Re: schematron and conformance

Hmmm ... I wonder if Martin & I really disagree, or I just wasn't
clear enough. I tried to remain neutral on the question as to whether
or not passing Schematron constraints (other than those with an @role
of "nonfatal" or "warning") is part of conformance.

I was neutral not because I don't have an opinion on the subject,
just because it wasn't the point of that particular post.

My opinion is:

 * There is no difference whether an *error* is flagged by RELAX NG,
   Schematron, or something else. (Or is not flagged at all, as would
   happen often if you were using DTDs.)

 * We can (and do) use Schematron to deliver messages that are not
   errors. Those should not be considered when thinking about
   conformance.

 * There are a few places where TEI flags a problem and reports it as
   an error where I think it maybe should be changed to "nonfatal"
   (or "warning" or "warn" or whatever), and thus not be considered
   when thinking about conformance.


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