[tei-council] @source urns and @version datatype bug
O'Donnell, Dan
daniel.odonnell at uleth.ca
Mon May 17 15:57:19 EDT 2010
Thanks Lou for clarifying this. I prefer either of the options in your
#3. In honour of my old political alma mater, the lib dems, I'll use a
transferable alternative vote to prioritise:
1) Use a 4 digit @version for the TEI elements
or failing that
2) Use @version="5" @release="1.2.3"
I suppose a third option might be to have either @unicodeVersion or
@teiVersion against @version if you wanted to avoid using different
constraints on identically named attributes.
-dan
On 10-05-17 01:39 PM, Lou Burnard wrote:
> There seem to be some misunderstanding about this issue. Let me try to
> state the situation again.
>
> 1. We have @version on unicodeName and on TEI. The former is defined (by
> Unicode) as 3 numbers 1.2.3 and we are not at liberty to change it! It
> refers to the version of the Unicode standard, of course, and has
> nothing to do with the TEI version.
>
> 2. We can define whatever we like for our own version number. I am
> merely proposing that it might be economical to use the same pattern as
> we are obliged to use for the unicode version. That in turn means that
> we have to do the admittedly slightly unwholesome business of
> concatenating the two final figures in the (comparatively rare) case
> where we have something like 1.2.0 and 1.2.1 , if you agree with me that
> there is a "5." at the start of every version number for P5, and if you
> agree with me that we want to use the same pattern as we do for
> unicodeName. Of course, you can disagree on either or both points -- but
> let's try to reach a speedy conclusion, as it matters.
>
> 3. We could make a distinction between "version" and "release" and have
> two attributes -- so release 1.2.0 of P5 would be @version="5" and
> @release=1.2.0. Or we could use a different four number pattern for
> @version and allow 5.1.2.0
>
> 4. This matters because we need to decide on a single way of refering to
> specific releases/versions which is now possible using the @source
> attribute on ODD *Ref elements
>
> O'Donnell, Dan wrote
>
>> Hi James,
>>
>> I vaguely remember this discussion. I was a fan of 5.x.x but lost, as I
>> remember (though apparently not in practice). I have a couple of
>> questions/comments about this:
>>
>> 1) Does this mean that 5.1.2.2 is impossible? (i.e. is there some
>> enforcement on the idea that you can only have two periods and three
>> sets of digits)
>> 2) My problem with your suggestion "Thus someone could use 1.2.3 for
>> @version on unicodeName but P5:1.2.3 on TEI or indeed 1.2 or 1, or 3.11,
>> or 3.4.5, etc." is that the stripped form on unicodeName is missing some
>> pretty crucial information: the "edition" number. How would distinguish
>> between unicodeName/@version="1.2.3" from P4 or (god help us, P6) from
>> unicodeName/@version="1.2.3" from P5? It would be like referring to
>> Ubuntu release .4
>>
>> I agree with you that 1.2.34 when you want to say 1.2.3.4 is terrible as
>> well. But it sounds like we might be constrained by datatypes?
>>
>>
>> On 10-05-15 11:51 AM, James Cummings wrote:
>>
>>
>>> Hiya,
>>>
>>> Lou checked in some changes recently to the TD chapter and the TEI
>>> elementSpec as a result of the earlier discussion on schemaSpec/@source
>>> and the TEI/@version attribute. One of them struck me as just
>>> unintuitive and unclear for users so I wanted to highlight it. I've
>>> already discussed it with Lou and I believe understand his reasons (for
>>> which I have a certain sympathy), but wanted to comment on it because of
>>> its implications.
>>>
>>> At lines 1174-1188 of
>>> http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Guidelines/en/TD-DocumentationElements.xml?revision=7524&view=markup
>>> It says:
>>>
>>> ====
>>> <p>The value for the<att>source</att> attribute may be a specific URL
>>> as in the preceding example, or any other form of URI. A set of
>>> TEI-conformant specifications in a form directly usable by an ODD
>>> processor must be available at the location indicated. When no
>>> <att>source</att> value is supplied, an ODD processor may either raise
>>> an error or assume that the location of the current release of the TEI
>>> Guidelines is intended.</p>
>>> <p>If the source is specified in the form of a private URI,
>>> the form recommended is<code>tei:x.y.z</code>, where
>>> <code>x.y.z</code> indicates the version number,
>>> e.g.<code>tei:5.1</code> for the most recent version of P5 release 1,
>>> or<code>tei:5.2.11</code> for release 2.1.1 of P5. When such a
>>> URI is used, it may be necessary to remove or translate it before
>>> such a file can be used in blind interchange.
>>> </p>
>>> ====
>>>
>>> What I'm uncomfortable with is the eliding of the last two digits of our
>>> published version numbers to form 5.2.11 from TEI P5 version 2.1.1 in
>>> the example given. This seems unintuitive and a very non-standard way to
>>> treat version numbers. (We are currently on 1.6.0 and this is on every
>>> HTML page of the Guidelines.)
>>>
>>> In addition I'm reluctant to call TEI P5 version 2.1.1 version '5' dot
>>> anything. By that I mean that mentally I separate TEI major releases
>>> (editions) and version numbering which I view as integral to an edition.
>>> (i.e. For TEI P6 we may also have a version 2.1.1, and Lou would
>>> sensibly number this 6.2.11 whereas I would number this P6 2.1.1).
>>> Moreover when we move from 1.9.x to 2.0.x I seem to remember us deciding
>>> that this would indicate a major change release, not as significant as
>>> moving to P6, but significant nonetheless. Partly I worry about this
>>> because we may indeed soon have a TEI P5 versions where the second
>>> numeral of the 1.6.0 version number will be in double-digits and that
>>> might cause even more confusion when eliding digits because we have
>>> referred to releases occasionally where we have dropped the
>>> minor-release number at the end. (e.g. we refer to 1.0, 0.9, 0.5, etc.)
>>>
>>> I recognise Lou's desire here in providing a straightforward tei: URN,
>>> but in this case I'd be more tempted to suggest this should be
>>> tei:p5:2.1.1 so in the form of 'project':'edition':'version'.
>>>
>>> But really what the discussion with Lou brought to my attention is that
>>> the default value of @version on the TEI element is '5.0' and in the
>>> example given it is '5.1.20' in the revision recently checked into
>>> subversion.
>>>
>>> http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/TEI.xml?revision=7478&view=markup
>>>
>>> Yes, it would be good to rationalise @version attributes across elements
>>> (not done yet)... something I generally wholeheartedly encourage.
>>>
>>> However to me 1.2.0 is very different from 1.20 and I view the P-release
>>> numbers as entirely distinct and different from the version numbering of
>>> individual versions within any P-release number.
>>>
>>> My proposed solution would be to create a pattern for the @version
>>> attribute's datatype which allows both:
>>> a) 1, 2, or 3 digit version numbers separated by full-stops
>>> b) an optional P#: before a)
>>>
>>> Thus someone could use 1.2.3 for @version on unicodeName but P5:1.2.3 on
>>> TEI or indeed 1.2 or 1, or 3.11, or 3.4.5, etc.
>>>
>>> I believe having P#: prefix to the version number more clearly
>>> distinguishes the nature of P-editions than just having it be a major
>>> version number.
>>>
>>> I guess it comes down to whether you believe we are currently at TEI
>>> version 5.1.60 or whether you believe we are at TEI P5 version 1.6.0. I
>>> believe the latter, and feel that the minor-change number of the
>>> intermediate version numbering is potentially significant.
>>>
>>> I would also like to argue that this is what the TEI Council decided
>>> previously. If you look in the archive starting at 2007-11-06 in a
>>> message from Sebastian entitled "how to release errata, versions etc"
>>> you'll see that he says:
>>>
>>>
>>>
>>>
>>>> I am proposing that we start thinking about this as "P5 release 1.0",
>>>> "P5 release 1.0.1" etc. so "P5" is the name of the deliverable, not
>>>> the version number.
>>>>
>>>>
>>>>
>>> And that day Syd also provides an eerie warning from history:
>>>
>>>
>>>
>>>
>>>> I'm
>>>> presuming P5 is version major.minor.bugFix, like lots of other
>>>> things. But this does raise problems with our version= attribute.
>>>>
>>>>
>>>>
>>> Syd wrote:
>>> Christian wrote:
>>> Sebastian wrote:
>>>
>>>
>>>
>>>>>> I am proposing that we start thinking about this as "P5 release
>>>>>> 1.0", "P5 release 1.0.1" etc. so "P5" is the name of the
>>>>>> deliverable, not the version number.
>>>>>>
>>>>>>
>>>>>>
>>>>> I thought we already agreed on this, no?
>>>>>
>>>>>
>>>>>
>>>> That is what we decided, but not what we did. The default for
>>>> version= is "5.0", and its datatype is xsd:decimal.
>>>>
>>>>
>>>>
>>> And Christian later commented:
>>>
>>>
>>>
>>>
>>>> This looks like a corrigible error then.
>>>>
>>>>
>>>>
>>> (The discussion continues and is important historically as it is where
>>> we decided to make six-monthly maintenance releases... but that this bug
>>> needs correcting drops off the radar and obviously never got fixed.)
>>>
>>> I know this dissection seems quite intense for something so trivial, but
>>> I wanted to make sure I got what we had decided previously accurate.
>>>
>>> Thanks for reading this.
>>> -James
>>> _______________________________________________
>>> tei-council mailing list
>>> tei-council at lists.village.Virginia.EDU
>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>
>>>
>>>
>>
>>
> i
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
--
Daniel Paul O'Donnell
Professor of English
University of Lethbridge
Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/)
Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America
President-elect (English), Society for Digital Humanities/Société pour l'étude des médias interactifs (http://sdh-semi.org/)
Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/)
Vox: +1 403 329-2377
Fax: +1 403 382-7191 (non-confidential)
Home Page: http://people.uleth.ca/~daniel.odonnell/
More information about the tei-council
mailing list