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


Help: OASIS Mailing Lists Help | MarkMail Help



   Handling well-formedness or validity errors

[ Lists Home | Date Index | Thread Index ]
  • From: Seairth Jacobs <seairth@bbglobex.com>
  • To: xml-dev <xml-dev@lists.xml.org>
  • Date: Mon, 18 Dec 2000 09:46:25 -0500

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)?  More specifically, I am concerned with XML requests that are received over HTTP (or similar transport) and require some form of response.
In a small specification I am working on, I have come up with the following:
1) When it comes to validity, each request is wrapped in a <add>, <edit>, <delete>, or <get> block.  The response document contains an associated <addresponse>, <editresponse>, <deleteresponse>, or <getresponse> block.  On of the attributes is a success code similar to the HTTP response codes.  If the document is not valid according to the specification, the appropriate response is sent back with the appropriate error code.  This seems fine as long as the the validity failure occurs inside of the root element.  Outside of the root element, I am not sure of the appropriate response.
2) When it comes to well-formedness, I have no good thoughts.  Every idea I have thought of has a weakness or two.  I had even thought of returning an error at the HTTP level itself, but I didn't want to tie the specification to the transport.  Or do I need to?  Is it acceptable to use an HTTP-level 4xx error response when using HTTP as the transport, while using a different method altogether when using an onrelated transport (such as SMTP or FTP)?
Any thought would be appreciated.
Seairth Jacobs


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

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