The TEI Processing Model: Introduction, limitations and potential extensions

Multiple behaviours

Suppose that my edition contains notes to the edited text, and these notes are located in a listAnnotation under the standOff element. I want to produce a section of notes, headed by the heading 'Notes'. I don't want to use the TEI PM note behaviour, because that doesn't give me sufficient control. That means that I have to create a container, a heading within that container, followed by the representation of the note element themselves. Currently, the processing model offers me behaviours section to create the container and heading to create the heading. The only way to associate a listAnnotation with both behaviours is to group them in a modelSequence element, but that would give me the heading before or after the section, not within it.

One obvious solution would be to define a further behaviour: section-with-heading. Besides the default content parameter, that behaviour would also have the parameters needed to create the heading. The model statement for the listAnnotation element might look like:

<model behaviour="section-with-heading"> <param name="content-heading" value="'Notes'"/> <param name="level" value="3"/> </model>

This would do what we need. However, it will only help an individual project once it is implemented in TEI Publisher or another implementation of the TEI PM.

But if my project uses TEI Publisher, I already have a solution available, based on the pb:template element. My listAnnotation model element could look like this:

<model behaviour="section"> <pb:template> <div><h3>[[content_heading]]</h3>[[content]]</div> </pb:template> <param name="content_heading" value="'Notes'"/> </model>

For anyone who knows some HTML, this is certainly an attractive solution. Note, however, that it takes us out of the domain of the processing model and into the domain (HTML) from which the processing model was trying to abstract.

To me a better solution seems to be to have nested models. A model with behaviour section could contain a modelSequence containing another model with behaviour heading and one with behaviour block, or even pass-through. This would keep us at the level of the model, without bothering with the HTML code that should be left to the implementation. So the model for the listAnnotation would look like this:

<model behaviour="section"> <modelSequence> <model behaviour="heading"> <param name="level" value="3"/> <param name="content" value="'Notes'"/> </model> <model behaviour="block"/> </modelSequence> </model>

In fact, cases where an element needs to be associated with multiple behaviours at the same time are very common. Think of a pb (page begin) element that we want to associate with a link (to the representation of that page) and the link should have the form of a thumbnail whose filename is held in the pbs facs attribute. This could be modelled by a behaviour link containing a behaviour graphic. Another example is that of a name element to become a link into an external authority file, but also to be provided with a popup with some biographical information.[8] The example that we mentioned earlier of a paragraph that needs to be provided with a paragraph number and a permanent uri for citation purposes is another case of a situation that can be handled by nesting models.

Ordering output

Let us suppose we have a personography contained in a personList element in a TEI document. Suppose we want to display the personography, ordering the persons by last name. With the behaviours described in the current TEI Processing Model that is not possible.[9] What we could do is define a new behaviour, say, sorted-block, with a parameter sort-key. The model element for personList would then look like:

<model behaviour="sorted-block"> <param name="content" value="tei:person"/> <param name="sort-key" value="tei:persName/tei:surname/text()"/> </model>

This would allow us to stick to the existing syntax for defining processing models.

Suppose however, that we want to have multiple orderings, with the user being able to select the ordering to be used, perhaps using radio buttons or a similar device. In theory, we could have parameters sort-key-1, sort-key-2, etc. The sorted-block component could then use all parameters whose name starts with 'sort-key' as potential sort-keys. We could even have a convention that what in the parameter's name comes after 'sort-key-' should be used as a label in the radio buttons. But that would become very ugly. It would be much cleaner to be able to describe the orderings explicity, for instance as follows:

<model behaviour="sorted-block"> <param name="content" value="tei:person"/> <order name="Last name" value="tei:persName/tei:surname/text()"/> <order name="Date of birth" value="string(tei:birth/@when)"/> <order name="Nationality" value="tei:nationality/text()"/> </model>

Modularisation in the ODD

As mentioned above, elements' processing models are supposed to be defined under the elementSpec element for those elements in a project's schema specification. The TEI schema definition module (tagdocs) makes it possible for projects to accept an element's definition from the schema, but selectively override certain aspects of that definition, such as its attributes, the constraints that apply to it or its contents. The base definition is taken from the schemaSpecs or elementSpecs source attribute. The way is which definitions are to be merged is indicated by the mode attribute. The value replace indicates that the new definition replaces the old one, the value change means that the existing definition will remain intact, except for the explicitly modified parts. In this way, projects could also override an element's model subelements.

There are, I believe, a number of difficulties with this model. First of all there is a conceptual mismatch between the model subelements and the other content in the elementSpecs. A schema is for validation, models are for processing. But what is more important is that, as the schema definition hierachically consists of the element definitions (and many other things), all processing has to be defined at the element level.

