Navigating the XML Tree

Schematron First published in 1999 by an Australian named Rick Jelliffe Now an ISO Standard (ISO/IEC 19757-3:2016) a rule-based validation language for making assertions about the presence or absence of patterns in XML trees. Wikipedia a feather duster to reach the corners that other schema languages cannot reach Rick Jelliffe

How it works, grossly oversimplified

The basic underlying principle is simple (and yet masterfully clever): Go to XPath A; from there test the existence of XPath B, and tell me if it is not there.

An example A person’s name as given in the contextual information about that person must be catagorized with @type.

Note that this does not say anything about use of type on persName elements that are not inside person.

Another example A limerick should have five metrical lines.

How it works, oversimplified

The basic underlying principle is simple (and yet masterfully clever): Go to XPath A; from there test the existence of XPath B, and tell me if it is (not) there.

Since there means true() and not there means false(), XPath B does not even have to be a path to a node in the input document, it can be anything.

And remember that an XPath returns a sequence of 0 or more nodes. If XPath A returns more than one node, XPath B is tested from each one in turn.

Reversed logic example

The attribute class att.handFeatures provides the pair scribe & scribeRef and the pair script & scriptRef. It is common for a project to use one from each pair, but never the other. But you can well imagine an archive that accepts documents that uses either, but would not know how to process an element that actually had both attributes of a given pair.

The scribe should be identified with a token or with a pointer to a <person> element, but not both. The script should be identified with a token or with a pointer to a <scriptNote> element, but not both.

Dynamicly generated information in messages The scribe should be identified with a token or with a pointer to a <person> element, not both; but this has both. The script should be identified with a token or with a pointer to a <scriptNote> element, not both; but this has both. A limerick should have five metrical lines, so either this line group should not be categorized as a limerick, or it should not have metrical lines. The current page () may be misnumbered!

Remembering XPaths for later use The element with id= corresponds to itself! The @xml:id "" on <> duplicates an @xml:id found earlier in the document

Where Schematron goes: ODD

Ideally, your Schematron tests should be included (with all your other TEI customizations) in your TEI customization ODD file.

The @xml:id "" on <> duplicates an @xml:id found earlier in the document

The WWP does not currently use the XML base attribute. It is permitted by this schema so that validation post-XInclude processing works.

When in ODD …

In an ODD, Schematron rules, assertions, or reports appear in a constraint inside a constraintSpec scheme="schematron" which itself can appear in attDef, classSpec, elementSpec, or schemaSpec.

If the sch:rule is missing (i.e., just bare sch:assert and sch:report elements), then the context is the element or attribute that is being defined.

In an ODD, you need to specify the tei: prefix for TEI elements (even though you do not need to declare it).

Another Schematron-in-ODD example a name of a person should be sub-catagorized as an officer's name or an enlisted man's name the name of a ship should be sub-catagorized as that of a merchant or naval ship

Where Schematron goes: standalone

It is possible to use Schematron without ODD.