[
Lists Home |
Date Index |
Thread Index
]
Rick Jelliffe wrote:
> From: "DuCharme, Bob (LNG)" <bob.ducharme@lexisnexis.com>
>
> > I'd like to hear any comments and suggestions. For example, my examples are
> > pretty simple; can anyone think of a reason that it might not scale well?
>
> This is the same problem that Schematron's <phase> element addresses.
>
> In Schematron the <phase> lists the patterns that are <active>
> in it, your <sn:stages> just provide a name and the later declarations themselves
> nominate which stages they belong to. In Schematron, the approach makes
> sense for it because we have multiple passes over the document, so it is easy to
> figure out the effects of factoring out patterns or assertions, and because the
> idea of progressively validating a document (i.e. making sure the foundation
> is good before checking the paintwork in the attic) is important. However,
> Schematron only allows phases on a very large-grain unit: the pattern
> and not on individual assertions (they can be refactored into different patterns
> easily if needed.)
I like the approach suggested by Bob and I can't see any problems with the solution.
Another way to do this could
be to embedd Schematron rules in another schema language (W3C or RNG).
If we want to use this approach we use the first option suggested by Bob [1]:
"Have one schema, and set everything that doesn't appear in all stages to be
optional."
This is how far the W3C or RNG schema will go and after this we just have to add
Schematron rules activated by phases to validate the rest. To illustrate we have the
following very simple W3C schema:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:element name="Root">
<xs:sequence>
<xs:element name="floob" type="xs:string"/>
<xs:element name="zatz" type="xs:string" minOccurs="0"/>
<xs:element name="glikk" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:element>
</xs:schema>
The idea here is that we have Bob's three phases (floob, zatz and glikk) and each
phase have different requirements:
1) In the "floob" phase the element "floob" is required but "zatz" and "glikk" cannot
appear.
2) In the "zatz" phase the elements "floob" and "zatz" are required but "glikk"
cannot appear.
3) In the "glikk" phase all elements must be present.
The above W3C goes with Bob's first option that everything that isn't required by all
stages are made optional. Now what we can do is embedd Schematron rules that depend
on phases to validate the rest of the constraints. Here is an example of how this
could look:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo>
<!-- First we define the different phases that exist in the validation process
("floob", "zatz" and "glikk"). -->
<!-- Each phase specifies which pattern that should be active in each phase -->
<phase id="floob" xmlns="http://www.ascc.net/xml/schematron";>
<active pattern="floob"/>
</phase>
<phase id="zatz" xmlns="http://www.ascc.net/xml/schematron";>
<active pattern="zatz"/>
</phase>
<phase id="glikk" xmlns="http://www.ascc.net/xml/schematron";>
<active pattern="glikk"/>
</phase>
</xs:appinfo>
</xs:annotation>
<xs:element name="Root">
<xs:annotation>
<xs:appinfo>
<!-- The "floob" pattern check that the elements "zatz" and "glikk" doesn't
appear -->
<pattern name="Perform base validation" id="floob"
xmlns="http://www.ascc.net/xml/schematron";>
<rule context="Root/zatz | Root/glikk">
<report test="true()">The element <name/> is not allowed in the floob instance
document.</report>
</rule>
</pattern>
<!-- The "zatz" pattern check that the element "zatz" is present but "glikk"
isn't -->
<pattern name="Perform zatz validation" id="zatz"
xmlns="http://www.ascc.net/xml/schematron";>
<rule context="Root">
<assert test="zatz">The zatz element is required in a zatz instance
document.</assert>
<assert test="not(glikk)">The glikk element is not allowed in a zatz instance
document.</assert>
</rule>
</pattern>
<!-- The "glikk" pattern check that both "zatz" and "glikk" are present -->
<pattern name="Perform glikk validation" id="glikk"
xmlns="http://www.ascc.net/xml/schematron";>
<rule context="Root">
<assert test="zatz">The zatz element is required in a glikk instance
document.</assert>
<assert test="glikk">The glikk element is required in a glikk instance
document.</assert>
</rule>
</pattern>
</xs:appinfo>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="floob" type="xs:string"/>
<xs:element name="zatz" type="xs:string" minOccurs="0"/>
<xs:element name="glikk" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Each stage in Bob's article hence correspond to a phase in Schematron. The name of
the phase that should be used for the validation is sent to the Schematron validator
in the same way that the stage name is sent to the getStage.xsl stylesheet.
If this is validated manually by a GUI tool that support embedded Schematron rules
the available phases can typically be selected by the user in a selection list.
You can try out the above examples using the Topologi Schematron Validator [2] which
support embedded Schematron rules in W3C XML Schema. The attached zip-file contains
the example files.
For more information on embedding Schematron in W3C XML Schema see [3]
Cheers,
/Eddie
[1] http://www.snee.com/xml/schemaStages.html
[2] www.topologi.com
[3] http://www.topologi.com/public/Schtrn_XSD/Paper.html
Stages.zip
|
