MHonArc v2.5.2 -->
wsia message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: RE: [wsia][wsia-requirements][R413]
> 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
>