[Summary] Characterization of Schematron - Usage and Features

["Costello, Roger L." <costello@mitre.org>]

CHARACTERIZATION OF SCHEMATRON - USAGE AND FEATURES

This example will be used in the below discussion:

<?xml version="1.0"?>
<Document>
      <Classification>unclassified</Classification>
      <Para>
           One if by land; two if by sea.
      </Para>
      <Classification>unclassified</Classification>
</Document>

CATEGORIES OF SCHEMATRON USAGE

Here are the ways that Schematron is being used today:

1. Co-constraint checking

 

In the above example there is a co-constraint between the two Classification values; namely, the two values must be identical. 

 

In general, co-constraints are constraints that exist between data (element-to-element co-constraints, element-to-attribute, attribute-attribute).  Co-constraints may be "within" an XML document, or "across" XML documents (intra- and inter-document co-constraints).

Schematron is very well-suited to expressing co-constraints.

Notes:

The term "co-constraint" is a misnomer, as it suggests a constraint only between two items.  There may in fact be a constraint over multiple items, not just two items.  For example, if there were many Classification elements then we need to check that ALL values are identical.

Co-constraints may exist between XML structure components (elements, attributes) as well as between data values.  For example, if Classification has the value "unclassified" then Document must only contain the elements shown above; if Classification has the value "secret" then Document must only contain other elements (not described here).

2. Cardinality checking

 

In the above example the cardinality constraint is: the text in the Para element must not contain any restricted keywords.  (The keywords may be obtained dynamically from another file.)

 

In general, cardinality constraints are constraints on the occurrence of data.  The cardinality constraints may apply over the entire document, or to just portions of the document.

Schematron is very well-suited to expressing cardinality checks.

Notes:

 

Cardinality checking encompasses uniqueness checking.

Existence checking is a special case of cardinality checking.

The following example will be used to characterize the next category of Schematron usage:

 

<?xml version="1.0"?>
<ElectionResults>

     <ByPercentage>

          <Candidate name="John">61</Candidate>

          <Candidate name="Sara">24</Candidate>

          <Candidate name="Bill">15</Candidate>

     </ByPercentage>

</ElectionResults>

3. Algorithmic checking

 

In the above example the algorithmic constraint is: "the election results must add up to 100%"

(i.e., 61 + 24 + 15 = 100). 

 

In general, validity of data in an XML instance document is determined not by mere examination or comparison of the data, but requires performing an algorithm on the data.

 

Schematron is very well-suited to expressing algorithmic checks.

Note:

 

"Algorithmic checking" may not be the best name for this category.  Other names suggested: "Computed value checking", "Formula checking", and "Equation checking".

SCHEMATRON FEATURES

1. Author specified error messages

 

Schematron allows the schema author to write the error messages, thus the errors can be reported at a higher (operational/user) level. The schema author can thus communicate with the user and explain the error in an understandable way and direct the user on how to correct the problem.

2. External Data Mashups

 

Data used in Schematron assertions may be dynamically obtained from external files.

ACKNOWLEDGEMENTS

 

Many thanks to the following people for their excellent inputs into creating the above summary.

 

Manos Batsis

George Cristian Bina

Stephen Green

Peter Hunsberger

Rick Jelliffe

Michael Kay

Guillaume Lebleu

Dave Pawson

Bryan Rasmussen