Constraining document structure is a very important part of document production. In order to be machine-testable, constraints are expressed in a formal language of some sort. A variety of such formal languages exist, including closed schema languages (like RELAX NG), open schema languages (like Schematron), and literate encoding languages (like ODD).

But each of these languages, as currently used, presupposes a model where one or more document instances are validated against a separate schema. But there are (at least) two reasons why it may be very beneficial to describe some document constraints in the document itself.

First, in many humanities text encoding projects the role of TEI expert and the role of encoder may be played by different people, and there may be good reason that the encoder would not be able to change the schema. The encoder may not have the TEI expertise necessary to modify and debug an ODD, and to generate a schema from it; or she may not have write access to the part of the project where the ODD and schema are stored.

Second, it is not uncommon to have a large number of files in a project, all of which should conform to the same schema except for one bit. Imagine a project which has hundreds or thousands of occurrences of a particular attribute (say material= of <supportDesc>) spread out over 2 dozen files, each of which has a different possible subset of values (e.g., one set of files has only carvings into various kinds of stone, another all the etchings into various kinds of metal, and a third set for the velum, parchment, and paper).

In cases like this it could potentially be very beneficial to express the constraints in the <teiHeader> of each instance. This poster will demonstrate two different methods that might be employed to locally constrain the value of attributes of type data.enumerated.

The first is a generic mechanism developed by the author several years ago. It uses special elements to express constraints that can be associated with multiple elements or attributes. XSLT can be used to transform this markup into Schematron that can be used to validate the instance.

The second method is a subset of a recommendation James Cummings has been making for years — that the entire ODD declaration be permitted in a <teiHeader>. It is not quite as flexible as the generic method, but does re-use existing TEI elements.