1The TEI ODD language (and the more modern version thereof, Pure ODD) can be used for two related, but distinctly different purposes: 1) to create a markup language, including documentation and schemas; and 2) to customize a markup language that was already written in ODD. There are several examples of (1), including the TEI_Guidelines, the Music Encoding Initiative, the ISO Feature Structure encoding system, the W3C Internationalization Tag Set, and a version of the Itsy Bitsy Teeny Weeny Simple Hypertext DTD. And there are several well known examples of (2), including TEI Lite, TEI Tite, TEI Simple Print, CBML, DALF, DHQ, jTEI, and the TEI-in-Libraries Best Practice Guidelines.

2Of all these various uses of the TEI ODD language, the most common (by far) is to create a customized TEI for use in a particular project. This is because the TEI Guidelines are not meant to be used out of the box — every TEI project is expected to customize the TEI. For example, in raw (i.e., uncustomized) TEI, the @type attribute of <stage> is given only three suggested values: “entrance”, “exit”, and “onStage”. A project may very well wish to expand this list (e.g., to “business”, “delivery”, “entrance”, “exit”, “location”, “modifier”, “novelistic”, “onStage”, “prop”, “remains”, and “setting”), and require that encoders use a value from this expanded list. This sort of molding of the TEI to local purposes is done by creating a TEI customization using the TEI ODD language.

3When writing a special-purpose XML document like these customizations written in ODD, it is very useful to have a schema against which to validate the document. The tei_odds customization provided by the TEI is, understandably, a schema intended to check conformance with the rules for using ODD. Because ODD is used for two different things, and for both TEI and non-TEI languages, those rules are necessarily much more broad than the rules needed for writing TEI customizations. E.g., the value of moduleRef/@key can be any XML name. But when used to write a TEI customization, the only values that make sense are the actual names of TEI modules (e.g., core, textstructure, header, namesdates).

4The tei_customization customization is not intended to produce a schema that can tell you what is “correct” or “incorrect,” but rather to help you write a TEI customization. So, e.g., only the names of TEI modules are allowed as values of moduleRef/@key, and thus your editor can give you a pop-up box of those values. This talk describes and demonstrates tei_customization, and discusses the interesting twist that this is not a schema whose rules must be obeyed, but rather an editing assistant.