RE: Dealing with HTTP response entities when response code is not 200 series

Leigh,

> We could provide an event to dispatch from xforms-submit-error which 
> continues with what xforms-submit-done processing would have done if the 
> response-code had been 200.

Would you really want that to happen?

If the response body contained an XML document that differed from that which the referenced instance expected (e.g. <error:error... instead of <atom:entry...) then you'd have possible schema validation and/or constraint errors.

Wouldn't it be better to just 'catch' the 40* errors via the 'xforms-submit-error' event and then handle the 'error' response by inserting it into an 'error' instance and have some rendering or message based behaviour that indicated the nature of the problem.


Regards

Philip Fennell 
Consultant
MarkLogic Corporation
Mobile +44 (0) 7824 830 866
email  Philip.Fennell@marklogic.com
web    www.marklogic.com

This e-mail and any accompanying attachments are confidential. The information is intended solely for the use of the individual to whom it is addressed. Any review, disclosure, copying, distribution, or use of this e-mail communication by others is strictly prohibited. If you are not the intended recipient, please notify us immediately by returning this message to the sender and delete all copies. Thank you for your cooperation.

________________________________________
From: public-forms-request@w3.org [public-forms-request@w3.org] On Behalf Of Leigh L Klotz Jr [leigh.klotz@xerox.com]
Sent: 07 September 2010 18:48
To: public-forms@w3.org
Subject: Dealing with HTTP response entities when response code is not 200  series

REST calls for correct use of HTTP response codes and entities, and
supports Content-Type and 400-series responses.
It's currently hard to process 400-series response entities.

For example, consider a web resource which either responds with 200 and
application/xml, or 40x and application/xml containing a document whose
top-level element is <error>...</error>.  In the error case, the
instance data is not replaced, but the event() function does offer
parsed access to the XML data.

Here are some ideas about how to move forward:

We could provide an event to dispatch from xforms-submit-error which
continues with what xforms-submit-done processing would have done if the
response-code had been 200.

<xf:dispatch ev:event="xforms-submit-error"
if="event('error-type')='resource-error' and
IS-IT-A-NODESET(event('response-body'))" />

Or, perhaps an attribute on submission for controlling whether
resource-error causes xforms-submit-error signalling.

<xf:submission resource-error="false()" ... />

Others?

Leigh.

Received on Wednesday, 8 September 2010 08:54:29 UTC