RE: Cancel a submission in progress

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