Re: [xml-dev] [off-topic] Re: [xml-dev] Use xsd to specify multipleinsta

[Rick Jelliffe <rjelliffe@allette.com.au>]

Michael Kay wrote:
>
> That solves an important part of the problem, namely explaining the rule
> that has been breached. It doesn't help much with the other half of the
> problem, which is locating where it has been breached - given that the rule
> might concern the consistency of a number of elements or attributes widely
> scattered through the document.
>   
Yes. In Schematron we solve this by

 1) Having a split between the context expression that locates the nodes 
for testing the assertions
 1a) an optional path from those nodes to locate the "subject" of the 
assertions, if this is different from the
      context, which frees the context expression to be as simple as 
possible for the tests
 1b) role attributes on the subjects, to markup the significance of the 
subject in the pattern (which are
    the closest to a type name in XSD)

 2) test expressions in the assertions
 2a) role attributes on the assertions, to markup the significance in 
the assertion in the rule
  (which are closest to facet or model group names in XSD)

3) separate diagnostics elements on the assertions, to allow dynamic 
construction of diagnostics
     or repair tips, which frees up the assertion text to be purely 
intentional: the assertions
    can be "an X should have a Y because Z" while the diagnostics can 
say "I found AAA,
    which is outside the range"
  3a) role attributes on the diagnostics, e.g. warning|caution|note
 
   4) (planned for the new version)  separate properties elements on the 
assertions,
    which can contain PSVI-like anotations of static properties, 
structured (labelled)
    dynamic content including text and so on that can help locate problems,
     and sub-schemas.  For example, I have been working on
    embedding XSD types and CRepDL (character repertoire) scripts as 
properties,
    which can be converted to extra assertions.

And the Schematron skeleton implementation provides 3 different ways to 
generate
an XPath for the current subject, and 2 different ways to generate 
unique IDS based
on the XPath of the current subject. The location is available in the 
ISO SVRL
(Schematron Validation Report Language) format, along with the assertion
failure details: being an XML format this can then be easily used by the 
caller
to locate the assertions being tested.

Furthermore, of course, because Schematron does not (unless you select 
this in
the validator) have a fail-on-first error semantic, you can approach 
link problems from
both ends by having multiple tests for the same assertion.

And, to address the issue of having multiple errors that are merely 
side-effects of
a single cause, Schematron's phase mechanism allows the user to group 
patterns into
"phases", and first validate some issues, then others. This progressive 
validation also gets
rid of the problem that conventional schema languages have that the 
first problem
you get reported may not be in the class of issues you want to address: 
if your
workflow is that you want to get tables correct next, you don't need to 
first have
to fix up all other issues before the first table to start.

Cheers
Rick