[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Reporting XML validation results in XML: is thisapproach s
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@i...> > > > 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
|
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
|