This is unfortunate, because the processing of an element very much depends on the context in which it is to be processed. Take a person element. It may be processed in at least four different ways: (i) in its rendering in the personography, (ii) in its redering in a side-panel to another document where the person is mentioned, (iii) in the pop-up that appears when the mouse hovers over the reference, and finally (iv) in the facetted search where the person's name is used as a label. Having to force all of these contexts into a single elementSpec leads to long lists of model elements that use parameters such as $mode (not mentioned in the Processing Model specification) in their predicate attribute. This makes the behaviours associated with an element hard to understand. That is all the more likely because the different behaviours for the person element will also affect the behaviour of its underlying elements in these contexts. To understand what happens in a certain context requires us then to find the relevant models (checking the parameters in the predicates) for various elements.

Alternatively, it could lead to using multiple ODDs (the document that holds the (modified) schema definition) for a single document type, which could then be activated in various contexts. These would only need to contain the definitions applicable in a certain context. Indeed, TEI Publisher facilitates using different ODDs for different views on a page. But now we have achieved the opposite of what we aimed for: we put the processing definitions within the elementSpec to make them part of the single ODD file. But because this isn't really workable we begin to create multiple ODDs.

I believe it is possible to define the processing for a schema's elements in the ODD file in a more modular way, without the disadvantages mentioned here. But before we discuss that, I want to mention another undesirable effect of the current state of affairs. The model element does not have an ident attribute. This makes it unclear how the model children of an elementSpec with mode="change" should be handled. The definition of mode change mentions replacing the children of the original definition 'that agree in type and identifier' with the children of the new definition.[10] The assumption in TEI Publisher seems to be that all model (and modelGrp and modelSequence) children of the original elementSpec should be replaced by those of the new one. The visual ODD editor in TEI Publisher, at least, when we indicate we want to change the behaviour of an element from the default, copies over all model and related elements from the default ODD to our new one. It would be more practical to be able to override only a single model subelement.

In passing, we note that TEI Publisher in practice does away with the fiction that elements' processing model is part of the schema specification. The ODDs that we encounter in TEI Publisher do contain a schemaSpec element, but the only reason it is there seems to be that the schemaSpecs source attribute is used for chaining ODDs and overriding definitions.

Tentatively, I think we might want to define elements' processing in an element schemaProc, sibling to schemaSpec. schemaProc has a source attribute to be able to chain (and override) definitions. schemaProc would contain one or more processing blocks (procBlock), distinguished by a procmode attribute.[11] One processing block could have the procmode attribute equal to default. Other procmodes might be popup, title, toc, sidepanel, depending on the edition's needs. The processing blocks would contain elementProc elements that describe the processing for an element in that processing mode, and these in turn would contain the models, modelSequences and modelGrps that are now contained in elementSpec.

The processing blocks might have other attributes. A start attribute could contain an xpath expression pointing to the location in the document tree where processing should start. A adddefaultdefs boolean attribute could be used to indicate whether all processing definitions to be used should come from the current processing block or whether the default processing block definitions can be used for situations not described in the processing block itself.

This would do away with some of the disadvantages of the current situation: it makes a clear distinction between schema and processing while these can still be described in the same file; various modes of processing can be described in a single ODD without the need for parameters; all processing for a processing mode is described in a single processing block rather than in many different places in an ODD.

As an example of where such a processing block could be useful, think of the need for a document title on each of the pages representing a document. TEI Publisher now handles that situation by setting in the HTML templates a parameter header with the value short, which is then used in the predicate attribute of a model element in the ODD. It would be much cleaner if it were possible to straightworwardly point to a section in the processing specification.

Similarly, when generating a table of contents, I might have different processing expectations than in the representation of the transcription. In a table of contents, I might want to ignore line breaks in headings, to always resolve abbreviations and to ignore notes. We could handle this by referring to the same parameter in the processing model of all these elements, but to have a single processing block for handling the table of contents is obviously simpler.

Modular components and transferring control to another ODD

All editions contain edited text(s) of at least one document or text type. But besides the edited text, editions also contain other components, such as introductions, bibliographies, and possibly many more, such as a variant apparatus, a personography, list of places, list of artworks, etc. Each of these, we can call them secondary, components has its own schema, and presumably also its own processing expectations.

