- From: TV Raman <tvraman@almaden.ibm.com>
- Date: Sun, 21 Jul 2002 08:28:41 -0700
- To: werner.donne@re.be
- Cc: www-forms@w3.org
Excellent points.
You may want to consider doing some experimentation via schema
annotations,
and seeing how far you can push that --looking at the xerces2 apis,
you might be able to access that information via the augmentation
APIs.
If all this works, we could do the classic 80/20 thing in XForms 2.0
or whatever the next version is called
in terms of allowing the forms author to access commonly desired
functionality directly from the xforms model.
Werner Donné writes:
>
> Hi,
>
> XForms provides strong validation which is very good because it will reduce
> the useless submission of wrong data to business services. The result of
> business rule validation, however, is not covered. An XForms processor should
> not, of course, have to be responsible for such validation. This is the task of
> the business logic only. If business rules are replicated in the presentation
> logic, the realm XForms lives in, we're back at the fat client paradigm.
>
> As a consequence, there will always be presentation-level validation and
> business-level validation. I think the feedback of the latter must also be
> supported in a portable way, because portability is a key issue in XForms.
> A business service can map a business rule violation back to the involved
> elements in the submitted instance data, so it could be fed back to the user.
> The user would get back his form initialised with the submitted instance data,
> together with an indication of the errors.
>
> A service can interact with many different XForms clients, but can report errors
> only in one way. If the complete chain of interactions is to be portable, the
> response after submission has to be included.
>
> It should therefore be possible to initialise a form not only with instance data,
> but also with errors that pertain to this instance data. A possibility is to extend
> the model element with a new optional element called "serviceResponse" for
> example. In this element error and warning detail elements can be stored. Each
> detail has a list of items which point to instance data elements. (More than one is
> needed, because a business rule violation can involve a combination of elements.)
> A detail also has a message which can be addressed to a human.
>
> The default processing of xforms:modelInitialize could have a sixth step in which
> all model elements are sent an xforms:serviceResponse event if they have such
> a non-empty element. It is then up to the XForms implementation to figure out
> how to present the service response to the user.
>
> Here is an example:
>
> <model>
> <instance>
> <my:payment>
> <my:amount>500</my:amount>
> <my:date>
> <my:year>2002</my:year>
> <my:month>07</my:month>
> <my:day>21</my:day>
> </my:date>
> </my:payment>
> </instance>
> ...
> <serviceResponse>
> <detail category="error">
> <item ref="my:payment/my:date/my:month"/>
> <item ref="my:payment/my:date/my:day"/>
> <message>A payment date must be at least eight days ahead.</message>
> </detail>
> <detail category="warning">
> <item ref="my:payment/my:amount"/>
> <message>The state of your account would not allow the payment at this
> moment.</message>
> </detail>
> </serviceResponse>
> </model>
>
> Regards,
>
> Werner.
> --
> Werner Donné -- Re BVBA
> Engelbeekstraat 8
> B-3300 Tienen
> tel: (+32) 486 425803 e-mail: werner.donne@re.be
--
Best Regards,
--raman
------------------------------------------------------------
T. V. Raman: PhD (Cornell University)
IBM Research: Human Language Technologies
Architect: Conversational And Multimodal WWW Standards
Phone: 1 (408) 927 2608 T-Line 457-2608
Fax: 1 (408) 927 3012
Email: tvraman@us.ibm.com
WWW: http://www.cs.cornell.edu/home/raman
AIM: TVRaman
PGP: http://emacspeak.sf.net/raman.asc
Snail: IBM Almaden Research Center,
650 Harry Road
San Jose 95120
Received on Sunday, 21 July 2002 11:29:47 UTC