[
Lists Home |
Date Index |
Thread Index
]
- To: <xml-dev@lists.xml.org>
- Subject: Re: [xml-dev] Reporting XML validation results in XML: is this approach sensible?
- From: "Rick Jelliffe" <ricko@allette.com.au>
- Date: Wed, 1 Jan 2003 16:45:28 +1100
- References: <Pine.SOL.4.21.0212301831380.9956-100000@ic-unix.ic.utoronto.ca>
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:
1) Many editors use the Emacs/VI conventions for file:column:line:errror
messages, and this info is often available from SAX locators, so it might
be a good idea to allow them as well as XPaths.
2) XPaths are perhaps not useful for WF errors, because a typical
XML parser will reject a non-WF document and then you don't
have a tree: if you have to implement your own non-WF XPath
matcher, it may be a little extra work than expected.
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.
I hope these are of some use.
Cheers
Rick Jelliffe
|