Dear TEI-L,

I understand that there are historical and technical reasons that we may
regard Schematron constraints as something different from the sorts of
rules that we might express in DTD or Relax NG or W3Schema (by way of
ODD). But from the perspective of the human, should it matter whether a
particular constraint is implemented in one way, rather than another? As a
human thinking about how I might enhance, constrain, and otherwise adapt
the TEI guidelines to match my project requirements, I might think that
³in a particular environment my project requires tei:X, permits tei:Y, and
prohibits tei:Z². Should it matter, with respect to TEI conformance,
whether I enforce such a project-specific modification with Schematron or
without Schematron? This isnıt meant as a rhetorical question, so Iım
equally happy with responses that skew toward ³yes² and those that skew
toward ³no²; I guess Iım asking whether conformance is just a matter of
what we require, permit, and prohibit, or also of the technology we use to
do that. And, for what itıs worth, I almost never disagree with either Syd
or Martin.



On 2017-26-03, 3:38 PM, "TEI (Text Encoding Initiative) public discussion
list on behalf of Martin Holmes" <[log in to unmask] on behalf of
[log in to unmask]> wrote:

>I actually disagree with Syd here (which almost never happens). For some
>years we've been treating Schematron constraints as an integral part of
>the TEI schemas, and we haven't to my knowledge ever thought of them
>constraints as inferior or optional. If you ask for a new TEI P5 "all"
>document in Oxygen, you get two xml-models:
>	schematypens="
>explicitly referencing the Schematron alongside the RNG.
>I do think we need to make more noise about this, and make it very clear
>that validation should always include the Schematron rules as well as
>the RelaxNG schemas. But if Syd is right, and Schematron is [in future
>defined as] merely nice-to-have, then I think there are a lot of
>constraints that have been defined in Schematron up to now that will
>need to be looked at more closely to see if they can be reimplemented in
>ODD in such a way that schemas can include them.
>On 2017-03-26 12:22 PM, Syd Bauman wrote:
>> Overall true, I think. But of course you can easily tie yourself in
>> knots with discrepancies between the set of documents permitted by
>> the RELAX NG portion of your ODD and the Schematron portion thereof.
>>     <sch:report test="/tei:TEI/tei:teiHeader">Here at the weBbad
>>         project, we do not believe in metadata, and thus
>>         do not allow use of the <gi>teiHeader</gi>
>>         element.</sch:report>
>> But keep in mind that some Schematron constraints are explicitly
>> role="nonfatal". These should not, IMHO, be violations of TEI
>> conformance, whether or not the others are.
>>> When I define my own Schematron constraints and add them into an
>>> ODD, their effect is always to reduce the set of documents which
>>> will be considered valid, by comparison with the set that might be
>>> considered valid by TEI All, or by a version of my ODD without
>>> those constraints. Hence I infer that schematron constraints are
>>> always going to be restrictions rather than extensions of an
>>> existing schema, which means (I think) that adding them has no
>>> effect on the TEI Conformance of my ODD or the documents it
>>> validates. Good.
>>> But what about the constraints which the TEI itself defines ? If a
>>> document is valid against TEI All but fails some TEI-defined
>>> schematron constraint is it no longer TEI conformant? The current
>>> definition (in chap 23 of the Glines) says nothing on the topic.
>>> You could argue that the object of most (or all?) TEI-defined
>>> schematron constraints is to test some semantic constraint
>>> otherwise expressed only loosely in the prose, and conformance with
>>> the TEI semantic model is also a requirement for conformance, so a
>>> document which fails the schematron test is ipso facto non
>>> conformant. You could argue that validation with schematron is an
>>> optional additional extra which shouldn't be required of all TEI
>>> users, since not all validating software supports it.
>>> Just wondering if there are any strong views out there ...