I can't resist weighing in on this, since it's a classic problem not just
for the TEI but for markup communities in general.
At 03:51 PM 2/20/2004, you wrote:
> > On the other hand, I'd like to adress your bigger question -- "use
> > TEI for encoding my catalog-that's-like-a-dictionary-but-not, or make
> > my own DTD" by suggesting that it is likely the best approach is the
> > middle road: to make your own extensions to the TEI DTD.
>I had thought that this might be possible, but wading through the TEI
>DTD, finding the right places to change things, and come out having it
>work has proved to be a formidable task in the past. OTOH, I am well aware
>of the TEI2-based XSLT materials that I have developed will largely go
>to waste if I start building my own DTD from scratch.
This does not actually have to be the case: although the TEI recommends
placing an order with the pizza chef, they can't actually prevent you from
learning how to make pizza yourself. If you were careful, you should be
able to design a "mock TEI" that would work with your stylesheets. I'm not
saying this is necessarily a good idea; but it is an intriguing alternative
to the usually recommended one for developing towards your own local
version. If done properly, the final outcome could well be a set of
extension files that would work with off-the-shelf TEI in the mandated way.
(If you decided to take on this challenge, you might want to try RNG
instead of DTDs, and share your insights with Sebastian and the WG....)
> > * Use <ab type="catEntry"> instead, and live with no internal
> > structure
>I have been aware that most of my problems could be resolved if I simply
>relegate all of the most meaningful markup to the attributes. But
>whenever I do that, I feel like my usage of XML is being constrained in
>a way that I don't really like, and I hate teaching that kind of XML to
It is a reasonable concern. There are definitely tradeoffs here, and no
absolutely right answer, especially since the requirement for interchange
and conformity to common models is not equally strong everywhere. Finally,
I think it behooves TEIers in general to recognize the difference between
formal compliance (it validates) and actual compliance (you're actually
using the tags in a way that is recognizable, a much blurrier line) -- and
that it's not hard to imagine nightmare scenarios in which a data set is
TEI in name but not at all in fact ... an "anti-TEI". :->
> > * Create a new paragraph-level element <catEntry> and give it
> > whatever internal structure you desire
> > * Create a new div-level element, <catEntry> and give it whatever
> > internal structure you desire
>To me, one of the above two seems to be the most attractive option, but
>I realize that it means I'll have to try to do some work with the DTD
>that scares me a bit.
It's not as scary as all that once you recognize that it's a challenge much
like others we are frequently confronted with these days, namely learning
many things on several levels at once. Sometimes tough, but when we persist
we eventually see the light.
See, no matter how you get there, you are discovering that to take TEI to
the next level, for you, means learning the internals of its architecture
(since therein lies the key to its extensibility). Even if you were to take
the apparent shortcut of starting from scratch and designing your own
"TEIish" tagging (if it seems like a shortcut and not just a long drive in
the country with no map), you'll need to grapple with TEI's architecture
sooner or later (and better sooner!) to get those proper extension files.
> > But as always, if you have trouble, post!
>This is encouraging.
To all of us!
"Thus I make my own use of the telegraph, without consulting
the directors, like the sparrows, which I perceive use it
extensively for a perch." -- Thoreau