Print

Print


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:

<?xml-model 
href="http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng" 
type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>
<?xml-model 
href="http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng" 
type="application/xml"
	schematypens="http://purl.oclc.org/dsdl/schematron"?>

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.

Cheers,
Martin

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 ...