Re: Support for service validation feedback

very good points and excellent presentation!

i absolutely agree with your statements about validation and would 
support your proposal for a definition of the error-messaging behaviour.

Validation is always a problem with different facets: item-wise, 
structural and business-constraints (which can be complex for itself). 
It's not convenient or sometimes even impossible to code everything 
directly into XForms such as database constraints or validations tightly 
coupled with transaction services.

as you nicely pointed out 'to be portable' XForms should define some way 
of reporting errors happening in some external process back to the 
XForms processor.


----
but also the response handling after a *successfull* submit should be 
detailed out: the submitInfo element currently only defines 'all' and 
'instance':

while 'instance' behaviour is clear, the 'all' behaviour looks 
underspecified to me. if i interpret it right the text tries to say 
(should say) something like this: '...if element submitInfo attribute 
replace has the value of 'all', the entire current document is replaced 
*by parsed XML*'

but how is a processor supposed to react on a replace="all"?
- should it finish the session and freshly start over with a new one? 
(silently assuming that the response contains another XForm)

- should it a preserve the old session ? and thereby allowing to chain 
forms.

futhermore i would propose to define another value e.g. 'none or 
redirect' for use with ordinary redirects. in this case the value of the 
action attribute would be interpreted as redirect url.

let me argue:
- it's a common use-case for applications to return to some menu or to 
simply send the user along when the job is done

- this way its easy to exit the form processing to some other 
page/location which doesn't use XML technology, making integration into 
arbitrary environments easier

- when initialization is covered by a spec, it should also define an 
'exit' but 'all' and 'instance' do not seem to fullfill this (at least 
as long as XML is expected as response to a replace='all' submit)

- on the other hand exiting could be achieved by allowing any 
content-type as response for 'all' but puts the burden of checking the 
type on the processor. an explicit third value for replace would solve 
this and allow to continue processing at any http reachable target.


please excuse for going off-topic but i think both issues have something 
in common: they seem to reach beyond the 'kingdom' of XForms but are 
essential for integration in real application environments. 'Kingdom 
XForms' should clearly show its boundaries to its neighbourghs (the 
client apps)

both issues can already be solved by using xforms:extension but as 
Werner pointed out this makes existing forms less portable across 
different xforms implementations and breaks the 'chain of interactions'.

Regards,

Joern



Werner Donné wrote:
> 
> 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.

Received on Thursday, 18 July 2002 21:21:36 UTC