<lg type="spoof" sample="initial">
<l>Schematron one-point-four, what shall we do?</l>
<l>Is anyone left who wants to use you?</l>
Information about the original can be found at
And yes, that's a somewhat questionable use of @sample.
If you use <constraintSpec> in your customization (i.e. ODD) file,
please let us know which category you fit into:
A. I depend on Schematron 1.x, and either cannot or don't want to
change to ISO Schematron. Please don't remove support for 1.x.
B. I don't use Schematron 1.x. Do whatever you want.
C. I use Schematron 1.x, but have been looking for an excuse to
change to ISO Schematron. Please remove 1.x.
D. Why are you even asking about a language that has been outdated
for 7 years? Just remove 1.x and go on with your lives.
[If you don't want to post to the list, feel free to reply to me
The TEI Guidelines support and use the capability to express formal
constraints above and beyond those expressed in the TEI RELAX NG
schema produced by customization. An example is the constraint
that a @spanTo attribute should point forward in the document, not
backwards. These extra-RELAX NG constraints may currently be
expressed in one of four ways:
* "schematron": in the original Schematron language 
* "isoschematron": in the ISO Schematron language 
* "xsl": in XSLT
* "private": in anything else, including non-XML languages
The TEI Guidelines themselves have not used anything other than
"isoschematron", which superseded Schematron 1.6 in 2007, for years.
The TEI Customization processing provided by the TEI (e.g. in Roma,
Byzantium, or the stylesheets built into oXygen) supports
"schematron" and "isoschematron", but not "xsl" (and obviously not
"private"). However, support for "isoschematron" is stronger than
support for "schematron".
The TEI Technical Council is seriously considering dropping support
for the original Schematron language. I am writing to find out if
this would be a significant hardship on anyone in the community.
For users, dropping support for the original Schematron language would
not necessarily mean that they have to change to the ISO Schematron
language. But it does mean they would have to change from the
original Schematron language if and when they wish to process their
ODD file against future versions of the Guidelines.
For the TEI Council, dropping support for the original Schematron
language means less time working on something that not only don't we
use, but, as far as we know, no one else uses either. Thus more time
to work on other issues. (And there are a *lot* of other issues. :-)
If we do remove support for the original Schematron language, the
general method would be something like the following.
1) The value "schematron" would be deprecated -- the documentation
would indicate that it should be avoided, and those who use it
would get a warning on validation.
2) The Council would no longer put significant time into work on
improving the processing of Schematron 1.x. However, the
processes would continue to work, and significant bugs might still
3) ~1-2 years after steps (1) and (2) start, the value "schematron"
would be completely removed. The documentation would no longer
mention that value, and those who use it would get an error on
4) The code that processes the original Schematron language would
(eventually) be removed.
 Or the DTD or the W3C Schema; but since the constraints expressed
in these languages are (currently) a subset of those expressed in
RELAX NG (although not necessarily a proper subset), it is not
necessary to mention them explicitly. But I just did. :-)
 Schematron versions 1.3, 1.4, 1.5, or 1.6 to be precise. See,
for details on the latest version, but note that even this latest
version has been superseded by ISO Schematron.
 <ref target="http://www.schematron.com/">
ISO/IEC 19757 - DSDL Document Schema Definition Language -
Part 3: Rule-based validation - Schematron
Syd Bauman, EMT-Paramedic
Senior XML Programmer/Analyst
Northeastern University Women Writers Project
[log in to unmask] or
[log in to unmask]