The TEI tagset for markup language documentation (module tagdocs, chapter 22 “Documentation Elements”), affectionately called “ODD”, is a generic meta-language that can be used to develop markup languages from scratch. But most of us use it create TEI customizations; furthermore, most of those customizations do not use some capabilities of ODD. (E.g., it is very rare to add a new class to a customization ODD — it is a perfectly reasonable thing to do, we just don’t do it often.)
The ODD language itself, as documented in the TEI Guidelines and instantiated in the tei_odds.odd customization available as part of the P5 package from Sourceforge, is (appropriately) very loose, permitting all sorts of constructs that are not used by current ODD processors or are not often used in creating TEI customizations. This means that many documents that are valid against tei_odds are not proper TEI customization files, and thus will fail to produce a conforming TEI schema when submitted to (e.g.) Roma. Thus as a constraint for writing or hand-editing TEI customizations, tei_odds is not particularly useful.
By contrast, the “Brown ODD for Hand-editing ODDs” language is deliberately very restrictive in an attempt to be helpful for the average user customizing TEI at the expense of the power user developing non-TEI languages or using esoteric features of ODD. For example, the @ident attribute of <classSpec> is restricted to a list of the classes available in the TEI. This is wonderful for the vast majority of us customizing TEI — when we enter the <classSpec> element, our XML editor (e.g., oXygen) automatically inserts an @ident attribute and gives us a pop-up list of available classes.
Getting and Using
There are several possible ways to get your hands on brown_odds. Here they are arranged in what I think is roughly easiest to hardest.
- Download the derived files from the WWP website.
- Download the ODD file itself from the WWP website, and submit it to Roma or some other ODD processor.
- Copy-and-paste the ODD file itself into a file, and submit it to Roma or some other ODD processor.
- Download the source ODD file and building programs, figure out how to alter them so they run on your system, generate a new brown_odds.odd from them, and submit that to an ODD processor. Useful files:
- source ODD file
- stylesheet that reads in the TEI Guidelines from disk and generates lists of elements, modules, and classes.
- shell script that runs the process on my Mac
- shell script that supposedly runs the process on a TEI Ubuntu system, but the resulting schema will be invalid until the next release of the Stylesheets.
The TEI is not a static language. E.g., the list of elements names one might use for the @ident of <elementSpec> or in the @include or @except of <moduleRef> may change at any release. Thus the ODD file is particular to a given version of the TEI Guidelines. Rather than changing the ODD file each time a new version of the TEI Guidelines is released, there is a stylesheet that extracts the lists of elements, etc., from the Guidelines and a shell script that inserts them (using XInclude) into a ‘driver’ ODD file, and the result is the ODD file.
- Does not check that the elements in @include and @except of <moduleRef> come from the module listed on @key.
- Does not check that the element or class named on @ident of <elementSpec> or <classSpec> comes from the module named on @module.
- Does not test that there is only one <schemaSpec>.
- The system for building, which was originally intended to build it against the current development release of TEI for WWP workshops, could use a lot of improvement.
- Trying to distribute this via a wiki page like this is a bit nuts.
This particular version was built against (and thus for) TEI P5 1.9.1.
Sorry — the ODD itself can’t be put on the wiki page, as it triggers the spam filter (due to an attribute of <person> that has as its possible values 0, 1, 2, and 9).
Just because it’s fun, I thought I’d list the size of both the source brown_odds_driver.odd file, and the brown_odds.odd file once built.
Note 1Remember that some processors (including oXygen) will not read the ISO Schematron that is embedded in the RELAX NG compact syntax. Thus you will need to either use the XML syntax (from which oXygen will read the Schematron), or explicitly ask that both the RELAX NG and the Schematron be used. In which case, the top of your ODD might look like this:
<?xml version="1.0" encoding="UTF-8"?> <?xml-model href="brown_odds.rnc" type="application/relax-ng-compact-syntax"?> <?xml-model href="brown_odds.isosch" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?> <TEI xmlns="http://www.tei-c.org/ns/1.0" version="1.9.1" xmlns:sch="http://purl.oclc.org/dsdl/schematron" xmlns:rng="http://relaxng.org/ns/structure/1.0" >