OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: Handling well-formedness or validity errors

[ 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 &

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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS