Re: schematron and conformance

Sorry if I misunderstood you Syd. There are currently 74 Schematron 
assertions and reports in the P5 source, of which only 9 have 
@role='nonfatal'; 4 of those relate to deprecations, so they are 
certainly advisory, but others are rather strange:

<constraintSpec ident="att-datable-w3c-when" scheme="isoschematron">
     <constraint>
       <sch:rule context="tei:*[@when]">
         <sch:report test="@notBefore|@notAfter|@from|@to" 
role="nonfatal">The @when attribute cannot be used with any other 
att.datable.w3c attributes.</sch:report>
       </sch:rule>
     </constraint>
   </constraintSpec>

The report says "cannot be used", which is pretty categorical; I don't 
see how this could be both accurate ("cannot") and nonfatal/advisory. 
All five of the "nonfatal" rules which are not related to deprecation 
explicitly use the word "cannot". This just seems wrong to me. If 
they're really advisory, they should use different terminology, surely.

Cheers,
Martin

On 2017-03-26 03:36 PM, Syd Bauman wrote:
> 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.