> Thank you for that lucid explanation. However, I'm sorry to say I'm
> not (yet) convinced. While as you say, not everyone follows "the
> rules" (more correctly, there are no rules, only guidelines), I can
> see that many thousands of works ... do follow the same basic
Indeed, thousands of works that can be encoded perfectly adequately
(if a bit annoyingly) using <div>. Whereas the books on the other
side of the coin (e.g., the bible, cookbooks, prayer books, some epic
poems, comic books, etc.; not mention manuscripts, diaries, letters,
proclemations, broadsides, transcribed sppeeches, posters, etc.)
could not all be adaquately encoded by any monolithic DTD that tried
to prescribe what the names of divisions were and how they nest.
> Indeed. Others have suggested to me before now that I can "just"
> modify the TEI DTD to provide the features I want.
Why the scare quotes? This sort of customization is not difficult,
and the pizza chef will even step you through a lot of it. (That
said, not all customizations are easy -- but this sort of syntactic
sugar one is, and is the only good reason I can think of at the
moment for numbered <divN>s to exist.)
Note that I'm talking about applying a properly formed (and
documented) pair of extension files, not hacking a flattened version
of a view of the TEI DTDs.
> But that seems to me to miss the point: I *want* to use TEI in
> order to benefit from the use of a standard; if I start modifying
> things, I'm immediately losing that benefit, in which case I
> might as well have created my own DTD in the first place.
It has been the intention of the TEI from the very begining (as I
understand things) that this be false. That is, the original design
of a "pizza" model DTD with user customizations was intended
(particularly via the TEIform= attribute) to allow use of a local or
discipline-specific encoding system that did *not* immediately lose
the benefits of the humanities-wide encoding system just because
there are some differences.
I don't think things have turned out quite the way TEI would have
liked -- I think you do lose some advantages when you make
customizations, but certainly not nearly as much as you would lose if
you created your own DTD. Probably not even in the same ballpark.
Furthermore, the advantages you lose are probably, IMHO, a lot
smaller than the advantages you gain. Especially if you transform
your files back to vanilla TEI before interchange. (A transformation
that, with XSLT, should be pretty darn easy.)
> I see no harm (and some benefit) in defining a tag set
> specifically for books which conform to the well-known book
I don't think it makes sense for TEI to get into the detail level of
what divisions are named and how they nest. (I don't even think it is
reasonable to make the value list for type= of <div> a closed list.)
On the other hand, I agree that it is quite a bit nicer (especially
when writing a file or during initial capture) to use namned elements
[it is also a big advantage if everyone agrees to use "chapter" not
"chap" or "Chap" or "Ch." or whatever as the value for type= of <div>
for chapters, but how we establish that is a different subject]. So I
do think it makes a lot of sense for someone in your shoes to use a
customization that sprinkles on the syntactic sugar that makes life
easy for you. Furthermore, I think it might make sense for TEI,
particularly in its new SourceForge presence, to serve as a
clearinghouse for such customization files (without implying any sort
If you have any trouble creating your customization files, feel free
Better yet, does anyone out there already have customization files
intended for this very purpose?