[tei-council] tricky situations for using @validUntil

[Syd Bauman]

Quick recap (see posts in this thread, particularly of 2013-12-10
14:26 and 2013-12-13 14:32 for details):

We'd like automated ways both of warning users of soon-to-be-
deprecated constructs and of having a P5 build fail after a certain
date if the deprecated thingy has not been removed. @validUntil does
this reasonably well for constructs (at least for elements and
attributes). However, using @validUntil to deprecate not a construct,
but rather a particular use of a construct, is a problem. Possible
solutions include the following.

1a) Change semantics of constraintSpec/@validUntil to mean "this
    constraint kicks in after @validUntil date" rather than the usual
    "the thing this attr is attached to becomes invalid after date".
    The logic here is that the constraintSpec is flagging an
    *invalidity*. So the thing is valid until X, after which the
    invalidity should be flagged.[1]

1b) Use an attr on constraintSpec that is like the "reverse
    @validUntil" described in (1a), but call it something else, e.g.
    @errorUntil.

2) When this kind of problem occurs, move the deprecated use of the
   element or attribute to a class of its own, and put @validUntil on
   that <classSpec>.

3) Do it by hand. (Kevin has already objected, quite reasonably, to
   this solution.)

4) Generate <constraintSpec>s by hand, either using att.datable to
   control when they are built, or XPath date comparisons to control
   when they are fired. (Martin likes this, Sebastian does not.)

5) Use a PI. (Sebastian has raised a mild objection that I think does
   not hold water. See [2].)

IMHO, we should decide this pretty soon so I can get on with my
actions. No one has commented on (2), which is really the most
ODD-like way of doing this, isn't it?

Notes
-----
[1] This nicely fits the logic of closed vs open schema languages. In
    our closed, grammar-based schema language (RELAX NG), anything
    that is not explicitly allowed is forbidden. Thus @validUntil
    means "this explicit permission will be withdrawn". In our open,
    rule-based schema language (ISO Schematron), anything that is not
    explicitly forbidden is allowed. Thus @validUntil means "this
    explicit prohibition will go into effect".

[2] As for using PIs, I think there is a strong argument in favor.
    They can go *anywhere*, are not explicitly part of the ODD
    language (which might be soon as an advantage or as a
    disadvantage), and (most importantly) the main thing we want here
    is actually an instruction to the processor! (To wit, "fail after
    date".) HOWEVER, there is also a bit of a drawback: the content
    of a PI isn't parsed by the XML parser for us. So code that does
    stuff with a PI has to parse it itself. This would make both the
    actions I'm working on (generate warning messages for users) and
    getting the build process to fail a bit harder.