[
Lists Home |
Date Index |
Thread Index
]
- From: Manoj Dhooria <manojd@geometricsoftware.com>
- To: xml-dev <xml-dev@lists.xml.org>, Seairth Jacobs <seairth@bbglobex.com>
- Date: Wed, 20 Dec 2000 14:33:32 +0530
Actually, the issue is more severe than just the handling of XML parsing
errors. I am building a distributed application where the client not only
wants to know if & what went wrong in HTTP transport & my request parsing,
but also the action that was expected of server per this request.
Since I could not find a standard way of handling it, I kind of started
embedding it in HTTP Reason-Phrase. E.g., "MyAppName#23 <my error text>"
with an appropriate HTTP status code. Where MyAppName is some prefix that my
server side code will always use - so client can parse the string & extract
it. If there is a browser that actually looks at the phrase returned by
server (my versions of both IE & Netscape give their own hard coded
messages), the client will see the code too. Since my clients usually ship
as my own vertical applications, I can always get the correct message &
code.
Whether to put your code in HTTP header or in entity actually appears to be
philosophical split - depends on how you look at your application.
Anyone with better ideas for handling these things?
> -----Original Message-----
> From: Seairth Jacobs [mailto:seairth@bbglobex.com]
> Sent: Tuesday, December 19, 2000 8:38 PM
> To: xml-dev
> Subject: Re: Handling well-formedness or validity errors
>
>
> Mike Brown wrote:
> > Seairth Jacobs wrote:
> > > When processing an XML ducument, how do you all suggest
> > > returning an appropriate error when the document is either
> > > not well-formed or is not valid (against a DTD or schema)?
> >
> > I think you answered your own question in the rest of your message; you
> want
> > to avoid using transport-specific error messages for well-formedness or
> > validity errors. If there was no problem with the transmission/transport
> of
> > the data, regardless of how parseable it is, then an HTTP 4xx error
> response
> > is not appropriate.
> >
> > However it is not out of the question to use the body of an
> HTTP response
> to
> > provide an acknowledgement and success/failure info, in any
> format.. just
> > don't pick the response code based on that. If the transmission was
> > successful, return a 200, 201 or 204, according to the guidelines in
> section
> > 9.5 of the HTTP/1.1 spec. In fact, 10.2.1 says that for a POST
> (I do hope
> > you are using POST), a 200 indicates that the request succeeded and it
> > should provide an entity (body) describing or containing the
> result of the
> > action. So there you go. Success of the request is not the same as the
> > result of the action.
>
>
> Sure, that was my feeling as well. However, is there a "standard" way of
> returning a response that indicates that the XML document failed either
> well-formedness or validity tests? For instance, if the document is not
> valid, it would not necessarily be appropriate to return a error response
> according to the document schema.
>
> Ex. 1: sending a request that is not valid (though is based on
> the correct
> document schema)
>
> <!-- request -->
> <mystandard><body>Some data</body></mystandard>
>
> <!-- response -->
> <mystandard errno="-1"><error>No body tag in schema</error></mystandard>
>
>
> Ex. 2: sending a request that is not valid and isn't even based on the
> correct schema
>
> <!-- request -->
> <wrongstandard><body>Some data</body></wrongstandard>
>
> What would be an appropriate response here? You can't
> necessarily return a
> response as was done in Ex.1 because the requester may not understand the
> schema being used. What would be a more universal way to indicate such a
> failure? (This sounds like the need for a standard.)
>
> The same argument can be applied to an XML document that's not
> well-formed.
> However, here one can't even necessarily return an error response
> based on a
> schema because the request may not have been validated yet. It's
> almost as
> if there needs to be a universal error response that everyone
> recognizes in
> addition to their own schema specific responses. For instance, the
> following could be a response recognized by all systems:
>
> <xmlerror type="VC" production="39"/>
>
> or
>
> <xmlerror>
> <production number="32" type="VC"/>
> <production number="39" type="WFC"/>
> </xmlerror>
>
>
> Before anyone complains, I realize that "xml" are reserved here.
> I was only
> using it for clarity (though it would be nice for the W3C to
> adopt something
> like this, if they haven't already). I realize that this does
> not encompass
> validation of the XML Schema standard or other standards concerning
> definition of validity. However, it may be possible to work one
> out so that
> the above sample might look like:
>
> <xmlerror source="XML">
> <!-- based on the XML specification productions -->
> <constraint number="32" type="VC"/>
> <constraint number="39" type="WFC"/>
> </xmlerror>
>
> <xmlerror source="XML Schema">
> <!-- indexed list of XML Schema validation contraints would be needed
> (if they don't aklready exist)-->
> <constraint number="25" type="VC"/>
> <constraint number="104" type="VC"/>
> </xmlerror>
>
> <xmlerror source="Schematron">
> <!-- indexed list of Schematron validation contraints would be needed
> (if they don't aklready exist)-->
> <constraint number="32" type="VC"/>
> </xmlerror>
>
>
> And, of course, if the processing got beyond all validity and
> well-formedness tests successfully, then the receiver could still
> return an
> "error" based on the schema in use and be guaranteed to know that
> the sender
> "should" understand the response.
>
> Thoughts, anyone?
>
> ---
> Seairth Jacobs
> seairth@bbglobex.com
>
>
>
|
