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

Just a thought, coulnd't we just extent the context info of the '
xforms-submit-error' event and add an xml instance that contains the 
returned xml?

Regards,

Nick

beaufour@gmail.com wrote on 04/11/2006 04:47:40 PM:

> 
> On 4/11/06, Mark Birbeck <mark.birbeck@x-port.net> wrote:
> > I don't think we're going to resolve this quickly, but I don't mind 
because
> > this is a big issue.
> 
> I tend to agree with you on both accounts :)
> 
> > > 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.)
> 
> Well, the http protocol does say that 4xx are errors, which is what I
> meant by "clear errors". But yes, people are (imho, unfortunately)
> twisting that.
> 
> > 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.
> 
> (Well, it is a design question. Amazon and Flickr f.x. use HTTP 200,
> do they not?)
> 
> > 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.
> 
> Yes, it was a couple of days since I visited RFC2616 though, but for
> some reason I just visited it again :) And, a bit to my surprise, for
> 4xx errors it actually states:
> "Except when responding to a HEAD request, the server SHOULD include
> an entity containing an explanation of the error situation, and
> whether it is a temporary or permanent condition."
> [http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4]
> The "SHOULD include an entity" had found its way out of my memory. So
> I am warming a bit more up to the idea :).
> 
> > 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*.
> 
> The designer is a failure then ;-)
> 
> > 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.
> 
> Well, I think we agree on that we need to expose more of the
> submission process to the form author. I have not thought too much
> about it though, so I do not currently have any pros or cons for your
> proposals or a solution either. I guess, what I fear is, that the form
> author ends up replacing his instance data with an error document.
> This is why I want a "distinct path" (I'm searching for a better
> word...).
> 
> --
> ... Allan
> 



--------------------------------------------------

Inventive Designers' Email Disclaimer:

http://www.inventivedesigners.com/email-disclaimer

Received on Tuesday, 11 April 2006 15:32:28 UTC