Customization of the TEI is motivated by: The disciplinary needs and concerns that we've been talking about all along The goal of reconciling the need for a common encoding language with the need for expressiveness: the tension between egoism and altruism

TEI, is made up of lots of stuff … like a natural language one of the most important building blocks are the things being dealt with, the nouns, in our case the elements.

TEI has some 503 elements. In order for humans to get a handle on these and be able to think of them without suffering from brain-bursting overload, it is very helpful to divide them up into sets or groupings. TEI does this in two separate but equal ways … the modules that group by domain, and the classes that divide by their functions. These are their stories.

Modules are the sets into which elements are grouped conceptually. Remember the flower diagram of the TEI universe? Core in the center with things like dictionaries, critical apparatus, and manuscript description radiating out? Each of those petals, if you will, and the center are each in some sense a bag or box which contain a bunch of elements. And if you're doing manuscript description you can get all of those elements you might need at one shot by picking up the manuscript description bag by the convenient handle.

Every element must be inside one and only one module.

So that was one way of dividing up the elements — conceptually by domain using modules.

The other way they are divided up is by their semantics or function or by common features. Classes are sets of elements that have some functional similarities — functional in the XML sense. Either they share attributes (e.g., addSpan, delSpan, and damageSpan all share the spanTo= attribute), or may appear in the same kinds of places in the XML structure (e.g., anyplace a name can appear a persName or an orgName might appear instead).

These two kinds of classes — one for sharing attributes, one for occuring in the same kinds of places, are like clubs. Elements get to be members of these clubs. Being a member of an attribute class club is like being a member of an Alumni club — you get certain benefits of membership like a beenie hat or a pocket protector or discounts at local shops. Being a member of a model club is like being a member of faculty committee — you have to show up to meetings whether you like it or not.

So a good analogy to this is Leggos. Elements are the little Leggo pieces, canonically rectangles with 6 divits on top. When you go to the toy store you buy Leggos by the module — there's a core set you can get, which is just a bunch of the canonical bricks. But then there's also the castle module, the helicopter module, the fire station module, etc.

But most of the individual Leggo blocks can be grouped functionally as well — by the shape of the block and thus the number of divits on top, by the color, etc. So you might have the class of all round blocks with 12 divits on top.

The TEI Guidelines is more than just the elements, though. They are, after all, a set of Guidelines, and as such are composed of large chunks of prose devoted to particular topics. Conveniently these chunks of prose are divided into chapters that correspond directly with modules.

But the Guidelines also contain a reference section: a spec sheet for each of the types of Leggo block, if you will. Reading these spec sheets takes a bit of ___ or training. So I want to step you through, kind of a how to use this manual for the TEI tagdocs as they're called by their makers.

show title and head.

As we've already said: there are a number of very useful things you can do by customizing the TEI, and a number of you have already discovered the need for these during the hands-on exercises: Select modules Delete unnecessary elements Add new elements or attributes Change element or attribute names Constrain attribute values Constrain structure Manipulate functional groupings of elements Produce an internationalized version of the TEI

Customization doesn't just accomplish these changes to the schema: it does so in a way that documents and formalizes the changes (even multilingually, if desired). Besides being essential for comprehension and consistent local application, this means the changes can be communicated to other people, other projects

Groups of projects can develop common customizations that are shared and published

Projects can customize other projects' customizations

Customizations can be developed for specific disciplines

While TEI customization files are not particularly hard to write by hand, creating them is made even easier by a web-based editor called Roma. Many thanks to Sebastian Rahtz with the help of Arno Mittelbach for creating this wonderful tool.