The TEI ODD system organizes elements and attributes into a variety
of different collections: attributes are usually defined within class
specifications, and elements are members of modules, claim membership
of attribute classes, and are grouped in models and macros. But despite the
use of the word class, little in this infrastructure is a class in the way
that we would use the word in the context of an object-oriented language
such as Java.
This paper will argue that when we come to re-examine the ODD system
for TEI P6, we should consider creating a genuine hierarchical class system.
We hint at this when we talk, for example, of <persName> being "syntactic
sugar" for <name type="person">. Some elements in TEI are more abstract
and some are more specified, constrained versions of them. We might, for
example, construct an inheritance hierarchy like this:
<rs>
-<name>
--<persName>
---<surname>
---<forename>
--<eventName>
--<placeName>
...
Similarly, the <list> element is a more abstract ancestor of <listPerson>, <listOrg>,
<listPlace> etc. <ab>, being the least-specified block element, might be an ancestor
of <div>, which might be an ancestor of <p>.
This kind of hierarchy, as applied to the ontology of textual components that TEI
provides, is obviously distinct from the structural hierarchy of a document, as
embodied in the content models of a schema: <list> would be parent of
<listPerson> in the taxonomy, but of <item> in its content model. But when we are
defining those content models, an ontological hierarchy would be highly convenient.
In contexts where it makes sense, including <list> in a content model would
automatically allow all its descendant elements (the other list types); elsewhere,
such as in a <particDesc>, only a <listPerson> or a <listOrg> might be specifically
included.
Similarly, attribute definition could be applied at any level in the hierarchy. If <date>
is a member of att.datable, then this membership would be automatically inherited by its
descendants (<birth>, <death>, <creation>, <origDate>, <docDate>, etc.).
It would be ideal if the entire ontology could be arranged in the form of a series of
well-formed trees, but this is surely impractical. Instead, we could adopt a
multiple-inheritance model such as we see in Python or C++. This would
allow, for example, <floruit> to descend from both <date> and <state>. Elements
could be characterized in terms of their semantics according to some ancestors, and
their typical mise-en-page in terms of others. The existing model class system
attempts to do this, but it has arisen in rather an ad-hoc manner in the service of
wrangling content models, and some model classes are quite puzzling. While
model.milestone-like, for example, might form a solid basis for class inheritance
descending from <milestone>, it is much harder to see the logic behind e.g.
model.pPart.data, which "groups phrase-level elements containing names, dates,
numbers, measures, and similar data."
A clear definition of the taxonomies by which TEI elements could be categorized
(semantic, bibliographic, domain-related, etc.), along with robust object hierarchies
based on multiple inheritance, would greatly enhance the coherence and maintainability
of the TEI ODD infrastructure.