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

[Kevin Hawkins]

Responses below ...

On 08/05/2010 21:36, Lou Burnard wrote:
> 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.

Restrict ourselves to data.version for what exactly?  The values of 
@version on TEI, teiCorpus, and unicodeName?

> 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.

If the @version that's part of att.translatable is only used internally 
by the TEI and never included in ODDs produced by Roma or Vesta, then, 
as you say, renaming this attribute wouldn't break backwards 
compatibility.  However, I am not so troubled by having an attribute 
called @version in att.translatable with a different datatype (and 
semantics) from the @version on TEI, teiCorpus, and unicodeName, which 
have their own datatype and semantics.  So if it's a lot of trouble to 
fix, I would just leave it.

Kevin