- From: Werner Donné <werner.donne@re.be>
- Date: Thu, 18 Jul 2002 18:30:01 +0200
- To: www-forms@w3.org, www-forms-editor@w3.org
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
Received on Thursday, 18 July 2002 12:29:59 UTC