[tei-council] @version (SF bug 2932853)

[Lou Burnard]

A @version attribute exists on each of the elements <application>,
<teiCorpus>, <TEI> and <unicodeName>. A similarly named attribute is
also supplied by the class att.translatable, members of which are
desc, exemplum, gloss, remarks, and valDesc. The datatypes specified
for this attribute vary, as follows:

1. On att.translatable it's data.word and there is a note saying "The
version may be a number, a letter or a date"

2. On <application> it's a token matching a specific RNG pattern
[\d]+[a-z]*[\d]*(\.[\d]+[a-z]*[\d]*){0,3}

3. On <TEI> and <teiCorpus> it's explicitly a W3C decimal number.

4. On unicodeName its the TEI-defined data.numeric (which matches all
sorts of things)

Obviously the datatypes for @version on TEI, teiCorpus, and
unicodeName are just plain wrong (the first two don't match our actual
current practice, and the last doesn't match the Unicode
requirement). In an ideal world, we'd like attributes with the same
name to have the same datatype, so one solution would be to give
everything the same datatype as <application>. Unfortunately the
pattern defined there is too permissive for either Unicodename or TEI
version (neither permits letters or a 4th number), so I have for the
moment defined a new datatype data.version which matches the Unicode 
spec, and propose we restrict ourselves to that.

There remains the problem of the @version provided by in the
att.translatable class, which is uniformly a date, with hyphens
separating the parts. We could at a pinch make that conform to the
same pattern by permitting hyphens as well as dots in the pattern, but
that I think that would be cheating. We could consider renaming the
@version you get from att.translatable to "translateDate" or some
such; so far as I know the attribute is only used for internal ODD
processing by the TEI so the compatibility issue is less severe. Note
that the semantics of this @version are quite different from the
others -- it carries the date when an ODD component was last
*translated* which is usually quite different from when the ODD
component itself was last modified, and nothing to do with the version
number of the P5 release into which that component was eventually
incorporated.

There is an outstanding issue about how the @version on these
translateable elements should be used in our workflow specifically how 
we ensure consistency when the English language version has changed and
the translations have not.