Re: [xml-dev] Schematron: Categories of Usage?

["Rick Jelliffe" <rjelliffe@allette.com.au>]

Costello, Roger L. said:
> Hi Folks,
>
> I am putting together a list of ways that Schematron is being used.  I
> seek your help in ensuring that the list is complete. (I will post the
> final list)

Perhaps existence may be considered a special case of cardinality: count()
is very common in Schematron schemas for cardinality. And does "existence"
capture the position-independence aspect?

Similarly, where does guarantees of uniqueness fit in? (e.g.
count(//x[@id=current()/@id) = 1 ) I don't think they are co-constraints
or existence. But people do key/id checking.

Also, some papers subdivide co-constraints to differentiate value and
structure:
  value-value
  value-structure
  structure-value
  value-value
but the reality seems more complicated.

Murata-san's 2005 paper http://www2005.org/keynotes/makoto.pdf at slide 35
identifies some uses for the Japanese Local Government project. He
identifies identity constraints such as
  //a/b + //c/d = //e/f
plus inter-document checks as being key. The trouble with the terms
"co-constraint" or "co-occurrence constraint" is that they suggest that
there are only two terms, whereas there can be multiple terms.

In BR's enormous Danish example earlier, shocked readers will be relieved
to know that ISO Schematron allows variables, so that expression could be
factored into smaller named chunks for clarity. However, equations are
often important. I expect that the use of Schematron to test formulae or
equations will increase with the advent of EXLST and XSLT2-based
implementions under current testing. For example, to check that the total
fields match the sum of the entries, to some level of precision at least.

In the ACORD (London Markets) work, it is used as for gatekeeping:
http://www.lloyds.com/News_Centre/Features_from_Lloyds/Schematron_pushes_the_right_buttons.htm
There is some detail of where they use Schematron and where they use XSD at
http://www.marketreform.co.uk/Documents/Claims_pubs/London_Market_Implementation_of_ACORD_DRI_Messages.pdf
around page 34:

 * Inconsistency between fields of this message
 * The message refers to a supporting message and it was not received
 * Cross field validation found missing data (co-occurrence and existance!)
The diagram on page 39 makes their process flow clearer.

A really interesting document is
http://www.eurocontrol.int/eaip/gallery/content/public/doc/pdf/book_eAIPSpecification.pdf
This gives the publication rules for Air Traffic Control manuals for a
large chunk of Europe. The fun starts around page 12 (18) s3.3.2
Additional Rules.  These gives rules such as "Route segments in the same
route may not have mixed true track and magnetic track."

It seems that they allow segments to be marked "deleted", therefore there
are constraints to apply to "the first non-deleted segment..." Is that a
co-constraint?

The Eurocontrol document also mentions checking against MIME types: so add
enumeration checking to the list. Also link and reference checking. Also
simple data typing (value of attribute must be positive number).

They also have mandatory and optional rules. (I don't know if they
implement them as separate Schematron phases or separate schemas.)

Cheers
Rick Jelliffe