[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Reporting XML validation results in XML: is this approach sensible?
Here's something to hopefully stimulate some interesting 2003 discussion. As I mentioned in a previous posting (http://lists.xml.org/archives/xml-dev/200212/msg00323.html) I am trying to develop a mechanism for reporting 'validation' error details for an XML entity. Although my specific context is a response to a Web service request, error reporting would seem a generic issue, so I'm hoping this topic might be of interest to this list. I also can't imagine that someone hasn't already looked into this, and any reference to existing work would be much appreciated. The goal is to have the response identify the locations and types of various 'data' validation errors (e.g. field value errors) associated with the request. In particular, we want these identified in the context of the request XML message, since this is the only context shared by client and server. The last goal is simplicity -- we want something that is easy to understand and use, so we can explain it and get designers to use it. The errors could be schema-validation errors, or not -- in our case I expect many will not be (e.g. checksum validation errors; date values disallowed based on the current date; other business rule errors not defined in the schema). The model I have proposed is as follows. * use XPath expressions to reference the node in the request causing the error * define an enumerated list of error messages to specify the error type. This list would likely not be defined in the schema, as the error types will be specific to element types, which makes it hard to define a simple single framework for this mechanism. By way of example, an error response might contain something like: <errorList> <error> <location> //a[1]/b[3]/item[1] </location> <errorType> invalidType2Checksum </errorType> </error> <error> <location> //a[1]/foo[4] </location> <errorType> disallowedElement </errorType> </error> </errorList> and so on. In principle, if related to a schema violation, the errorType could specify the facets that were violated, and how. Also, in principle, the model could be extended for errors related to co-constraints. But, of course, any model can be extended to just about anything, so I first wanted to pass it by some others, and see if it seems reasonable. Any thoughts? Best -- Ian -- http://www.utoronto.ca/ian/
|
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
|