Peter Robinson writes:
I would like to add my vote to exploration of TEI reform along the
lines suggested by David Durand. It has been my experience that
the great strength of the TEI is its rich element vocabulary:
all those tags for things in dictionaries, in critical
apparatus, in manuscript transcriptions, and much much more.
This neatly sums up my own feeling, although there are several lacunae
in the manuscript/transcription area which I would hope can be amended
(to which end I've just posted a summary to the TEI editors for
inclusion on the list of stuff for consideration). But we do have a very
powerful machine in the TEI DTD, and one which seems rightly to be
becoming more popular every time I read mail.
But what has made TEI sometimes very difficult to work with is the
prescriptive (sometimes, overly prescriptive, to my mind)
regulation of exactly how these elements might occur in relation to
each other and to the basic hierarchical 'div', 'body', etc,
structures. It is, for example, a feat of major prestigitation to
have an element occur BOTH within <P> elements AND within <DIV>
elements, without causing parser crisis.
I think this is an inevitable result of so many diverse applications
wanting everything everywhere. I know one or two of my own suggestions
have raised Lou's and Mike's eyebrows with more than slight incredulity,
yet they simply reflect the fact that in many projects, encoders must
represent as faithfully as possible the actual state of a text, and not
try to shoehorn Norse manuscripts into the mould of 18th century English
verse, or 20th century newspaper articles into the mould of the Dead Sea
I agree with David that, very often, one has to modify the TEI dtds:
I have had to do this for all three of the CD-ROMs Cambridge UP have
published in the last six months.
So far I have managed without modification of the master DTD files
themselves, just managing with local DTD and entity file mods, although
these in themselves have been traumatic on occasion. I think it is a
tribute to the expertise of the designers that the TEI is capable of so
wide a range of work with so little modification.
And, I agree too that it is quite impossible to adapt the TEI dtds
without a very deep knowledge indeed of how SGML DTDs work. (If
there is a more complex DTD than the TEI set, with all those
include statements, all those nested parameter entities, I hope I
never see it.) I would add also that this matter of modifying the
TEI DTDs is extremely problematic.
That is a problem, but the recent announcement of Richard Light's
NORMDTD has solved an outstanding problem of several years: how to get a
graphical DTD structural/hierarchical display/map from Near&Far without
manual surgery on the DTD (N&F suffered from not being able to handle
the depth of marked section nesting used in the TEI DTD). A few days ago
I successfully flattened the DTD version/subset I use, and produced a
large and complex but perfectly comprehensible diagram of the whole
thing, which has already proved itself invaluable in teaching and
explaining the relative positions and roles of elements to co-workers
and user. I've printed it off in several views and I'll bring it to
Bergen on slides.
statements, and modifications minor or major, makes for a real
problem in trying to establish public identifiers for any one TEI
This is already causing me problems in implementing one system, as I
have just discovered that it requires an FPI before it can attach a
style sheet or navigator. Of course these can be faked for local access,
but it is a problem we are going to have to tackle soon, IMHO. Is it
appropriate, for example, for projects to register themselves with the
ISO 9070 Registrar as Public Text Owners, so that their variant of TEI
can achieve an FPI?
dtd. It will also create all sorts of other problems further down
the track, when (for example) a library is trying to maintain an
archive of 100000 documents, every one of them claiming 'TEI
conformancy' and every one of them having a different brand of TEI
This has other implications: faster chips or faster parsers and more
bandwidth. If every instance one could download into (say) a browser
required the immediate subsequent downloading of a DTD or fragment, an
"acceptable display speed" would require greater speed in handling the
parsing before display or manipulation can begin.
As some sort of final argument: I wonder how many people actually
make DTDs by taking TEIlite, grafting in elements they need from
elsewhere in the TEI DTDs, and then fiddling content models in the
Unfortunately for most of the work I am involved in, Lite is not an
option, nice though it is, even with grafted elements.