W3C home > Mailing lists > Public > www-forms@w3.org > July 2002

Support for service validation feedback

From: Werner Donné <werner.donne@re.be>
Date: Thu, 18 Jul 2002 18:30:01 +0200
Message-ID: <3D36ED09.5060503@re.be>
To: www-forms@w3.org, www-forms-editor@w3.org


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:

     <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 category="warning">
       <item ref="my:payment/my:amount"/>
       <message>The state of your account would not allow the payment at this


Werner Donné  --  Re BVBA
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne@re.be
Received on Thursday, 18 July 2002 12:29:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:06 UTC