[tei-council] update from the TEI Tite task force
laurent.romary at inria.fr
Tue Dec 14 10:04:49 EST 2010
I agree that we need to be cautious with the changes we implement on
Tite at TEI (as I named it in early mail exchanges before the summer).
The sourceforge ticket is in particular there for people to react on
things which we may drop and which, beyond the idiosyncrasies of
specific projects, would be worth keeping.
On your last point, we are combining 1) and 2), in the sense that
Tite at TEI is intended to be a reference customization for interactions
between TEI-based projects and conversion vendors, but also, since
Access-TEI is a major initiative for the consortium, we want to make
sure that the schema we maintain is straightforwardly useful for this
@Kevin: would you want top ask the TEI-L for feedback on some of the
Le 14 déc. 10 à 15:56, David Sewell a écrit :
> Council people,
> I would suggest that before any final decisions are taken on canonical
> TEI Tite, feedback should be requested from the membership via TEI-L,
> particularly to solicit input from people who have actually been using
> TEI Tite for encoding projects (with or without conversion vendors).
> I'm reasonably sure, for example, that we've asked a conversion vendor
> to use some of the "unnecessary elements and attributes" mentioned in
> Sourceforge ticket 3136934 in an encoding based on TEI Tite. As we
> in fact already customized Tite for our local practice (this is not a
> project going via AccessTEI), it might not be a hardship to revise our
> ODD later to explicitly include anything we need to use.
> But I think Council/Board need to decide whether (1) TEI Tite is a
> customization primarily designed to meet the needs of AccessTEI/Apex
> CoVantage plus anyone else who wants to adopt their precise encoding
> practice, or (2) TEI Tite is a customization to provide a lingua
> for use between TEI-based projects and conversion vendors, including
> not limited to formal AccessTEI work. (Or has that decision already
> made and documented somewhere?)
> On Mon, 13 Dec 2010, Kevin Hawkins wrote:
>> Colleagues, a happy holiday season to you.
>> A brief report on progress by the task force that Laurent charged
>> aligning the TEI Tite schema maintained by Council (and hosted on
>> tei-c.org) with that in use by Apex CoVantage in the AccessTEI
>> Recall that the task force members are:
>> * Perry Trolard (author of Tite and representative of the Mellon-
>> project that created Tite)
>> * Greg Spurlock (of Apex CoVantage)
>> * Kevin Hawkins (of the TEI Council)
>> I've copied Perry and Greg on this message for their information, but
>> please remember that they won't receive messages sent only to
>> tei-council and likewise can't post to the list themselves.
>> First some notes on aligning the two versions and then on additional
>> changes to consider making (to both versions).
>> = Aligning the two versions =
>> Before AccessTEI was launched, Apex reviewed Tite 1.0 closely and
>> provided a number of suggestions to Dan O'Donnell (perhaps also
>> to others), which were passed along to Laurent and Lou in February
>> These changes were deemed uncontroversial, so no Council vote was
>> on them; instead, Apex was allowed to implement them.
>> Perry shared a summary of these with me, and I have entered them into
>> SourceForge for our consideration. If we implement them, we will
>> the Council's Tite closer in line with Apex's derived version.
>> 1. removing a bunch of unnecesary elements and attributes:
>> (includes as a comment one more change discovered by Lou, not by
>> 2. adding <add> and <del>:
>> 3. Adding @facs to <pb/>:
>> For (2) and (3), apparently Lou provided some notes in February that
>> provide the basis for changes to the prose to accompany these schema
>> changes. If someone can find these, we will save ourselves time in
>> redoing this work.
>> In addition, Dan mentioned in May that while we met in Dublin, he
>> received the last set of suggestions from Apex. Requests to Dan and
>> Apex to see these have not yielded anything, but I would like to find
>> these and add these items to SourceForge before the Council begins
>> considering the other tickets in SourceForge that I have created
>> with issues I have discovered on my own that are problems with both
>> versions of Tite. If someone can provide these to me, I'll be
>> Once we get these documents incorporated into SourceForge tickets, we
>> can have a Council vote (or call for objections) and then ask the
>> editorial team to implement these changes.
>> = Additional changes to make =
>> The other bug reports and feature requests in SourceForge are about
>> things that I detected in both canonical Tite on tei-c.org and in the
>> Apex Tite documentation. While a few people have commented on
>> them, I
>> think we should wrap up all of the issues already identified first in
>> order to make the schema in use by Apex identical (in theory) to the
>> latest version at tei-c.org. *Then* we can discuss ways in which
>> are deficient.
>> Questions? Comments?
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
> David Sewell, Editorial and Technical Manager
> ROTUNDA, The University of Virginia Press
> PO Box 400314, Charlottesville, VA 22904-4314 USA
> Email: dsewell at virginia.edu Tel: +1 434 924 9973
> Web: http://rotunda.upress.virginia.edu/
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
INRIA & HUB-IDSL
laurent.romary at inria.fr
More information about the tei-council