W3C home > Mailing lists > Public > www-forms@w3.org > April 2006

Submission and protocol 'errors' [was RE: Cancel a submission in progress]

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Tue, 11 Apr 2006 14:10:03 +0100
To: <www-forms@w3.org>
Message-ID: <009801c65d69$3f5bd510$0e01a8c0@Jan>

Hi Allan,

Good comments, thanks.

I don't think we're going to resolve this quickly, but I don't mind because
this is a big issue. If we were programming with XMLHttpRequest it would be
a lot easier because we'd just request the data, look at it close up, and
then decide what to do with it. We'd not have overwritten any previous data
with new data, because the data received arrives in the XHR object waiting
to be copied, and we'd only copy if we were happy with the result.

But obviously this doesn't work with XForms, since we're trying to come up
with something that isn't just based on HTTP, and abstract away those kinds
of details, and so what constitutes 'an error' is something we have to
resolve.

So, anyway...some more thoughts...


> > 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 :(

I'm agnostic ;) I'm not sure if I like or dislike it, but this approach is
not confined to SOAP--in fact it's increasingly common. Here's another
example, that retrieves information from a genome database and uses HTTP
error codes:

  <http://www.biodas.org/documents/das2/das2_protocol.html>


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

I understand the concern, but the problem with the way that HTTP is being
used nowadays for transferring data is that an error is not necessarily an
error! (In other words, there is no such thing as the "clear error
statement" that you would like.)

As an example, say I have a RESTful interface to my contact database and I
ask for person 300. The XML is returned fine with an HTTP 200, I interact
with the data, and all is well with the world. I then ask for person 250,
who doesn't exist, and the server returns an HTTP 404 with some XML message
that says the customer no longer exists, and if I think they *should* then I
can contact the sysadmin on extension 333.

In this scenario what exactly is the error? There is no failure of
communication (for example, the network), since we asked for data, and got
stuff back. Sure there is a 404 'error' but that is not a catastrophic
failure--it's just that we designed our system (in good RESTful fashion) to
make use of the HTTP error codes to pass back extra information.

So I'm not saying that XForms should turn this into 'no error'--I'm saying
that the system designer already has! As far as this system is concerned
there is no error in the sense of *failure*.

My feeling is that we don't just have 'extra' information that might be
useful, we have a fundamentally different approach to how we look at the
interactions with the server. In terms of building applications we're
finding more and more that we can't do this:

  * ask the server for person x and put it directly into
    instance A;

because we can't be sure that there is a person x (and we can't be sure that
Google returned any search results, or Flickr returned any photos).

Instead we invariably have to take an approach more like the XHR one I
outlined at the top, and do this:

  * ask for person x and put the *response* into instance T;

  * examine the response and if all is OK put it into
    instance A and if it's an error, maybe put it into
    instance B.

So this is why I'm saying that what constitutes 'an error' is dependent on
the particular application and can only be decided by the form author.
(There could still be errors at a lower level...server not found, network
down, etc., and they would warrant an xforms-submit-error.)

The big bit that is missing in XForms is the "examine the response" part I
just described, since at the moment we do not have access to the headers and
status codes from the underlying protocol.

Note that you could achieve the same thing with a slightly different logic,
hiding some of this functionality inside the processor:

  * the author asks for person x to be placed in instance A;

  * the XForms processor asks the server for person x and puts
    the *response* into some temporary bucket;

  * the processor dispatches the event 'xforms-data-received';

  * the author checks the status codes and if all is ok does
    nothing;

  * if there is an error the author changes the instance property
    on the SubmitEvent object to point to instance B.

This is all doable and in fact I proposed something along these lines a long
time ago when suggesting serialisation events. But at the moment I'm not
that bothered about how this part plays out since the same effect is
achieved by the author having two instances. The first issue is to resolve
this question of 'an error'.


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

I can see some advantages, but again I come back to the question of what
constitutes an error? I don't think this would work.

For the purposes of this discussion I wonder if we should talk about
*failure* or *critical error* for when the network is down, the server is
not found, the hard-drive is full, etc. And then just *error* for the HTTP
error codes. That might help us to prise apart what we need.

Regards,

Mark


Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
b: http://internet-apps.blogspot.com/
w: http://www.formsPlayer.com/

Download our XForms processor from
http://www.formsPlayer.com/
Received on Tuesday, 11 April 2006 13:11:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:03 GMT