I could make a long argument for this, and I'll probably go on too
long before I finish this mail (I did), but I will try to be brief (and
fail). I think that the TEI (and perhaps starting with the new advisory
committee) should seriously examine the possibility of re-defining TEI
tagging on the Architectural form model. The current TEIform= attribute
leaves us partway there already.
In a long email discussion I had about 3 years ago with the editors
(but mainly Michael), I argued for this viewpoint. At the time, there
were a number of semantic issues unresolved about architectural forms to
which I could not give convincing answers. Today, these issues may still
be unresolved, but there is a great deal more experience with
Architetural forms, as they are finding growing acceptance within the
community of people who write DTDs for large groups to use.
The forthcoming HyTime revision is said to include a machine
processable syntax for architectural form definitions. I'm not sure what
to think of this proposal, as I've not seen it. I have some significant
reservations, since it is being included in the HyTime Techical
Corrigendum, but it has not been widely reviewed or subject to a formal
approval process in the way that it would have been had it gone through
a DIS (Draft International Standard) stage. However, James Clark is
reputed to be contributing his considerable talents to the effort, so it
may be alright despite the closed development process.
Regardless of the merits of that particular effort, I think the
Architectural Form (AF, henceforth) notion has much to offer the TEI in
terms of simplifying the TEI extension process. From what I've seen in
terms of traffic on this list, and the status of those TEI projects that
I follow, most projects must customize the TEI to some extent. And it
also seems that to customize the TEI DTD, people need to have a solid
understanding of SGML DTDs, as well as the TEI extension mechanisms. I
mention these facts to refute, in advance, two possible arguments
against my proposal:
i. People don't need to customize the TEI that much.
ii. The TEI extension mechanisms protect people from having to learn
SGML DTD skills.
What I'd like to see at the millennium, when the TEI is using AFs:
The TEI element definitions should be rephrased as AFs, along with
with example element declarations satisfying them. The TEI DTD should be
supported as a legacy application, but any DTD satisfying some basic
assumptions and containing TEI AFs should also be conforming. The TEI
bases should be replaced by example DTDs tailored to the specialized
tasks those bases are intended to satisfy. Specialised example DTDs
should also be included for the Linguistic, Editorial, and other
specialized tagsets. These example DTDs would serve as starting points
for projects to use, and could be customized using only the SGML DTD
skills that are required to customize the TEI, in any case.
The AF for a TEI document would require the inclusion of a TEI
header, and that header's AF would contain the same requirements that
its current element definition enforces. Using AFs one can not only
allow, but prevent extension of an element definition, at any point.
This might also simplify the creation of the specialized TEI software
we all crave, since even customized DTDs could retain full TEI
information even for customized variants. Currently, an application must
look at the values of a variety of parameter entities to determine what
tag changes have been made to the TEI DTD. With AF attributes in place,
the "TEI-nature" of a tag would be clear even just in looking at a
parsed document instance.
Maintenance of the TEI itself would be simplified with the splitting
of the current monolithic, yet highly customizable DTD into several
hundred individual tags or crystals. (Perhaps only TEI old-timers will
recognized the old TEI term "crystal,: referring to a small, rigidly
defined secton of markup). This would be a great gain in modularity, and
might also help simplify some of the hard arbitrary decisions that
workgroups have had to make in the past.
I think that for such a radical-seeming change, the execution would
not be that hard, as most of the current work would stand, with minor
syntax changes. The hardest part will be converting the current base
tagset definitions into example DTDs. But the result out to be simpler,
and significantly more accessible to casual inspection by the SGML
David Durand [log in to unmask] | [log in to unmask]
Boston University Computer Science | Dynamic Diagrams
http://cs-www.bu.edu:80/students/grads/dgd/ | http://dynamicDiagrams.com/