[tei-council] @source urns and @version datatype bug

Lou Burnard lou.burnard at oucs.ox.ac.uk
Mon May 17 15:39:14 EDT 2010

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

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

More information about the tei-council mailing list