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

[James Cummings]

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