[tei-council] @source urns and @version datatype bug
James.Cummings at oucs.ox.ac.uk
Sat May 15 13:51:55 EDT 2010
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
At lines 1174-1188 of
<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.
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
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
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:
> presuming P5 is version major.minor.bugFix, like lots of other
> things. But this does raise problems with our version= attribute.
>>> 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.
More information about the tei-council