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

[James Cummings]

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