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

[O'Donnell, Dan]

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
>    

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