If we want to create editions based on reusable components, we should make sure that in the places where the components interact, we can somehow call or include functionality from one component into the other. If, in the example mentioned before, in our edition of correspondence we want the references to persons to be provided with a popup that gives some summary information about that person, we should be able to call a function (or to execute a rule block, or something of the kind) defined in the processing specification for the personography. If we can do that, we have a personography component that we can reuse in the context of other editions. If we cannot do it, we need to define some of the personography processing in each of the editions that uses the personography, doing away with hopes for a modular design. This is in fact, I believe, a strong reason for the processing blocks proposed in the preceding section.

To work this out a bit more, suppose in our edited text we have an rs element (referring string) of type person, representing a (reference to a) person. Supposing we have defined a popup behaviour that associates the string with the popup, we might also define a behaviour switch_odd (or perhaps switch_schema) and an associated attribute switch_to, used as follows:

<elementProc ident="rs" mode="change"> <model predicate="@type='person'" behaviour="popup" cssClass="popupContainer"> <modelSequence> <model behaviour="inline" cssClass="hasPopup entity"/> <!-- displays the referring string --> <model behaviour="switch_odd" switch_to="bio.odd#proc-bio-popup"> <!-- creates the popup content --> <param name="content" value="@ref"/> </model> </modelSequence> </model> </elementProc>

For creating the content of the popup, this would switch to the proc-bio-popup processing block in the personography ODD (called bio.odd). This processing block might look like this:

<procBlock xml:id="proc-bio-popup" procmode="mode-bio-popup"> <elementProc ident="person" mode="change"> <model behaviour="block" cssClass="isPopup"> <modelSequence> <model behaviour="heading"> <param name="level" value="4"/> <param name="content">Person information</param> </model> <model behaviour="paragraph"> <param name="content" value="tei:persName[@full='abb']"/> </model> <model behaviour="paragraph"> <modelSequence> <model behaviour="text"> <param name="content">Birth: </param> </model> <model behaviour="inline"> <param name="content" value="string(tei:birth/@when)"/> </model> <model behaviour="text"> <param name="content"> Death: </param> </model> <model behaviour="inline"> <param name="content" value="string(tei:death/@when)"/> </model> </modelSequence> </model> <model behaviour="paragraph"> <param name="content" value="tei:note[@type='shortdesc']"/> </model> </modelSequence> </model> </elementProc> <elementProc ident="persName"> <model predicate="@full='abb'" behaviour="inline"/> </elementProc> </procBlock>

This creates a block that contains a heading and several paragraphs of person information.[12]

We already saw some places where this switch_odd behaviour might be useful in creating an edition. Think of a person's or other entity's representation in a side panel to the text, or of the label needed to represent an enity in a facetted search.

Some more limitations

I want to mention a few more potential requirements for extension of the Processing Model, some of them in more detail than others.

• Above we saw that the models contained in an elementSpec in a chained ODD apparently are replaced wholesale when an elementSpec for the same element in the chaining ODD also contains model elements. It would seem much more natural to concatenate the models from the chaining and the chained ODDs, and apply the first model with a predicate and output attributes that match the current situation.

  One reason for this is that some elementSpecs contain long lists of model elements, because the required behaviour depends very much on the contexts in which the element occurs. It is cumbersome and and error-prone to have to overide all when you need to change just a single model element. Another reason is that concatenating is much more powerful that just overriding. For instance if a chained ODD says that a head within a line group (stanza) shoud be displayed in a certain way (predicate parent::tei:lg), when we concatenate rather than override, the chaining ODD can say that this should not apply to heads in nested line groups (predicate parent::tei:lg[parent::tei:lg] and behaviour pass-through) without changing the behaviour for heads in top-level line group.

• Currently, the values for the behaviour attribute are described as 'suggested'. That means that a project that would use the Processing Model to describe the expected processing for its elements can never be sure that an implementation that claims to support the Processing Model actually supports the behaviours that are decribed. The section in the TEI Guidelines that describes what is expected from implemenations[13] does not mention this aspect at all. I would argue that the Guidelines should prescribe which behaviours an implementation should at least support.

• The value attribute of the param element is expected to contain an xpath expression. But above we also met cases where the value could be a literal. In that case, we have to write value="'literal'". It would be cleaner to provide a literal value as text content. The param element should then have either a value attribute or literal content.

• If you read closely the example for switching to another ODD, you will have noticed that what we passed to the personography ODD was not the person node, but a reference to that node. To be able to provide the person node, the name of the personography file would have to be known in the rules of the other components. It makes for a cleaner separation in functionality when processing model rules for a component do not have to be aware of file names of other components. It should be left to the implementation to provide a mechanism that gets from the reference to a person (or other object) to the corresponding node.