[
Lists Home |
Date Index |
Thread Index
]
Ian,
I'm not suggesting you go this route, but have you looked into the Post
Schema Validation Infoset (PSVI)? It seems that there *might* be some
potential overlap in the concepts you describe below, and the notions
behind PSVI (I'm simply suggesting that you may want to at least be
aware of these concepts).
Here is a recent XML.com article by Dare Obasanjo of Microsoft that
elaborates on the PSVI:
http://www.xml.com/pub/a/2002/12/19/datamodel.html
Here is a www-tag posting by Tim Bray from June 2002 that begins a
discussion on PSVI architecture:
http://lists.w3.org/Archives/Public/www-tag/2002Jun/0146
Kind Regards,
Joe Chiusano
Booz | Allen | Hamilton
Ian Graham wrote:
>
> 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/
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
begin:vcard
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard
|
