Re: Cancel a submission in progress

On 4/8/06, Mark Birbeck <mark.birbeck@x-port.net> wrote:
> > 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.

I agree. We need to distinguish beteween
"xforms-submit-error-in-xforms" and
"xforms-submit-error-in-protocol-layer" (no, I do not suggest these
names :) )

> 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.

Imho SOAP is heading down the wrong path. Why is it messing with the
HTTP-layer? Why is it using HTTP in the first place? But that's SOAP
:(

> 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.

I do not agree with that. XForms should not take a clear error
statement from the underlying layer and turn it into a "no error".
That is very wrong in my eyes. Fine if it was
"soap://foo.bar.com/request", and SOAP defined clearly that the
information should be used. But converting a clear http error into a
"non-error"? I'm not in favor of that.

I do agree that 1) the information returned by the server on an error
could be useful and 2) proper soap handling needs this. But imho, it
still needs to be an error message, and it needs to take a different
and distinct path than that of a success response.

A specific attribute on submission that is false by default would be
fine by me. <submission ignore-protocol-error="true"/> ... or
whatever. But it needs to be clear that we ignore/convert/? the error.

--
... Allan

Received on Tuesday, 11 April 2006 10:41:48 UTC