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

[Martin Holmes]

> I have for the
> moment defined a new datatype data.version which matches the Unicode
> spec, and propose we restrict ourselves to that.

Have you applied this new datatype to application/@version? If so, it 
will break backward compatibility.

Cheers,
Martin

On 10-05-08 01:36 PM, 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.
>
> 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.
>
>
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council