[I realize Martin has already responded, and I think he is correct,
but there is more to say, here.]
> In this particular case, I think that "cannot" is misleading, and
> should be replaced by "should not".
I think you are right. BUT ...
> You *can* use @when together with (say) @notAfter if you don't
> invoke schematron validation.
"Cannot" does not mean that it is impossible for you to type that
combination on your keyboard. Surely "cannot" means it is impossible
for you to use that combination and remain TEI conformant, no?
> 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?
No. IMHO having a deprecated construct in your file does not violate
conformance per se. But to understand my explanation, you will need
to keep in mind that TEI conformance is not a general-purpose
concept, but rather a concept that is expressed in relation to a
particular version. So here is a fictitious scenario. Let's say in
the future TEI Council decides to remove the <head> element from TEI
while 4.12.0 is the current version.
* In P5 version 4.12.0 it is still valid. Use is valid and
* In P5 versions 4.13.0 through 4.16.0 it is deprecated. Use is
conformant but raises a warning. There is a red box and warning
around it in the reference section of the documentation. It is no
longer discussed as a useful method in the prose, and there are no
examples of its use in the Guidelines.
* In P5 version 4.17.0 it is removed. Use is invalid (i.e., raises
an error) and non-conformant. It is not mentioned in the
Guidelines at all (except perhaps nostalgically :-)
(BTW, I don't for a moment suggest that Council would do anything as
dumb as removing the <head> element -- besides being ridiculous, it
would violate our rules on breaking backward compatibility.)