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