[
Lists Home |
Date Index |
Thread Index
]
Thanks for the suggestions -- and also to Henry (and Joseph Chiusano) who
provided additional feedback. I am still reading and thinking things
through, but I thought in the interim I'd jot down some half thoughts, to
indicate where I'm wandering.
Of course you're right that XPAth's won't work if the document is not well
formed: but I'm more interested in the case where it is well formed, and
where I want the error report to be somehow positioned in the 'business
layer' of the application as defined by the messages, rather than at the
mid-level layer of schema validation. That is, I'd like the XML error
report to make sense from the application's business context -- and
hopefully be understandable to a business analyst reading response
messages, and potentially the business developer writing code. For
example, suppose I send a message such as
<purchaseOrder>
<partType> 1234-5463 </partType>
<unitsOrdered> 123 </unitsOrdered>
<deliveryBy> 20021231 </deliveryBy>
</purchaseOrder>
and there are two problems: the partType doesn't match a string pattern
constraint (part types have five numbers after the hyphen -- a type of
constraint that could easily be defined in a schemafile), while deliveryBy
satisfies a date string constraint, but is still invalid (its impossible
to deliver before it's ordered!). I'd like to report this as:
<report>
<error>
<location> report/purchaseOrder/partType</location>
<position> column:line </position>
<type> InvalidPartNumber </type>
</error>
<error>
<location> report/purchaseOrder/deliveryBy</location>
<position> column:line </position>
<type> dateInPast </type>
</error>
</report>
where the types are some kind of pre-agreed error reporting vocabulary.
The advantage is that the response is easy to interpret at the business
level, which should make development and debugging easier. It also forces
the designers to put as much 'business process' intelligence as possible
the requests and responses, which I suspect is good for making easy to
understand (and debug) protocols.
A second (half-thought through) idea as to why this might be useful has to
do with application design (web service client code, not XML). Suppose
application, X (client) constructs a request XML message and sends it to
application Y. But, as the message is constructed, 'X's components
register themselves, using XPath, as owners of specific portions of the
request message. Error responses referencing specific XPaths are then
automatically handled by the appropriate component.
This sort-of uses XPath as a hacky bridge to account for the fact that
there is likely no shared application component model across different web
services clients & servers -- but there is always a shared model for the
message, and for the types of errors a message might produce.
I admit this is a lot of half-baked thoughts in one letter, but there
seems to be something interesting in here ....
On Wed, 1 Jan 2003, Rick Jelliffe wrote:
> From: "Ian Graham" <igraham@ic-unix.ic.utoronto.ca>
>
> > 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.
>
> There is an implementation of Schematron that has error messages in
> XML: see the section on conformance at the bottom of
> http://www.ascc.net/xml/schematron/1.5/
> for the DTD.
>
> Some points:
>
....
> 3) Schematron allows you define your own diagnostics
> (including dynamic, context-sensitive details) as part
> of the diagnostic. So allowing just a predefined number
> is probably not workable. In fact, many implementations
> of Schema languages are parameterized too (e.g. Xerces)
> to allow contextual information to be provided (e.g.
> the value and name and parent of an attribute).
>
> 4) Schematron also allows peripheral information, for
> example, an XPath to the "subject" of a pattern, or
> a "role" attribute so that you can label which role
> a particular assertion is playing.
>
> 5) In the case of ISO DSDL and XPath 2, where
> you can transform some data into another XML and then
> examine it, you have two paths involved: the path
> where the error was found, and the path back to the
> original document. This complicates reporting.
THanks for the pointers -- so much to read and learn, and so little
time .... ;-O
Ian
|
