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

[Lou Burnard]

No, of course not, for precisely that reason. Sorry if my note below was 
not clear: I meant to suggest only that the TEI version numbering 
pattern should follow the Unicode one.

Martin Holmes wrote:
>> 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
>>     
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>