OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [wsia][wsia-requirements][R413]


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:tim@crossweave.com]
Sent: Monday, May 06, 2002 2:22 PM
To: Eilon Reshef; wsia@lists.oasis-open.org
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:akropp@epicentric.com]
> Sent: Friday, May 03, 2002 9:10 PM
> To: 'wsia@lists.oasis-open.org'
> 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>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC