Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Handling well-formedness or validity errors
 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@b...] > 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@b... > > > 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
