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

[Martin Holmes]

I don't think this is a minor issue at all; I think it's essential that 
the policy on version numbering for TEI be clear and clearly documented. 
It's the sort of thing that will dictate processing pathways for 
automated processes.

I think I'm with Lou on this one: I think "P5" should be an informal 
human designation for the 5.x tree, and I favour 
"major.minor.build.revision" or "major.minor.build.release" for the four 
components. We should encourage people to include full version numbers 
in the TEI/@version of their data files if they know them, but in many 
cases, this is going to be impossible. If I encode a lot of data using a 
schema generated with 5.1.20, then update my schema to 5.2.0, but the 
update doesn't change the validity status of my files, should I have to 
change all my data files?

So perhaps we should encourage a more generic:

<TEI version="5">

where it's not practical or helpful to be more precise about the version 
number.

Cheers,
Martin

On 10-05-15 10: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
> .
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)
Half-Baked Software, Inc.
(mholmes at halfbakedsoftware.com)
martin at mholmes.com