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