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]
[Summary] Characterization of Schematron - Usage and Features


This example will be used in the below discussion:

<?xml version="1.0"?>
           One if by land; two if by sea.

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.


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.

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"?>
          <Candidate name="John">61</Candidate>
          <Candidate name="Sara">24</Candidate>
          <Candidate name="Bill">15</Candidate>

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.

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

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.

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

[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