Title: Message
I agree that having an existing standard with which we can express
constraints is a good "bottom-up" reason to use it - however, I am still
struggling with the "top-down" reason, namely: what business value does it
provide. Or: where does it save the Producer / Consumer / User work that would
otherwise be manual.
Rich suggested that this allows the Consumer to perform validation prior
to invoking the Producer.
I can sort of see the use of it being used when one binds data to
controls in an MVC model (this provides a declarative way to validate user input
without code, I guess), which is (I guess, again) the motivation in XForms. Even
in this case I would personally favor (manual or automatic) generation
of procedural validation code over declarative programming. (And, again, I
am not familiar enough with XForms to know what's the constraint language used
there).
In WSIA, Property Values are provided by the Consumer, so
the Consumer programmer (or the End User filling Property Values in some GUI)
needs to learn a lot of about the semantics of the the Property Values
to ensure that they make sense (e.g., the "StockSymbol" Property must
indeed represents an existing company; how do you represent tracking stocks;
which stock exchanges are supported; how do you represent option symbols, etc.).
So, I am not sure that declarative inter-property constraints is where we
can provide the most value. (Versus, for example, specifying a human-readable
textual representation of the constraints...).
Having said all this (I suddenly noticed it is actually five paragraphs),
do we feel that property constraints are part of the Embedded use case? Of the
Customized use case? In the latter, we might take it back into what I am sure
will be an exciting debate in the Customized subcommittee...
Eilon
-----Original Message-----
From: Timothy N. Jones
[mailto:]
Sent: Monday, May 06, 2002 2:22
PM
To: Eilon Reshef;
Subject:
RE: [wsia][wsia-requirements][R413]
There is a concise scenario nicely describing the value of
semantic
validation in the XForms intro
chapter[1]. I see no reason not to include
the
XForms binding constraint technology[2] as a recommendation along with
the Schema datatype constraint technology.
My only issue with R413 is that it's unclear whether #4 is
necessary -- are
binding constraints not included in
semantic constraints (#3)?
Tim
[1] http://www.w3.org/TR/2002/WD-xforms-20020118/slice2.html
[2] http://www.w3.org/TR/2002/WD-xforms-20020118/slice6.html
> I *think* I understand the intent but not necessarily the
motivation.
> Are rich semantic descriptions of
property values and relations a
> *requirement* or
a "nice to have" feature of a particular API? I can see
> the value of having *human-readable* meta-information (aids the
user of
> the Web Service). I can see the value of
type constraints a-la Schema
> (mainly helping the
Consumer map properties into programming
>
constructs). Can anyone clarify the value of richer constraints?
>
> Or, maybe, can
we perhaps define this requirement as open for
>
extensibility, for example:
> This specification
should permit the Producer to specify additional
>
machine-readable semantic information regarding properties.
> ...which would lead to a construct such as Schema's
<app-info>
> which
> allows arbitrary (but not specified) type constraints and
information.
> -----Original Message-----
> From: Alan Kropp [mailto:]
> Sent: Friday, May 03, 2002 9:10 PM
> To: ''
> Subject: [wsia][wsia-requirements][R413]
> R413 [Expressiveness]
>
Producer properties should allow for the specification
> of
> validation constraints and/or
logic at each of the following levels:
>
1. lexical
>
2. syntactic
>
3. semantic
>
4. Constraints linking two property elements,
defining how the
> value of
> one may be computed from that of the other. Debate: CW, SR, AK,
SF, SA.
> Also
> 414-415
>
Reword #4:
> By reference to
the value(s) of one or more properties already
>
defined.
>
----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use
the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
