[tei-council] update from the TEI Tite task force
dsewell at virginia.edu
Tue Dec 14 09:56:12 EST 2010
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 have
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 franca
for use between TEI-based projects and conversion vendors, including but
not limited to formal AccessTEI work. (Or has that decision already been
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 with
> aligning the TEI Tite schema maintained by Council (and hosted on
> tei-c.org) with that in use by Apex CoVantage in the AccessTEI program.
> Recall that the task force members are:
> * Perry Trolard (author of Tite and representative of the Mellon-funded
> 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 directly
> to others), which were passed along to Laurent and Lou in February 2010.
> These changes were deemed uncontroversial, so no Council vote was held
> 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 bring
> 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 Apex)
> 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 dealing
> 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 grateful.
> Once we get these documents incorporated into SourceForge tickets, we
> can have a Council vote (or call for objections) and then ask the Oxford
> 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 both
> 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
More information about the tei-council