[tei-council] tricky situations for using @validUntil

[Martin Holmes]

Hi Syd,

Responses inline, with the caveat that I'm also not 100% clear that I 
know what I'm talking about:

On 13-12-30 06:49 PM, Syd Bauman wrote:
> I think you may be on to something here, Martin, but my mind is a bit
> fuzzy right now. I'm going to talk it through (aloud) in the hopes of
> straightening myself out.
>
> 1) On 2015-02-14 we put a validUntil=2016-04 on the <pi> elementSpec
>     (which had been introduced back in version 3.14 of the
>     Guidelines).

Right.

> 2) On the 2015-05 build, the P5 build process
>     a. notices that 2015-05 < 2016-04 and does not fail,
>     b. transforms the validUntil=2016-04 into a Schematron test[1]
>        which gets put into p5odds.isosch.
>     In 2015-06 Project Circle generates their customization against
>     the current Guidelines and get that same Schematron test in their
>     .isosch file. When they validate their instances that have <pi>,
>     they get the warning.

Yes, and that's what we would want.

> 3) On the 2017-05 build, the P5 build process notices 2017-05 >
>     2016-04, and fails. The release technician cusses, goes in and
>     removes the elementSpec for <pi>, regenerates, and all is well.

Yep.

> 4) In 2017-10 project Circle makes a change to their customization
>     and re-generates schemas against the 2015-05 version. (This is the
>     situation you were worrying about, yes?) Their customization process
>     puts the Schematron test into their .isosch file. When they
>     validate their instances that have <pi>, they get the warning.

My sense was that because the @validUntil date is actually passed by the 
time the schema is generated, the generation would actually fail -- in 
other words, not a warning but an error. I had assumed that the 
processing of the @validUntil date was a) based on the date of 
processing, i.e. the date on which you're trying to generate the schema, 
and b) produces an outright error at any point beyond that date (as #3 
above suggests). Am I wrong about that?

> I don't think I see a problem for the average Circle project, here,
> but I may be missing something.
>
> On the other hand, if on 2018-10-20 TEI-C Council member Art Tangent
> wants to *build* a 2017-flavored version of P5 itself, he will get a
> build error and it will fail. Is that what you're worried about?

I don't see that Art's situation is different from that of Project 
Circle, who have decided there are lots of lovely things they can't live 
without in the 2015-05 version of P5, and wish to continue generating 
their schemas against that version -- something that, IIRC, we've 
explicitly told them they can do.

>
> Part of me says that's a serious problem, and we have to sort through
> how to fix it. And part of me says we keep built copies of the
> Guidelines around, why would Art need to rebuild it? And on the rare
> occasion he really does need to, he should change his system clock.
> (Blasphemy!)

Definitely blasphemy. Any build system that requires changing your 
system clock is a bit of a disaster.

But if there's actually no Schematron constraint that would cause the 
build to fail with an error after the specified date, then I do see that 
the problem is less serious; but at the same time, I see that there's no 
really useful flag that we ourselves are able to notice as the date goes 
by. I would expect builds to fail once the date is passed, until you've 
got rid of the deprecated <whatever>.

Cheers,
Martin

> Notes
> -----
> [1] <sch:pattern xmlns:sch="http://purl.oclc.org/dsdl/schematron">
>        <sch:rule context="tei:pi">
>          <sch:report test="true()" role="nonfatal">
>            WARNING: use of deprecated element — The TEI-C may drop support for the <sch:name/> element as early as 2016-04.
>          </sch:report>
>        </sch:rule>
>      </sch:pattern>
>      (perhaps with a better worded message).
>
>> 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?