AN ODD BASKET OF ODDS

The Text Encoding Initiative’s Guidelines for
Electronic Text Encoding and Interchange version P4 provides for separate steps of ‘customization’ and ‘extension’. The former consists of choosing which TEI tag-sets to use, and is typically performed either in the document type declaration subset or using the PizzaChef. The latter consists of various other alterations, including renaming elements, adding elements, deleting elements, and modifying content models or attribute lists. Although the PizzaChef can help ease this process, most of the work is done by re-defining TEI parameter entities using the DTD language. An ‘extension’ may extend the set of documents valid against the resulting DTD, may restrict that set, or may create a completely non-overlapping set. In all cases, it is still called an ‘extension’.
In TEI P5, these two steps have been rolled into one. The selection of modules (including the few mandatory
ones) is performed in a customization file. Changes to the schema, including the deletion of elements, the
addition of elements, etc., are also performed in this same customization file.
Because module selection is a necessary process, in
order to use P5 a user must start with a customization file
(even if it is just one of the sample customization files shipped with TEI). Luckily, the P5 method of creating customizations is substantially simpler than P4’s DTD method. This means they are easier to write, easier to document, and easier to share.
P5 customization files are written in TEI, using the
module for tagset documentation. This is also true for the
Guidelines themselves — they are written in TEI, using
the module for tagset documentation. Because using this tagset one encodes a single file from which all the
needed outputs are produced (the prose Guidelines, the
reference documentation, and the schemata), this language
is called ODD, for “one document does it all”. Therefore the customization files are usually referred to as “ODD files”, and given the extension .odd.
Because ODD files are written using a language the user already knows (TEI), rather than a special schema-
language syntax, creation of customizations is quite a bit easier. Furthermore, the TEI class system (which groups elements for convenient use) and datatype system (which provides restrictions for attribute values) are significantly
simplified since P4. And last, but far from least, there is a significant web interface (“Roma” at http://www.
tei-c.org.uk/Roma/) that presents a form interface for creation of the ODD customization files. This means that instead of trying to remember whether the
correct identifier for the module for names and dates is “namesdates”, “namesAndDates”, “namesDates”, etc., the user need only click on the “add” next to “Names and Dates”.
Because the same language as that used for the Guidelines themselves is used, brief documentation about added or changed elements or attributes can be placed directly
within the customizations themselves. Examples of
usage and remarks can also be encoded within the
customizations, and standard TEI style-sheets will
produce reference documentation from these. Furthermore,
because ODD files are written in TEI, the usual
prose elements (like <p>) can be used alongside the
specialized customization elements to provide more
in-depth documentation for the customization in the same
file. finally, since a customization file is a TEI XML file, it can be validated and easily transferred via any Unicode
aware exchange method. Because it contains the
documentation as well as the customizations themselves, it can be easily understood by the recipient.
But what do customizations look like? What are they good for? How does one make them? What are the
advantages and disadvantages of various customizations?
This panel presentation hopes to answer these questions not by having TEI “experts” lecture, but rather by having actual TEI users who have performed P5 customizations present their projects.
Each of the following projects will give a brief
presentation including a discussion of the reasons and motivations behind their customization, a careful look at the ODD file itself, a glance at the output reference documentation (some of which will be non-English), and perhaps an overview of the tool-chain used, culminating in a demonstration of sample output.