[tei-council] One Licence Does it all

O'Donnell, Dan daniel.odonnell at uleth.ca
Tue Aug 10 16:55:58 EDT 2010


I think people are confusing a couple of different things here, and that 
it is worthwhile to get them straight so that we understand what we are 
wanting to do and why others are acting the way they are.

The first issue has to do with a canonical Tite and Apex's 
implementation of it at any one moment. I am frankly failing to see why 
this is getting everybody so riled up. We do not demand that any actual 
users reflect the real-time status of the latest version of a TEI ODD. 
Instead--and this is why we've been concerned about version numbers and 
the like lately--we expect them to derive /a/ version drawn, customised, 
extended, or whatever, for their own internal use. I imagine that we 
assume that such users will return every so often to the fount to update 
the version they are using in house. But I'd be surprised if a majority 
of us really through that users use the TEI through daily builds as it were.

The same is true of Tite and Apex. They can't be expected to use the 
bleeding edge version to train their keyboarders (were Tite part of our 
regular revision programme, which it isn't yet--though thankfully that's 
about to change). They need to have a temporarily fixed schema that 
nails down some decisions for a reasonable period of time. And then, 
like we hope all users, they will presumably return to the source every 
so often to adopt the changes and improvements that the TEI have 
introduced in the meantime. So we should always expect that there will 
be differences between the most recent TEI ODD and the version used by a 
project or programme like AccessTEI, the main exception perhaps being on 
the day the update their schemas.

The second thing to keep in mind is that the Canonicalisation of Tite is 
in fact something like a reverse fork: Perry developed Tite on the basis 
of schemas used by major libraries for their digitisation projects which 
were in turn developed from the TEI. And he built it as a customisation. 
As the TEI takes over on-going development and maintenance, the main 
task is naturally going to involve discovering and reconciling the bits 
where the forking happened.

A second implication of this reverse forking is that Perry, and Apex, 
have been working without the usual support mechanisms and workflows we 
all expect and value in everything the TEI does with things it controls 
officially--so things like sf ticket workflows were not obviously 
established. When they needed to do things--for example, like adjust 
documentation so that it didn't include examples and text that referred 
to other things not in Tite--it made reasonable sense to handle this 
in-house rather than wait for the TEI to establish a maintenance 
mechanism for it. I think it is a very positive reflection on the people 
involved that much of this work was in fact done in ways that maintained 
the connection to the Guidelines and the ODD mechanism more generally. 
Our work on the ODD in Dublin, including particularly the ability to 
positively include rather than negatively eliminate elements and the 
development of a robust system for indicating versions and sources is a 
direct result of issues discovered during the Apex/Tite review. Many 
other users of the TEI do similar reviews and evaluations and make 
similar changes in far less responsible ways even when they have access 
to the established ticket system we use for our other ODDs. And these 
guys were working under commercial pressure--including from us--to get 
the work done.

Rather than concentrating on what's wrong or what we would have done 
differently if Tite had been designed as an official project and run 
from the beginning within our workflows and processes, I think we should 
be looking at what we can now do to make Tite and its user base work 
better and more closely within the TEI (finish reversing the fork so to 
speak). We claim we want to encourage people to develop customisations; 
we also claim that we are interested in having commercial and 
quasi-commercial instances take up the ODD the TEI and develop 
appropriate task-oriented customisations. Tite has been a leader in this 
area, and, like any pathfinder, has discovered all the bumps and detours 
in the road that we'll be able to smooth out for others. We have already 
benefited significantly from the relationship. Also we should remember 
that it is only know we seem able to do this: when the subject came up 
in Nancy, we left it on the table because we didn't really know what to 
do about making it "official." The fact we can develop a real plan now 
is probably a sign that things have developed enough to allow us to do 
it profitably now.

Rather than railing about law suits and god knows what else, maybe the 
thing to do is to simply place Tite in the ticket system, start 
maintaining it, and let people involved know how they can contribute. 
Given that we haven't been maintaining Tite this way yet, we will have 
to take a deep breath and realise that implementing a process like this 
will mean re-proposing ideas and comments that got missed when it wasn't 
enjoying such a robust maintenance system and introducing tickets based 
on proposals that were initially introduced in ways that we deprecate.

I have the impression we are pushing (sometimes even a little rudely 
perhaps) against an open door. I don't know anybody who does not want to 
see the same end goal: a canonical, TEI maintained and supported Tite 
ODD with a regular release schedule and all the benefits of the ticket 
system and the like. And I don't know how people can be clearer about 
their willingness to work with us than indicating that they'd love to 
and they are happy with everything we propose. If we can't handle 
working with people who really want to work with us and have immense 
good will towards us, then I don't see us ever succeeding in our desire 
to work further with academic publishers, many of whom have a much 
heavier investment in their own ways of doing things and less of an 
intrinsic desire to work with the TEI. So this is also a test of us and 
how honestly we are interested in working with others, as well. This is 
perhaps especially true of our ability to work with commercial entities 
like Apex. They really don't deserve some of the acrimony they have been 
shown, both here and when they were in Michigan.


On 10-08-10 01:18 PM, Sebastian Rahtz wrote:
> On 10 Aug 2010, at 19:41, Perry Trolard wrote:
>    
>> If this is the recommended course, perhaps Dan&  I should compare notes
>> about pending changes to Tite coming out of Apex, then I can file
>> tickets for each.
>>      
> which seems weird. Apex can't change TEI Tite, only we can do that. They should
> be submitting bugs or feature requests, which we implement
>
>    
>> (Dan, I recall that we were waiting on the results of a review of Apex's
>> schema from an outside party [David Seaman?],
>>      
> even weirder. What on earth is a review of the schema all about? or is this a different
> schema?
>
> I am afraid I don't feel the TEI Board, or sub-committee thereof, has handled
> this Apex thing very well. To find such a lack of clarity about fundamental
> aspects like licensing, authoritative files, and maintenance procedures, so late
> in the day is disturbing.  I may be told, of course, that this was all done by the
> TEI/Apex work team, and its all sorted - but that would bring me back to asking
> exactly who is in charge of this customization and its offshoots?
>
>
> --
> Sebastian Rahtz
> Information Manager, Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> Sólo le pido a Dios
> que el futuro no me sea indiferente
>
>
>
>
> _______________________________________________
> 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/




More information about the tei-council mailing list