Rick Jelliffe, 2010/04/14
This document provides documentation on the XSLT API available in the implementation of Schematron called iso_schematron_skeleton.xsl. (available in an XSLT1 and XSLT2 version). The API makes available as much information from the schema, however there may be some edge cases where it is not exhaustive.
The skeleton is an XSLT script which provides all the basic parsing and validating routines for compiling a Schematron schema into XSLT. Schematron was designed to allow many different uses, and the skeleton gives you a headstart in creating a customized implementation. You just need to write XSLT templates to override the default ones. (The program you write is sometimes called a meta-stylesheet.) It is the meta-stylesheet that is called as the XSLT script, not the skeleton. There are several pre-processing stages which the Schematron schema should be processed through first, to handle such things as include statements and abstract patterns.
Phases and error reporting for problems in the schema itself are handled by the skeleton with no interaction with a “meta-stylesheet”. Note that there is no guarantee that the context node is always the element being handled: in most cases the only information available is the information in the parameters.
For an introductory tutorial on using this API, see Bob DuCharme's Schematron 1.5: Looking Under the Hood
(This is an updated version of the API for the Schematron 1.5 implementation called skeleton1-5.xsl, which in turn comes from the new architecture contributed by Oliver Becker for Schematron 1.3.)
The current API contains only additions. Well-written meta-stylesheets that use the new API will be be able to run on the existing 1.5 and 1.6 skeletons. Similarly, it should be possible to upgrade the skeleton from 1.5 or 1.6 to the iso-schematron-skeleton only by correcting the import statement at the beginning of the meta-stylsheet. Additions or re-groupings from the 1.5 schema are shown in red. Deletions have overstrike.
Mooted addition: a parameter @action which for specifying processing instructions on assertions and reports.
The process-prolog template gets called at the start of the validation session. It has no parameters. The default implementation is no action.
The process-root template processes the root element of the schema (which is not the same thing as the root of the document / and need not be the document element /*) .
Rich properties:
To print the documentation paragraphs, use <xsl:apply-templates mode="do-schema-p" />
To output the results, use <xsl:copy-of select="$contents" />
The process-assert template handles asserts whose test has failed.
Rich properties:
Linking properties:
To print the text contents, use <xsl:apply-templates mode="text" />
The process-diagnostic template handles diagnostic messages for assert statements that have failed and report statements that have succeeded. The diagnostics are evaluated in the context of the rule.
Rich properties:
The process-dir template handles bi-directionality markup, which is only needed by certain human scripts such as Arabic.
The process-emph template handles the markup of emphasized text in paragraphs, assertions and diagnostics. It has no parameters.
The process-message handles default outputing of text.
The process-name templates handle name strings that can be used in assertions. asssert and report only provide name subelements rather than the more general value-of elements to encourage plain language and generic descriptions rather than specific diagnostics, for which purpose the diagnostics elements are used.
The process-ns template reports on ns declarations, which are used to transmit on namespace information by the skeleton.
The process-p template handles paragraphs.
To print the text contents, use <xsl:apply-templates mode="text" />
The process-pattern reports on the start of evaluation of a pattern element.
Rich properties:
To print the documentation contents, use <xsl:apply-templates mode="do-pattern-p"/>
The process-report template handles report whose test has succeeded.
Rich properties:
Linking properties:
To print the text contents, use <xsl:apply-templates mode="text" />
The process-rule reports that a rule element has fired: its context attribute matched some nodes. .
Rich properties:
Linking properties:
The process-span handles span elements, which are generic elements for styling, like HTML's .
The process-title handles title elements, which are generic elements for styling, like HTML's .
By default, titles are handled by invocing process-p with the parameter class with a value "title".
The process-value-of template handles value-of elements, which are used in diagnostic messages to allow very specific hinting .
There are several global parameters that may be available for use. However, it is not a requirement to follow these, and implementations may not supply them with any value. So a test of string-length(variable) < 0 is appropriate in each case.
Parameter |
Value |
Description |
allow-foreign |
"true" | "false" (default) |
Pass non-Schematron elements to the generated stylesheet. Pass the Schematron elements span, emph and dir: to the output SVRL. |
fileNameParameter |
string |
A parameter passed to the Validator and potentially available as a variable in Schematron schemas as $fileNameParameter |
fileDirParameter |
string |
A parameter passed to the Validator and potentially available as a variable in Schematron schemas as $fileDirParameter |
archiveNamePaameter |
string |
A parameter passed to the Validator and potentially available as a variable in Schematron schemas as $archiveNameParameter |
archiveDirParameter |
string |
A parameter passed to the Validator and potentially available as a variable in Schematron schemas as $archivePathParameter |
debug |
“true” | “false” (default) |
Verbose error messages (Note this may be superceded by “verbose” at some stage in the future.) |
generate-paths |
true|false |
generate the SVRL @location attribute with XPaths |
diagnose |
yes | no |
Add the diagnostics to the assertion results |
yes | no | true | false | assert |
Terminate on the first failed assertion or successful report |
|
message-newline |
"true" (default) | "false" |
Generate an extra newline at the end of messages |
output-encoding |
string |
The encoding used for output, for example if the output is XML |