[tei-council] tricky situations for using @validUntil

[Kevin Hawkins]

I am sympathetic to Syd's footnote number 1, but of course this would 
require that we rewrite the definition of @validUntil (at 
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.deprecated.html 
) into something incredibly convoluted that covers both situations.  I 
would fully expect questions from future Council members and even users 
of the TEI about why we decided these two very different things should 
use the same attribute, much as we've been carefully unconflating things 
like @rend and @type on <list>.

So this makes me think we should go with (1b), except maybe named 
@warningUntil.  Regardless what we call this attribute, how would the 
build process treat this after the date has passed?  Treat the 
Schematron warning as a Schematron error to remind us to remove this 
along with the deprecation?

K.

On 12/30/13 10: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.
>