> You *can* use @when together with (say) @notAfter if you don't invoke
> schematron validation.
and you *can* use <anyoldthing> inside <TEI> if you don't invoke RelaxNG
As far as I remember, the decision to express a constraint in a
Schematron rule as opposed to a construct that translates into RelaxNG
has never been made on the basis of the rule's supposed regulatory force
(for want of a better way of putting it); it's always been made on the
basis of practicality (we can't do this [yet] in ODD/RelaxNG). Therefore
I don't believe it makes sense to say that these constraints are in any
way less significant than regular constraints, except in the case of
deprecation warnings, which are explicitly warnings rather than errors.
On 2017-03-27 04:13 AM, Lou Burnard wrote:
> 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>
>> 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
>>> I was neutral not because I don't have an opinion on the
>>> subject, just because it wasn't the point of that particular
>>> 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
>>> * 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:
>>>> 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.