Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: [off-topic] Re: Use xsd to specify multipleinsta
![Re: [off-topic] Re: Use xsd to specify multipleinsta](/images/get_stylus.gif)
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
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
|
|||||||||
