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

Lou Burnard lou.burnard at oucs.ox.ac.uk
Sun May 9 11:00:10 EDT 2010


James Cummings wrote:
> Am I the only one who thinks maybe we should have a att.versionable or 
> something class which provides @version? And moreover that this should 
> not be tightly constrained at this location?  I'm doubting that with all 
> sorts of different possibilities for version-numbering that there is a 
> single pattern which matches them all.  So maybe we should have it not 
> constrained that much at all, but give examples of constraining it to 
> tighter datatypes as customisations?
>   

I am not sure what an attribute class would buy us here, precisely 
because the different @versions all need to have different datatypes.  
unicodeVersion/@version is constrained by Unicode, not us, so all I 
thought reasonable to do is (a) provide a corresponding datatype (b) 
explicitly tie TEI/@version to it. If I defined a class I'd have to 
decide what the default dataype would be and/or make it very 
unspoecific, and then modify it for all the other non default cases, 
which just looks like unnecessary work to me.
> I see this as related to the underlying ODD problem of needing to 
> further constrain certain aspects of an element/attribute definition. 
> e.g. we have an attribute that has this unspecific datatype in its 
> attribute class, but here we have an instance of it that we've further 
> constrained. Or, we have an attribute that has a particular definition 
> (a version number) which in this particular location needs to be 
> constrained further (say, version number of the applicable release of 
> TEI).  We have many instances of attributes which are not in classes 
> primarily because they have slightly different definitions.
>
> -James
>
> Lou Burnard wrote:
>   
>> 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
>>>   
>>>       
>> _______________________________________________
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>     
>
>   



More information about the tei-council mailing list