> > [IM] XSL processibility always has a huge impact
> > [IM] on how I mark up our texts (given that TEI gives you
> > [IM] so many choices), both in terms of feasibility (probably
> > [IM] more a question of my XSLT shortcomings) and efficiency.
> [SR] I do find this a rather worrying statement. It seems remarkably
> [SR] indefensible to base markup decisions on what one particular
> [SR ] programming language can or cannot do! If your task isn't suited
> [SR] to XSLT, use another solution, don't compromise the markup.....
I don't really think what's at stake involves compromising the markup. As
Ingo says, the Guidelines give "so many choices". Sometimes a commitment to
XSLT processing can provide precisely the sort of criteria that people badly
need when they survey the amplitude of permissive flesh that clothes the
firm, but often deeply-hidden, skeleton of the TEI corpus. There are indeed
some academics who view all clear decisions as regrettable compromises, but
I regard that as a déformation professionelle to be guarded against.
I wouldn't regard XSLT as just "one particular programming language" as far
as a significant and growing subset of TEI-inspired projects is concerned,
namely those that place a premium on real-time delivery of html (or, down
the road, client-friendly xml) from their canonical xml. I can't see any
other tool in existence or in prospect that could do this job anything like
so well. And actually XSLT can avoid the need for truly undesirable markup
compromises by pulling the ground from under those who argue that complexity
of markup must be limited by a need for immediate perspicuity, an argument
that once held powerful sway in markup design, but no longer need do so now
that XSLT provides such a ready means of generating alternative
visualisations of our core markup.
In view of that, if the difficulty of applying XSLT to markup that makes
extensive use of milestone-type elements has some influence on markup
choices, that would seem to me to be inevitable, and defensible, where that
subset of projects is concerned.
[SB] Thank you for saying so, Sebastian. I couldn't agree more.
[SB] In fact, I've been known to go even further: don't base
[SB] markup decisions on what any or all current processing tools
[SB] can or cannot do, only on what they could or should do.
[SB] This on the theory that our tools will get better over time.
Well, yes, without this approach there would have been no TEI, and precious
little usable markup for the tardily-arriving and still inadequate tools to
process in the first place. And as long as we're talking about projects that
are primarily archival (in a fairly loose sense: I mean essentially
committed to providing digital documents for generations of future scholars
in ways that attempt to provide for as yet maybe unimagined specific needs
which such scholars may have) I can see no good reason for softening that
But there are some projects which need to get their materials to market
right now, and if the tools for doing that effectively and attractively also
dictate some aspects of the markup itself, then so be it. In the case of
Anglo-Norman, there is a huge repository of medical, mathematical, legal,
commercial, maritime etc etc lexis and usage that has been largely ignored
by scholars fixated on romance and hagiography, so that the received
historical lexicography of English and of continental French, as well as of
insular French itself, is in urgent need of revision. To get that revision
under way, we need to deliver our markup right now in ways processable to
today's tools and usable in today's (or even, realistically, the
day-before-yesterday's) browsers. Special pleading for a special case,
maybe, but I don't think it's altogether unrepresentative of a new(ish)
dimension in xml-based scholarly activity where the specific strengths and
weaknesses of XSLT are indeed allowed a special say in markup decisions.
The Anglo-Norman Dictionary http://anglo-norman.net/