[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Schematron: Categories of Usage?

• From: "Costello, Roger L." <costello@m...>
• To: <xml-dev@l...>
• Date: Mon, 22 Jan 2007 11:16:04 -0500

Thanks Rick and Manos.  Lots of excellent points.  I have revised my
earlier summary, to incorporate your comments:

- - -
Characterization of Schematron

This example with be used to clarify the discussion below:

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

A. Schematron Usage

Here are the ways that Schematron is being used today:

1. Co-constraint checking: in the example the co-constraint is 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).  The co-constraints may be "within" an XML
document, or "across" XML documents (intra- and inter-document
co-constraints). 

Note: the term "co-constraint" is a misnomer.  There may in fact be a
constraint over multiple items, not just two items.  Thus in the
example, if there were many Classification elements then we may want to
check that all values are identical.

Note': co-constraints may exist between XML structure components
(elements, attributes) as well as between 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.

2. Cardinality checking: in the example the cardinality constraint is
that the text in the Para element must not contain any restricted
keywords.  The keywords may be obtained dynamically from another file
(see Feature B below). 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.

Note: cardinality checking encompasses uniqueness checking. 

Note': existence checking is a special case of cardinality checking. 

3. Algorithmic checking: in the example the algorithmic constraint is:
"sum of the numbers in AuthenticityCode must be an even number".  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.

B. 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.


Excellent!  

Any others?

Is the above writeup easily understandable?  If not, I invite your help
to reword it.

/Roger

• Follow-Ups:
  • RE: Schematron: Categories of Usage?
    • From: "Rick Jelliffe" <rjelliffe@a...>

• References:
  • Re: Schematron: Categories of Usage?
    • From: "Rick Jelliffe" <rjelliffe@a...>