[tei-council] Galway agenda

Syd Bauman Syd_Bauman at Brown.edu
Thu Mar 27 13:57:52 EDT 2008


I realize that Council may consider this an intrusion, since I am no
longer on Council and have not been invited to attend the meeting in
Galway. If so, please accept my apologies in advance. However, I am
very concerned that one of the most important, if not the most
important, tasks facing the TEI is not on the agenda.


In P5 we have explicitly created a system which is not designed to be
useful out-of-the-box, but rather is intended to be customized.
Proper customization of P5 is an integral part of any TEI encoding
project. We (I think appropriately) make a big deal out of the
advantages of using ODD for this purpose, and even provide some tools
to help.

One of the advantages we (appropriately) tout is that from an ODD you
get not only a schema, but also custom documentation. This custom
documentation of their schema could be extremely useful to an
encoding project. However, currently it is not very useful at all
because 
a) it is not very well designed,
b) its CSS stylesheet is such that it is all but completely
   unreadable
c) links to the Guidelines proper don't work, and
d) internationalization output doesn't work correctly.

Having custom on-line documentation (not necessarily printed) is,
IMHO, absolutely crucial to the acceptance of TEI in many circles.
Imagine how much easier it would be to introduce people to TEI if the
reference documentation for TEI Lite were usable. The TEI put a lot of
effort into making TEI Lite accurate and helpful (the vast majority of
the work was done by Lou Burnard). But from section 20 on through the
ever-so-important appendices, it's so poorly formatted as to be
unusable.

The TEI put a lot of effort into allowing users to choose which
language would be used for formal documentation (i.e., <gloss> and
<desc> inside <*Spec>) and for element and attribute names (the vast
majority of the technical work and coordination was done by Sebastian
Rahtz). But this effort doesn't help most users, because even when
Roma does use the requested language (and I have not been able to
figure out when it will spit out non-English snippets and when it
won't), it seems to use all of them, and even if it only used the
right one, the formatting would still make the documentation all but
unusable. 

I don't know that it is reasonable for TEI to attack (a) in the near
future. But it seems to me that (b), (c), and (d) are of the utmost
importance and should be very very high priority tasks for Council (in
that order, I would say, but that's debatable).


P.S. Another item that should be on the agenda, although not as
     important, is finding the resources to improve Roma so that it is
     more usable for what customizers actually need to do (e.g.,
     constrain type= values and document them), or to re-write Roma
     from scratch, preferably as a desktop application.[1]


Note
----
[1] It has now been nearly 2 years since Amit Kumar took on this task,
    and since he is no longer on Council and has pretty much dropped
    out of sight (I have been to UIUC 3 times since, and have barely
    seen him, and he has not responded to my e-mail queries about this
    project), I think it would be worth examining this issue afresh.
    If Council would like, I would not mind trying to check in w/ Amit
    again via phone just so we know for sure where he stands.



More information about the tei-council mailing list