[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