OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] [off-topic] Re: [xml-dev] Use xsd to specify multipleinstances of existing element

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 
    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 
    which can be converted to extra assertions.

And the Schematron skeleton implementation provides 3 different ways to 
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 
(Schematron Validation Report Language) format, along with the assertion
failure details: being an XML format this can then be easily used by the 
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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS