[tei-council] new validUntil=

[Syd Bauman]

I'm working on our new validUntil= attribute, and quite a few mildly
thorny issues are raised. What I've done so far has just been checked
in at revision 12101. We'll see if Mr. Jenkins agrees with me that
it's all OK.[1]

1. datatype
-- --------
The natural datatype for validUntil= would seem to be
'data.temporal.w3c'. But were we to do this, then I think the test
for "is the validUntil= in the past" would be horrific. This is
because (AFAIK), we can't easily do temporal comparisons across W3C
datatypes. Thus we would need at a minimum 8 Schematron rules with
different contexts. Something like
   <sch:rule context="tei:*[@validUntil castable as xsd:date]"> ...
   <sch:rule context="tei:*[@validUntil castable as xsd:gYear]"> ...
   <sch:rule context="tei:*[@validUntil castable as xsd:gMonth]"> ...
   <sch:rule context="tei:*[@validUntil castable as xsd:gDay]"> ...
   <sch:rule context="tei:*[@validUntil castable as xsd:gYearMonth]"> ...
   <sch:rule context="tei:*[@validUntil castable as xsd:gMonthDay]"> ...
   <sch:rule context="tei:*[@validUntil castable as xsd:time]"> ...
   <sch:rule context="tei:*[@validUntil castable as xsd:dateTime]"> ...
And then, we'd need to decide and figure out what it *means* to
specify a validUntil= date that is only a month and day, or only a
time.

Seems to me it makes sense to restrict to only dates. I think it is
OK to allow time zones in these dates (as silly as that might be), as
dates with or without timezones can be compared to current-date().

Thus I have used xsd:date as the datatype. This runs counter to the
idea that we should always use TEI defined datatypes. Should we make
a new "data.date.w3c" datatype? If so, should we also make the 7
others? (When does this become silly?)

2. class
-- -----
We agreed to make the new validUntil= attribute in a new class of its
own. Am I correct that the only member of this class should be
att.combineable?

3. Schematron problems
-- ---------- --------
I'll try to post bug reports soon about some problems I've noticed w/
Schematron use in the Guidelines. This is really here as a
placeholder and a reminder to myself. (And permission for y'all to
bug me about it in a couple of weeks if I haven't said anything :-)

4. status of "deprecated" of status=
-- ------ -- ------------ -- -------
I presume that the "deprecated" value of the status= attribute of
att.identified is the first thing to be deprecated with the new
validUntil= attribute, and have done so. Should the entire status=
attribute of att.identified be deprecated by validUntil=, or do we
think status= still serves a purpose? We do not (currently) use any
value other than "deprecated" in the source of the Guidelines.

I presume that the "deprecated" value of the status= attribute of
att.docStatus should be left alone.

5. ODD processing
-- --- ----------
The roma stylesheets should be updated to do the right thing. I am
not sure whether I am hoping that Sebastian gets to this before I do
to spare me the hassle, or that I get to it before Sebastian does
just to get more experience mucking with the ODD stylesheets.

6. Chapter
-- -------
I have *not* documented this attribute in chapter TD yet. I thought
I'd leave the definition lying around for a week or two to see if
there were any problems or suggested changes, first.

7. tests
-- -----
I have not added any tests in P5/Test yet. Should we? Since the only
important tests are based on the current date, it seemed a bit
problematic, if not silly. I suppose we could test that
validUntil=3015-05-16 doesn't fire and that validUntil=1015-05-16
does. But we can't really test the equality test easily.

8. ODD oddity
-- --- ------
In order to get a valid DTD out of roma, I found that I had to put
predeclare=true on the <classSpec>, not the <attDef>. Is that the
intended behavior?

Note
----
[1] Well, almost. My local build gives 1 java error, apparently from
    `trang` translation of RNG to XSD of an Exemplar, I think of
    tei_tite. Will that cause Mr. Jenkins to fall over?