[
Lists Home |
Date Index |
Thread Index
]
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/
|
