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

["Timothy N. Jones" <tim@crossweave.com>]

> 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.

I can think of two "top-down" advantages to consumer/client-side validation:
efficiency and ease-of-use.  It will save the producer work and also network
bandwidth if the validation can be done on the consumer side.  Also, it is
conceivable that the consumer could use constraint information to provide
assistance to the user when filling out a form.

>  
> 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).

I actually think we should be encouraging the declarative style wherever
possible -- it is much more amenable to machine interpretation IMO and I
think will better support customization "value chains".  I pray that I can
one day excise the client-side javascript interpreter from my server-side
product :).

>  
> 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.). 

I think there is a wide spectrum to "semantic validation" and what I have in
mind (the XForms-type stuff) is fairly low level and well-defined -- I'm
specifically not suggesting any semantic web/RDF "magic".  The credit card
example discussed in the XForms intro seems like very basic stuff to me.

Efficency will always be a consideration.  In the stock quote example,
sending a list of every valid stock symbol from the Producer to the Consumer
would certainly not be reasonable.  In this case I think the Consumer-side
constraint should be loose and the real validation should take place at the
Producer.  The point is that where the validation should be applied will
depend on the specific circumstance, but we should support inter-property
constraints on the Consumer side for those circumstances where it is
appropriate.

>  
> 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 <DEFANGED_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>