[tei-council] tricky situations for using @validUntil

[Martin Holmes]

Thanks Syd for the summary. I don't recall anyone having raise this 
additional issue:

We've been telling people that they can build their TEI project against 
any TEI version in the Vault if they want to. However, once a validUntil 
date expires, even if they're building against an old version in dating 
from a period when it had not expired but was only deprecated, they'll 
still get an error, won't they?

If so, I think this is unfortunate. I wonder if we ought to be thinking 
of our @validUntil in terms of TEI version numbers rather than dates.

Or am I missing something?

Cheers,
Martin

On 13-12-30 07:43 AM, Syd Bauman wrote:
> 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.
>