Print

Print


In this particular case, I think that "cannot" is misleading, and should 
be replaced by "should not". You *can* use @when together with (say) 
@notAfter if you don't invoke schematron validation. Council decided 
that this combination of attributes didn't make sense, and therefore it 
would be helpful to deprecate the practice. But you cannot actually make 
deprecated behaviour impossible, which is what "cannot" means to me.

My question remains unanswered however: is a TEI document which indulges 
in deprecated (in another context Michael has suggested the term 
"deviant") behaviour ipso fact non TEI conformant?




  On 27/03/17 02:59, Martin Holmes wrote:
> 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.