- From: Mark Birbeck <mark.birbeck@x-port.net>
- Date: Sat, 8 Apr 2006 19:45:44 +0100
- To: <www-forms@w3.org>
Hi Leigh, > On my point 2, I was unclear and your interpretation is what > I meant to say. When I said "we need to return error > documents", I meant that the form author and service author > needs to design their applications not to rely on HTTP level > errors for reporting conditions to the user, but must instead > return XML error descriptions with code 200, and then code > the form to present them. I think the issues you raise are really important, and all of the issues arise because XForms does not distinguish between errors at the protocol level and errors in its own submission sequence. I think we need some other way of getting information back about the protocol itself, and XForms should only concern itself with whether the submission process was started and completed successfully. In terms of the latter, I think the only error condition should be that either that there was some serious failure (no network, hard-drive full, etc.), or non-XML data was returned. The main reason for taking this approach is that some protocols such as SOAP and WebDAV sit on top of HTTP, and use the same error codes at a higher level. For example, the SOAP 1.2 HTTP Binding [1] makes use of HTTP 500 "Internal Server Error" [2] to indicate a fault [3]. However, the HTTP response can contain a SOAP message (valid XML), as illustrated by Example 11 in the SOAP 1.2 Primer [4]. The situation is the same in version 1.1 of SOAP [5]: In case of a SOAP error while processing the request, the SOAP HTTP server MUST issue an HTTP 500 "Internal Server Error" response and include a SOAP message in the response containing a SOAP Fault element (see section 4.4) indicating the SOAP processing error. Although this only has W3C Note status, it is quite widely implemented, so it does affect us, and the big problem is that in XForms 1.0 an HTTP 500 response is sufficient to cause the returned data to be ignored, and an xforms-submit-error to be dispatched: For an error response nothing in the document is replaced, and submit processing concludes after dispatching xforms-submit-error. [6] This means that the SOAP fault message is discarded, when in fact it could usefully be used by the form. Similar situations would arise with systems built on WebDAV, where creating an object that already exists or deleting an object that doesn't exist would cause an error--but there is no way to give the user useful feedback ("Customer already exists", for example) because the XForms processor has already got rid of the returned data. My feeling is that if submission was started successfully, and XML data was received successfully then we should regard that as there being 'no error' and replace the instance data as requested. It is then up to the form author to 'unpack' the data and do something with it, and to decide what constitutes an error in their system. This is a problem that has been discussed within the Working Group and a couple of proposals are on the table, so hopefully it will be solved. Regards, Mark [1] <http://www.w3.org/TR/soap12-part2/#soapinhttp> [2] <http://www.ietf.org/rfc/rfc2616.txt> [3] <http://www.w3.org/TR/soap12-part2/#tabreqstatereqtrans> [4] <http://www.w3.org/TR/soap12-part0/#Example10> [5] <http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383529> [6] <http://www.w3.org/TR/xforms/slice11.html#submit-event> (End of step 5.)
Received on Saturday, 8 April 2006 18:46:24 UTC