Previous | Up | Next

#### Part 1

### Introduction

# 3 Structure of the TEI Document Type Definition

This chapter describes the overall structure of the encoding scheme defined by these Guidelines. It introduces the conceptual framework within which the following chapters are to be understood, and describes the technical means by which that conceptual framework is implemented in SGML. It assumes some familiarity with SGML; see chapter 2 .

The TEI encoding scheme consists of number of modules or DTD fragments which we refer to below as tag sets. Selected tag sets may be combined in many different ways, according to principles described in this chapter, within the framework of the TEI main DTD. Auxiliary tag sets are also defined for specific purposes independent of the TEI main DTD.

The DTD fragments from which the main TEI DTD is constructed may be classified as follows:

- core DTD fragments
- base DTD fragments
- additional DTD fragments

The first two sections of this chapter discuss these distinctions and list the specific tag sets included in each category. Section 3.3 describes how to invoke the TEI document type declaration, and how to specify which of the various base tag sets and optional additional tag sets are used in a document.

The global attributes, characteristics postulated of every element or tag in the encoding scheme, are defined in section 3.5 .

The remainder of the chapter contains a more technical description of the SGML mechanisms used to implement the encoding scheme. It may be skipped at a first reading, but a proper understanding of the topics addressed here is essential for anyone planning to modify or extend the TEI encoding scheme in any way (see also chapter 29 ), and also highly desirable for those wishing to take full advantage of its modular nature. The structure of the main TEI DTD file itself is outlined in section 3.6 . The element classes used to define smaller groups of elements and their characteristics are described in section 3.7 . Both global attributes and element classes are implemented using SGML parameter entities; various other uses of parameter entities in the TEI DTDs are discussed in section 3.8 .

## 3.1 Main and Auxiliary DTDs

These Guidelines define a large number of SGML tags for marking up documents, all of which are formally defined within the document type declaration (DTD) files provided by the TEI and documented in the remainder of the present document. The tags are grouped into tag sets or DTD fragments, each comprising a set of declarations for tags which belong together in some respect, typically related to their intended application area.

All tags used to transcribe documents are available for use within the main DTD of the TEI and are defined in Parts III and IV of these Guidelines. There are DTD fragments for prose and mixed matter, verse and verse collections, drama, dictionaries, analysis and interpretation of text, text criticism, etc. A full list, including the files in which they are defined, and the rules determining their selection and combination, is given in section 3.2 .

A number of auxiliary DTDs are also defined in these Guidelines. These are used for the encoding of ancillary descriptive information useful when processing electronic documents. Part V of these Guidelines describes several such auxiliary document types, specifically:

- independent header for use with sets of TEI headers regarded as documents in their own right, for example by libraries or archives exchanging details of their holdings (see chapters 5 and 24 ).
- writing system declaration used to define and document character sets or transliteration schemes (see chapters 4 and 25 ).
- feature system declaration used to define and document sets of analytic features (see chapters 16 and 26 ).
- tag set declaration used to define and document descriptive documentation for TEI-conformant tag sets (see chapter 27 ).

An independent header typically describes the encoding of a specific document, but in the case of a planned corpus or collection, it may define a set of encoding practices common to all texts in the collection. The other auxiliary document types provide information likely to be relevant to many documents, rather than to individual documents.

When individual TEI documents are exchanged between sites, they should be accompanied by whatever auxiliary documents apply to them. When larger groups of documents are exchanged, the relevant auxiliary documents need be exchanged only once. For further information see chapter 30 .

The DTD files containing these auxiliary DTDs are:

- `teishd2.dtd` independent header
- `teiwsd2.dtd` writing system declaration
- `teifsd2.dtd` feature system declaration
- `teitsd2.dtd` tag set declaration

Some of these auxiliary DTDs also make use of the core tag set defined as part of the main TEI DTD; this is described in the relevant chapters of part V.

## 3.2 Core, Base, and Additional Tag Sets

The main TEI DTD is constructed by selecting an appropriate combination of smaller tag sets, each containing some set of tags likely to be used together. These building blocks include:

- core tag sets standard components of the TEI main DTD in all its forms; these are always included without any special action by the encoder;
- base tag sets basic building blocks for specific text types; exactly one base must be selected by the encoder (unless one of the `combined' bases is used);
- additional tag sets extra tags useful for particular purposes. All additional tag sets are compatible with all bases and with each other; an encoder may therefore add them to the selected base in any combination desired.

Each tag set is contained in one or more system files, which are defined by appropriate SGML parameter entity declarations and invoked as a unit by appropriate SGML parameter entity references. [ see note 17 ] Several such declarations may be needed to invoke all parts of a given tag set, since as well as defining elements or attributes, a tag set may (for example) add new items to the set of global attributes or add classes to the system of element classes. Consistent naming principles are applied throughout the TEI scheme for these and other entities. Thus, assuming a tag set named `xxx` , the following parameter entities may be encountered:

- TEI.xxx used to enable or disable tag set `xxx` ; must have the value `INCLUDE` (tag set is enabled) or, by default, `IGNORE` (tag set not enabled).
- TEI.xxx.ent refers to a system file containing any parameter entity declarations unique to tag set `xxx` .
- TEI.xxx.dtd refers to a system file containing the element and attribute list declarations for tag set `xxx` .
- a.xxx contains definitions of attributes which are to be added to the set of global attributes when tag set `xxx` is enabled.
- m.comp.xxx if `xxx` is a base tag set, this contains a list of any component-level elements unique to it (for a definition of component-level elements, see section 3.7 ).
- mix.xxx a special entity for use in defining the set of component-level elements when the mixed base tag set is in use.
- gen.xxx a special entity for use in defining the set of component-level elements when the general base tag set is in use.

Few tag sets declare all of these entities; only those actually used are declared.

The interpretation of the parameter entity declarations, and the inclusion of the appropriate tag sets, are handled by a single `driver file' for the main TEI DTD. This file, `tei2.dtd` , is described in detail below in section 3.6 . The remainder of the present section identifies the files in which each tag set is contained, and the parameter entities associated with them.

### 3.2.1 The Core Tag Sets

Two `core' tag sets are always included in every invocation of the main TEI DTD. The tags and attributes that they contain are therefore available to any TEI document. The parameter entities used for this purpose, and the files they refer to, are:

- `TEI.core.dtd` refers to the file `teicore2.dtd` , which declares the core tags defined in chapter 6
- `TEI.header.dtd` refers to the file `teihdr2.dtd` , which declares the tags of the TEI header defined in chapter 5

Together with these tag sets, part II also documents a tag set for default text structure and front and back matter. This tag set is embedded by the base tag set selected, and may vary with the base; it is therefore described in the next section.

### 3.2.2 The Base Tag Sets

The base tag sets are those which define the basic building blocks of different text types. The basic structures of verse (line, stanza, canto, etc.), for example, are not those of prose (paragraph, section, chapter, etc.), while dictionaries use yet another set of basic structures. Each base corresponds to one chapter of Part III of this document.

In general, exactly one base tag set must be selected for any TEI-conformant document. Errors will result if none, or more than one, is selected, because the same elements may be differently defined in different base tag sets. For documents which mingle structurally dissimilar elements and require elements from more than one base, however, either the mixed base or the general base may be used; see section 3.4 . These bases require the encoder to specify which of the other bases are to be combined.

The encoder selects a base tag set by declaring the appropriate SGML parameter entity with the replacement text `INCLUDE` . To invoke the base tag set for prose, for example, the encoder must ensure that the DTD subset in the document contains the declaration:

     <!ENTITY % TEI.prose 'INCLUDE' >

The entities used to select the different base tag sets, and the files containing the SGML declarations for each base, are listed below.

- `TEI.prose` selects the base tag set for prose, contained in `teipros2.dtd` .
- `TEI.verse` selects the base tag set for verse, contained in `teivers2.dtd` and `teivers2.ent` .
- `TEI.drama` selects the base tag set for drama, contained in `teidram2.dtd` and `teidram2.ent` .
- `TEI.spoken` selects the base tag set for transcriptions of spoken texts, contained in `teispok2.dtd` and `teispok2.ent` .
- `TEI.dictionaries` selects the base tag set for print dictionaries, contained in `teidict2.dtd` and `teidict2.ent` .
- `TEI.terminology` selects the base tag set for terminological data files, contained in `teiterm2.dtd` , `teiterm2.ent` , `teite2n.dtd` , and `teite2f.ent` .
- `TEI.general` selects the generic mixed-mode base base tag set, contained in `teigen2.dtd` .
- `TEI.mixed` selects the base tag set for free mixed-mode texts, contained in `teimix2.dtd` .

As shown in the list, each base tag set is normally contained in one or two system files: a required one (with the extension `dtd') defining the elements in the tag set and their attributes, and an optional one (with the file extension `ent') defining any global attributes or specialized element classes enabled by that tag set. The parameter entities for these files have the same name as the enabling parameter entity for the base, with the suffixes `ent' and `dtd' respectively: the prose base, for example, is enabled by declaring the parameter entity `TEI.prose` as `INCLUDE` ; this in turn enables declarations of `TEI.prose.ent` and `TEI.prose.dtd` as the system files `teipros2.ent` and `teipros2.dtd` . For further details, see section 3.6 .

Most base tag sets (but not necessarily all) embed common definitions of text structure, front matter, and back matter, by referring to three standard parameter entities; these are:

- `TEI.structure.dtd` refers to the file `teistr2.dtd` , with default definitions for `<text>` , `<div>` , etc.
- `TEI.front.dtd` refers to the file `teifron2.dtd` , with tags for front matter
- `TEI.back.dtd` refers to the file `teiback2.dtd` , with tags for back matter

These default-structure tags are documented in chapter 7 .

### 3.2.3 The Additional Tag Sets

The additional tag sets define optional tags required by different encoders for different types of analysis and processing; each corresponds to a chapter in part IV of this document. In any TEI encoding, any or all of these additional tag sets may be made available, as they are all compatible with each other and with every base tag set. They are invoked in the same way as base tag sets, by defining the appropriate parameter entity as `INCLUDE` ; the relevant parameter entities, and the files containing the additional tag sets, are these:

- `TEI.linking` embeds the files `teilink2.dtd` and `teilink2.ent` , with tags for linking, segmentation, and alignment (chapter 14 )
- `TEI.analysis` embeds the files `teiana2.dtd` and `teiana2.ent` , with tags for simple analytic mechanisms (chapter 15 )
- `TEI.fs` embeds the file `teifs2.dtd` , with tags for feature structure analysis (chapter 16 )
- `TEI.certainty` embeds the file `teicert2.dtd` , with tags for indicating uncertainty and probability in the markup (chapter 17 )
- `TEI.transcr` embeds the files `teitran2.dtd` and `teitran2.ent` , with tags for manuscripts, analytic bibliography, and transcription of primary sources (chapter 18 )
- `TEI.textcrit` embeds the files `teitc2.dtd` and `teitc2.ent` , with tags for critical editions (chapter 19 )
- `TEI.names.dates` embeds the files `teind2.dtd` and `teind2.ent` , with specialized tags for names and dates (chapter 20 )
- `TEI.nets` embeds the file `teinet2.dtd` , with tags for graphs, digraphs, trees, and other networks (chapter 21 ) --- not to be confused with the graphics markup of `TEI.figures`
- `TEI.figures` embeds the files `teifig2.dtd` and `teifig2.ent` , with tags for graphics, figures, illustrations, tables, and formulae (chapter 22 ) --- not to be confused with the graph-theoretic markup of `TEI.nets`
- `TEI.corpus` embeds the file `teicorp2.dtd` , with tags for additional tags for language corpora (chapter 23 )

Like the base tag sets, the additional tag sets are each contained in one or two system files: a required one (with the file extension `dtd') defining the elements in the tag set and their attributes, and an optional one (with the file extension `ent') defining any global attributes or specialized element classes enabled by that tag set. The parameter entities for these files have the same name as the enabling parameter entity for the tag set, with the suffixes `ent' and `dtd' respectively: the additional tag set for linking, segmentation, and alignment, for example, is enabled by declaring the parameter entity `TEI.linking` as `INCLUDE` ; this in turn enables declarations of `TEI.linking.ent` and `TEI.linking.dtd` as the system files `teilink2.ent` and `teilink2.dtd` .

### 3.2.4 User-Defined Tag Sets

As described in chapter 29 , users may modify the markup language defined here by renaming elements, suppressing elements, adding new elements, or modifying element or attribute-list declarations. In general, local modifications will be most conveniently grouped into two files: one containing the local modifications to parameter entities used in the DTDs, and the other containing new or modified declarations of elements and their attributes. These files will be embedded in the TEI DTD if they are associated with the following two parameter entities:

- `TEI.extensions.ent` local modifications to parameter entities
- `TEI.extensions.dtd` declarations of new elements and modified declarations for existing elements

In some cases, users may wish to provide completely new base or additional tag sets, to be invoked in the same way as those defined in this document; such tag sets should also be divided into `entity files' and `DTD files' in the same way as the standard tag sets. Such modifications should be undertaken only with a thorough understanding of the interface among core, base, and additional tag sets as documented in the final sections of this chapter; see in particular section 3.6.2 .

Further recommendations for the creation of user-defined extension or modification are provided in chapters 29 and 28 .

## 3.3 Invocation of the TEI DTD

Like any other SGML document, a TEI document must begin with a document type definition (DTD). Local systems may allow the DTD to be implicit, but for interchange purposes it must be explicit. Because of its highly modular nature, it may in any case be desirable for the component parts of the TEI DTD to be made explicit even for local processing.

The simplest version of the TEI DTD names the main TEI DTD file as an external file, and specifies a single base tag set for use in the document, using the parameter entity names specified in section 3.2 . For example, a document using the base tag set for prose will begin with a document type declaration something like this:

     <!DOCTYPE TEI.2 PUBLIC "-//TEI P3//DTD Main Document Type//EN"
                            "tei2.dtd" [
          <!ENTITY % TEI.prose 'INCLUDE' >
     ]>

A document using the base tag set for drama will define a different parameter entity:

     <!DOCTYPE TEI.2 PUBLIC "-//TEI P3//DTD Main Document Type//EN"
                            "tei2.dtd" [
          <!ENTITY % TEI.drama 'INCLUDE' >
     ]>

If one or more of the additional tag sets described in Part IV are to be used, they are invoked in the same way as the base tag set. A document using the base tag set for prose, with the additional tag sets for text criticism and for linking, segmentation, and alignment, for example, will begin with a document type declaration something like this:

     <!DOCTYPE TEI.2 PUBLIC "-//TEI P3//DTD Main Document Type//EN"
                            "tei2.dtd" [
     <!-- TEI base tag set specified here: ... -->
          <!ENTITY % TEI.prose 'INCLUDE' >

     <!-- TEI additional tag sets optionally specified here: ... -->
          <!ENTITY % TEI.textcrit 'INCLUDE' >
          <!ENTITY % TEI.linking 'INCLUDE' >
     ]>

If local modifications are used, they may be stored in separate files and pointed to using the parameter entities `TEI.extensions.ent` and `TEI.extensions.dtd` . If such local modifications are added to the example just given, this is the result:

     <!DOCTYPE TEI.2 PUBLIC "-//TEI P3//DTD Main Document Type//EN"
                            "tei2.dtd" [
     <!-- Local modifications to the TEI DTD declared here.  They
          will be embedded at an appropriate point in the main
          DTD. ... -->
          <!ENTITY % TEI.extensions.ent system 'project.ent' >
          <!ENTITY % TEI.extensions.dtd system 'project.dtd' >

     <!-- TEI base tag set specified here: ... -->
          <!ENTITY % TEI.prose 'INCLUDE' >

     <!-- TEI additional tag sets specified here: ... -->
          <!ENTITY % TEI.textcrit 'INCLUDE' >
          <!ENTITY % TEI.linking 'INCLUDE' >
     ]>

If the document requires tags which are defined in different base tag sets (e.g. prose and drama) or embeds smaller texts which use different base tag sets, then one of the mixed-type bases must be used. Their proper invocation is described below in section 3.4 .

## 3.4 Combining TEI Base Tag Sets

The TEI DTD has been designed to simplify the task of choosing an appropriate set of tags for the text in hand. The core tag set includes tags appropriate to the majority of simple tagging requirements for prose, verse and drama, irrespective of the base tag set chosen. For more detailed tagging, the encoder may choose the prose base for prose texts, the verse base for verse, and so on.

In discussing these base tag sets elsewhere in these Guidelines, it is generally assumed for clarity of exposition that a text will fall into one, not several, of these types. It is not uncommon, however, for a text to combine prose and verse, or other forms treated by the TEI as different bases. Examples include:

- when the text is a collection of other texts, which do not all use the same base: e.g. an anthology of prose, verse, and drama
- when the text contains other smaller, embedded texts: e.g. a poem or song included in a prose narrative
- when some sections of the text are written in one form, and others in a different form: e.g. a novel where some chapters are in prose, others take the form of dictionary entries and still others the form of scenes in a play
- when the text moves back and forth among forms not between sections but within a single section: e.g. mixed prose-and-verse forms like many pastorals or like some portions of the Poetic Edda

The TEI DTD provides the following mechanisms to handle these cases:

- a definition of a corpus or collection as a series of `<tei.2>` documents, sharing a common TEI header (see chapter 23 )
- a definition of composite texts which comprise front matter, a group or several possibly nested groups of collected texts, themselves possibly composite (see section 7.3 )
- a notion of embedded text which allows one text to be embedded within another (that is, `<text>` is defined as a component-level element, as described briefly at the conclusion of section 7.3 )

Whichever mechanism is adopted, if the whole of the resulting document is to be parseable by the main TEI DTD it may need to combine elements from different TEI base tag sets. Two special-purpose base tag sets are defined for this purpose:

- the general base, which allows different sections of a text to use different bases, but ensures that each section uses only one base
- the mixed base, which allows chunk- and inter-level elements from any base to mix within any text division

When either of these `combined' bases is used, the user must specify all of the other bases to be included in the mix as well as either the general or the mixed base. This is the only exception to the general rule that no more than one base tag set may be enabled in a TEI document. The following set of declarations for example allows for any mixture of the low level structural tags defined in the prose, drama and dictionary base tag sets:

     <!DOCTYPE TEI.2 PUBLIC "-//TEI P3//DTD Main Document Type//EN"
                            "tei2.dtd" [
       <!ENTITY % TEI.mixed 'INCLUDE' >
       <!ENTITY % TEI.prose 'INCLUDE' >
       <!ENTITY % TEI.drama 'INCLUDE' >
       <!ENTITY % TEI.dictionaries 'INCLUDE' >
       <!-- Structurally, Moby Dick is not your
        everyday common or garden variety novel ... -->
     ]>

The following set of declarations has the same effect, but with the additional restriction that each text division (i.e. each member of the element class `divn` ) must be homogenous with respect to the mixture of available bases. Because in a `general' base, each `<div>` of the text may use a different base, the divisions of the text prefixed by this set of declarations will each be composed of elements taken solely from one of the prose, verse or dictionary base tag sets:

     <!DOCTYPE TEI.2 PUBLIC "-//TEI P3//DTD Main Document Type//EN"
                            "tei2.dtd" [
       <!ENTITY % TEI.general 'INCLUDE' >
       <!ENTITY % TEI.prose 'INCLUDE' >
       <!ENTITY % TEI.drama 'INCLUDE' >
       <!ENTITY % TEI.dictionaries 'INCLUDE' >
     ]>

The actual DTD fragments for the combined bases do nothing but embed the default tag set for overall text structure. The mixed-base tag set is in file `teimix2.dtd` :

    <!-- 3.4:  Mixed-Base Tag Set                                 -->
    <!-- Text Encoding Initiative: Guidelines for Electronic      -->
    <!-- Text Encoding and Interchange. Document TEI P3, 1994.    -->

    <!-- Copyright (c) 1994 ACH, ACL, ALLC. Permission to copy    -->
    <!-- in any form is granted, provided this notice is          -->
    <!-- included in all copies.                                  -->

    <!-- These materials may not be altered; modifications to     -->
    <!-- these DTDs should be performed as specified in the       -->
    <!-- Guidelines in chapter "Modifying the TEI DTD."           -->

    <!-- These materials subject to revision. Current versions    -->
    <!-- are available from the Text Encoding Initiative.         -->

    <!ENTITY % TEI.structure.dtd system 'teistr2.dtd'               >
    %TEI.structure.dtd;

The general-base tag set is in file `teigen2.dtd` :

    <!-- 3.4:  General-Base Tag Set                               -->
    <!-- Text Encoding Initiative: Guidelines for Electronic      -->
    <!-- Text Encoding and Interchange. Document TEI P3, 1994.    -->

    <!-- Copyright (c) 1994 ACH, ACL, ALLC. Permission to copy    -->
    <!-- in any form is granted, provided this notice is          -->
    <!-- included in all copies.                                  -->

    <!-- These materials may not be altered; modifications to     -->
    <!-- these DTDs should be performed as specified in the       -->
    <!-- Guidelines in chapter "Modifying the TEI DTD."           -->

    <!-- These materials subject to revision. Current versions    -->
    <!-- are available from the Text Encoding Initiative.         -->

    <!ENTITY % TEI.structure.dtd system 'teistr2.dtd'               >
    %TEI.structure.dtd;

## 3.5 Global Attributes

The following attributes are defined for every TEI element. [ see note 18 ]

- `id` provides a unique identifier for the element bearing the ID value.
- `n` gives a number (or other label) for an element, which is not necessarily unique within the document.
- `lang` indicates the language of the element content, usually using a two- or three-letter code from ISO 639.
- `rend` indicates how the element in question was rendered or presented in the source text.

Some tag sets (e.g. those for terminology, linking, and analysis) define other global attributes; these are documented in the appropriate chapters of Part III and Part IV. See also section 3.7.1 .

An additional attribute, `TEIform` , is also defined for every TEI element. Unlike the other attributes defined for every element, `TEIform` is not defined by class `global` because its default value is different in every case and must be defined individually for each element. [ see note 19 ]

- `TEIform` indicates the standard TEI name (generic identifier) for a given element.

Any TEI element may be given values for `id` , `n` , `lang` , `rend` , or `TEIform` , simply by specifying values for these attributes. The following two examples convey the same information about the text: that the material transcribed occurs within a `<p>` element (paragraph). They differ only in that the second provides an identifier for the paragraph, to which other elements (e.g. notes or hypertext links) can conveniently refer.

    <p>If to do were as easy as to know what were
    good to do, chapels had been churches and poor men's cottages
    princes' palaces.  It is a good divine that follows his own
    instructions ...</p>

    <p id='MV1.2.5'>If to do were as easy as to know what were
    good to do, chapels had been churches and poor men's cottages
    princes' palaces.  It is a good divine that follows his own
    instructions ...</p>

ID values must be legal SGML names; by default, this means they must begin with a letter from A to Z or a to z and contain no characters other than the letters A to Z or a to z, the digits 0 to 9, the full stop, and the hyphen. Furthermore, by default upper and lower case letters are not distinguished: thus, the strings `a23' and `A23' are identical, and may not be used to identify two distinct elements. If two elements are given the same identifier, the SGML parser will signal a syntax error. The following example, therefore, is not valid:

    <p id=page1><q>What's it going to be then, eh?</q></p>
    <p id=page1>There was me, that is Alex, and my three droogs,
    that is Pete, Georgie, and Dim, ... </p>

For a discussion of methods of providing unique identifiers for elements, see section 6.9.2 .

The `n` attribute allows identifying information (e.g. chapter numbers, etc.) to be encoded even if it would not be a legal `id` value. Its value may be any string of characters; typically it is a number or other similar enumerator or label. For example, the numbers given to the items of a numbered list may be recorded with the `n` attribute; this would make it possible to record errors in the numeration of the original, as in this list of chapters, transcribed from a faulty original in which the number 10 is used twice, and 11 is omitted:

    <list type=ordered>
    <item n=1>About These Guidelines
    <item n=2>A Gentle Introduction to SGML
    <!-- ... -->
    <item n=9>Verse
    <item n=10>Drama
    <item n=10>Spoken Materials
    <!-- sic:  original has '10' twice! -->
    <item n=12>Printed Dictionaries
    <!-- ... -->
    </list>

The `n` attribute may also be used to record non-unique names associated with elements in a text, possibly together with a unique identifier as in the following examples:

      <div type=chap n='One' id='TXT0101'>

      <div type=stanza n='xlii'>

The `lang` attribute indicates the language, writing system, and character set associated with a given element and all its contents. If it is not specified, the value is inherited from that of the immediately enclosing element. As a rule, therefore, it is simplest to specify the base language of the text on the `<tei.2>` element, and allow most elements to take the default value for `lang` ; the language of an element then need be explicitly specified only for elements in languages other than the base language.

The following two encodings convey the same information about the language of the text, since in the first the `lang` attributes on the `<emph>` elements specify the same value as that on the parent `<p>` element, while in the second they inherit that value without specifying it.

     <p lang=en> ... Both parties deprecated war, but one of
     them would <emph lang=en>make</emph> war rather than let
     the nation survive, and the other would <emph lang=en>accept
     </emph> war rather than let it perish, and the war came.</p>

     <p lang=en> ... Both parties deprecated war, but one of
     them would <emph>make</emph> war rather than let
     the nation survive, and the other would <emph>accept</emph>
     war rather than let it perish, and the war came.</p>

In the following example, by contrast, the `lang` attribute on the `<term>` element must be given if we wish to record the fact that the technical terms used are Latin rather than English; no `lang` attribute is needed on the `<q>` element, by contrast, because it is in the same language as its parent. It is strongly recommended that all language shifts in the source be explicitly identified by use of the `lang` attribute, as described in chapter 4 .

     <p lang=en>The constitution declares <q>that no bill of
     attainder or <term lang=la>ex post facto</term> law shall
     be passed.</q> ... </p>

Formally, the `lang` attribute is an `IDREF` ; a reference to the `id` value of a `<language>` element in the TEI header. [ see note 20 ] This means that each language used in the document should be declared in the TEI header using the `<language>` element defined in section 5.4.2 .

The `rend` attribute is used to give information about the physical presentation of the text in the source. In the following example, it is used to indicate that both the emphasized word and the proper name are printed in italics:

     <p> ... Their motives <emph rend='italics'>might</emph> be
     pure and pious; but he was equally alarmed by his knowledge
     of the ambitious <name rend='italics'>Bohemond</name>, and
     his ignorance of the Transalpine chiefs: ...</p>

If all or most `<emph>` and `<name>` elements are rendered in the text by italics, it will be more convenient to register that fact in the TEI header once and for all and specify a `rend` value only for any elements which deviate from the usual rendition.

The contents of the `rend` attribute are free text. In any given project, encoders are advised to settle on a standard vocabulary with which to describe typographic or manuscript rendition of the text, and to document their usage of that vocabulary in the `<rendition>` element of the TEI header.

The `TEIform` attribute is used to allow application programs to handle TEI-encoded documents correctly even if some or all elements have been renamed. Most users can ignore this attribute entirely; it is only relevant when the TEI DTDs are modified. [ see note 21 ]

The default value of `TEIform` for any element is the generic identifier of that element, as described in this document. The value for `<p>` is `p', the value for `<div1>` is `div1', etc. When elements are renamed, as described in chapter 29 , the declaration of `TEIform` is not modified. If `<div1>` is renamed `<chapter>` , for example, the default value of `TEIform` remains `div1'. An application program which does not recognize the new generic identifier can check to see whether the attribute `TEIform` exists, and examine its value if it does to find out which TEI element, if any, is being used.

Modifications of DTDs, however, may involve more than simple renaming of elements: sometimes elements are given not just new names, but complete new definitions. In such cases, the `TEIform` attribute may be used to indicate the standard TEI element corresponding to the modified element. For example, if a local modification of a DTD renamed the `<div1>` element as `<chapter>` and also modified its formal declarations (e.g. to change its content model), then the `TEIform` attribute on the modified element should be given the default value `div1` , in order to indicate that the local `<chapter>` element is a modification of the standard TEI `<div1>` .

When new elements are introduced, they may be identified as specialized variants of existing TEI elements by giving them the appropriate default value for `TEIform` . For example, if a local element called `<quatrain>` were introduced, as a specialized variant of the `<lg>` (line group) element which must contain exactly four lines, then its declaration might give its `TEIform` as `lg` , to signify that a quatrain is a particular type of line group, thus:

     <!ELEMENT quatrain - O (l, l, l, l)            >
     <!ATTLIST quatrain     %a.global
               TEIform      (lg)            'lg'    >

The formal definition of the global attributes is as follows:

    <!-- 3.5:  Global attributes                                  -->

    <!-- The global attributes are defined for every element in   -->
    <!-- the TEI tag set; individual declarations may be          -->
    <!-- overridden by local declarations for individual          -->
    <!-- elements.                                                -->

    <!-- If the tag sets invoked by the user define extra global  -->
    <!-- attributes (they do this in their .ent file), then they  -->
    <!-- are inherited by GLOBAL; otherwise the parameter         -->
    <!-- entities referred to expand to the empty string, as      -->
    <!-- shown here.                                              -->

    <!ENTITY % a.analysis ''                                        >
    <!ENTITY % a.linking ''                                         >
    <!ENTITY % a.terminology ''                                     >
    <!ENTITY % a.global '        %a.analysis;
                                 %a.linking;
                                 %a.terminology;
              id                 ID                  #IMPLIED
              lang               IDREF               %INHERITED
              rend               CDATA               #IMPLIED
              n                  CDATA               #IMPLIED'      >

    <!-- The TEIform attribute is also global, but is declared    -->
    <!-- individually for each element, not in a parameter        -->
    <!-- entity declaration.                                      -->

    <!-- This fragment is used in sec. 3.7.3                      -->

## 3.6 The TEI2.DTD File

All TEI-encoded documents use the same top-level DTD file, which refers to a number of other DTD files, the exact set of other files referred to depending on which base and which additional tagsets are in use. The remainder of this chapter describes in some detail the organization and function of this file and those it embeds; it is necessarily of a rather technical and specialized nature.

The main TEI DTD is always invoked by specifying the file `tei2.dtd` . This file:

1. takes care of certain necessary preliminaries:
   1. embeds any locally defined changes to the standard TEI parameter entities, so that local modifications can take precedence over default declarations;
   2. declares TEI-specific keywords used in other declarations and declares default values of `IGNORE` for all the parameter entities used to select base and additional tag sets (see section 3.8.3 );
   3. declares parameter entities for TEI generic identifiers (by embedding the file `teigis2.ent` ; see section 3.8.2 );
2. declares parameter entities for element classes, content models, and global attributes (by embedding `teiclas2.ent` ; see section 3.7.3 );
3. declares the top-level elements `<TEI.2>` and `<teiCorpus.2>` ;
4. embeds DTD files containing local modifications (if any), the core tag sets, the base tag set, and the additional tag sets.

### 3.6.1 Structure of the TEI2.DTD File

Each parameter entity associated with a tag set controls several marked sections in the main DTD file `tei2.dtd` . If the entity has been declared in the DTD subset with the text `INCLUDE` , then the marked sections it controls will be parsed; otherwise, they will be ignored. The marked sections controlled by each entity:

1. declare and refer to the entity file for the tag set, which defines its global attributes and element classes
2. declare and refer to the DTD file for the tag set, which defines its elements and their attributes
3. declare the parameter entity `component` ) in a form suitable for texts using that base

The `tei2.dtd` file has the following structure:

    <!-- 3.6.1: File tei2.dtd: Main document type declaration     -->
    <!-- file                                                     -->
    <!-- Text Encoding Initiative: Guidelines for Electronic      -->
    <!-- Text Encoding and Interchange. Document TEI P3, 1994.    -->

    <!-- Copyright (c) 1994 ACH, ACL, ALLC. Permission to copy    -->
    <!-- in any form is granted, provided this notice is          -->
    <!-- included in all copies.                                  -->

    <!-- These materials may not be altered; modifications to     -->
    <!-- these DTDs should be performed as specified in the       -->
    <!-- Guidelines in chapter "Modifying the TEI DTD."           -->

    <!-- These materials subject to revision. Current versions    -->
    <!-- are available from the Text Encoding Initiative.         -->

    <!-- This file first defines some useful entities, then       -->
    <!-- defines the element TEI.2 and includes files with the    -->
    <!-- various specialized parts of the document type           -->
    <!-- declaration. It also declares the top-level TEI.2 and    -->
    <!-- TEI.2.corpus elements.                                   -->

    <!-- I.  Preliminaries.                                       -->

    <!-- Embed any local modifications to TEI entities.           -->

    <!-- ... declarations from section 3.6.2                      -->
    <!--     (Local modifications to parameter entities)          -->
    <!--     go here ...                                          -->

    <!-- Embed entities for TEI generic identifiers.              -->

    <!ENTITY % TEI.elementNames system 'teigis2.ent'                >
    %TEI.elementNames;

    <!-- Define entities for TEI keywords.                        -->

    <!-- This includes defining the default for each base and     -->
    <!-- additional tag set as 'IGNORE'.                          -->

    <!-- ... declarations from section 3.8.3                      -->
    <!--     (TEI Keywords)                                       -->
    <!--     go here ...                                          -->

    <!-- II. Define element classes for content models, shared    -->
    <!-- attributes for element classes, and global attributes.   -->
    <!-- (This all happens within the file TEIclas2.ent.)         -->

    <!ENTITY % TEI.elementClasses system 'teiclas2.ent'             >
    %TEI.elementClasses;

    <!-- III. Define the top-level TEI elements: one for          -->
    <!-- individual texts, one for composites with a collective   -->
    <!-- header.                                                  -->

    <!-- A TEI document is a text preceded by a TEI header.       -->

    <!ELEMENT TEI.2         - O  (teiHeader, text)                  >
    <!ATTLIST TEI.2              %a.global;                         >

    <!-- A TEI corpus is a series of TEI.2 documents, preceded    -->
    <!-- by a corpus-level TEI header.                            -->

    <!ELEMENT teiCorpus.2   - O  (teiHeader, TEI.2+)                >
    <!ATTLIST teiCorpus.2        %a.global;                         >

    <!-- IV. Embed the actual tag sets. First embed any local     -->
    <!-- modifications and extensions. Then embed the core tag    -->
    <!-- sets, the (single) base tag set, and the (optional)      -->
    <!-- additional tag sets specified by the user.               -->

    <!-- ... declarations from section 3.6.2                      -->
    <!--     (Embed local element declarations, etc.)             -->
    <!--     go here ...                                          -->
    <!-- ... declarations from section 3.6.3                      -->
    <!--     (Embed the core tag sets)                            -->
    <!--     go here ...                                          -->
    <!-- ... declarations from section 3.6.4                      -->
    <!--     (Embed base tag set)                                 -->
    <!--     go here ...                                          -->
    <!-- ... declarations from section 3.6.5                      -->
    <!--     (Embed additional tag sets)                          -->
    <!--     go here ...                                          -->

A TEI-conformant document must use the `tei2.dtd` file, or one derived from it in the manner described in chapter 29 . It must also specify which base and which additional tag sets are to be invoked, using the mechanisms described in section 3.3 .

### 3.6.2 Embedding Local Modifications

As noted above in section 3.2.4 , local modifications to the DTD are most conveniently grouped into two files, one containing modifications to the TEI parameter entities, and the other new or changed declarations of elements and their attributes. These files should be associated with the parameter entities `TEI.extensions.ent` and `TEI.extensions.dtd` by declarations included in the document's DTD subset.

For example, if the relevant files are called `project.ent` and `project.dtd` , then declarations like the following would be appropriate:

     <!ENTITY % TEI.extensions.ent SYSTEM 'project.ent' >
     <!ENTITY % TEI.extensions.dtd SYSTEM 'project.dtd' >

When an SGML entity is declared more than once, the first declaration is binding and the others are ignored. The local modifications to parameter entities should therefore be handled before the standard parameter entities themselves are declared in `tei2.dtd` . The entity `TEI.extensions.ent` is referred to before any TEI declarations are handled, to allow the user's declarations to take priority. If the user does not provide a `TEI.extensions.ent` entity, the entity will be expanded to the empty string.

For example the encoder might wish to add two phrase-level elements `<it>` and `<bd>` , perhaps as synonyms for `<hi rend='italics'>` and `<hi rend='bold'>` . As described in chapter 29 , this involves two distinct steps: one to define the new elements, and the other to ensure that they are placed into the TEI document structure at the right place. We deal with the second first, by specifying the element class to which the new elements should be attached. To do this, the standard parameter entity `x.phrase` should be modified to include the two new generic identifiers. The file containing local declarations of the standard parameter entities will thus contain a declaration of the following form:

     <!ENTITY % x.phrase 'it | bd |' >

The relevant fragment of the DTD is this:

    <!-- 3.6.2:  Local modifications to parameter entities        -->
    <!-- Embed local modifications to TEI parameter entities.     -->
    <!-- Declare entity as empty string first, in case user has   -->
    <!-- no mods and has not declared it.                         -->

    <!ENTITY % TEI.extensions.ent ''                                >
    %TEI.extensions.ent;
    <!-- This fragment is used in sec. 3.6.1                      -->

The second type of modification needed is most conveniently performed after all the standard TEI parameter entities have been declared; this allows the element declarations provided by the user to make use of the parameter entities which define standard TEI content models and attribute definitions. To facilitate this, the parameter entity `TEI.extensions.dtd` is used to embed local element declarations before any of the TEI tag sets are embedded by the file `tei2.dtd` , but after all the TEI element classes and other parameter entities have been declared.

The task of declaring the non-standard `<it>` and `<bd>` elements is thus simplified: they can, for example, use the same parameter entities as the `<hi>` element. A suitable local DTD-modifications file might look like the following (note that the standard parameter-entity reference for phrase sequence is used):

     <!ELEMENT it           - -  (%phrase.seq)                      >
     <!ATTLIST it
               id                ID             #IMPLIED
               lang              IDREF          %INHERITED
               n                 CDATA          #IMPLIED
               rend              CDATA          #FIXED 'italics'    >
     <!ELEMENT bd           - -  (%phrase.seq)                      >
     <!ATTLIST bd
               id                ID             #IMPLIED
               lang              IDREF          %INHERITED
               n                 CDATA          #IMPLIED
               rend              CDATA          #FIXED 'boldface'   >

For further examples of local modifications to both parameter entities and element declarations, see chapter 29 .

The relevant fragment of the DTD is this:

    <!-- 3.6.2:  Embed local element declarations, etc.           -->
    <!-- Embedding local modifications here allows user           -->
    <!-- modifications to use all the standard TEI element        -->
    <!-- classes and parameter entities.                          -->

    <!ENTITY % TEI.extensions.dtd ''                                >
    %TEI.extensions.dtd;
    <!-- This fragment is used in sec. 3.6.1                      -->

### 3.6.3 Embedding the Core Tag Sets

The core tag sets are embedded by the file `tei2.dtd` using the parameter entities `TEI.header` and `TEI.core` . The relevant fragment of the DTD is this:

    <!-- 3.6.3:  Embed the core tag sets                          -->
    <!-- These occur in all documents and are therefore defined   -->
    <!-- unconditionally.                                         -->

    <!ENTITY % TEI.header.dtd system 'teihdr2.dtd'                  >
    %TEI.header.dtd;
    <!ENTITY % TEI.core.dtd system 'teicore2.dtd'                   >
    %TEI.core.dtd;
    <!-- This fragment is used in sec. 3.6.1                      -->

The default text structure tags, which are also documented as part of the core, are embedded by the base tag set, unless the base defines its own text structure tags; see the chapters on the individual bases.

### 3.6.4 Embedding the Base Tag Set

The `tei2.dtd` file embeds the appropriate files for the base tag set previously selected by means of the parameter entities described in section 3.2 . A parameter entity for the file containing the relevant DTD fragment is declared and referred to inside a conditional marked section controlled by the appropriate parameter entity. The relevant fragment of `tei2.dtd` is this:

    <!-- 3.6.4:  Embed base tag set                               -->
    <!-- A different base will be embedded, depending on which    -->
    <!-- parameter entity has been declared by the user with the  -->
    <!-- value 'INCLUDE'.                                         -->

    <![ %TEI.prose [
    <!ENTITY % TEI.prose.dtd system 'teipros2.dtd'                  >
    %TEI.prose.dtd;
    ]]&nil;>

    <![ %TEI.verse [
    <!ENTITY % TEI.verse.dtd system 'teivers2.dtd'                  >
    %TEI.verse.dtd;
    ]]&nil;>

    <![ %TEI.drama [
    <!ENTITY % TEI.drama.dtd system 'teidram2.dtd'                  >
    %TEI.drama.dtd;
    ]]&nil;>

    <![ %TEI.spoken [
    <!ENTITY % TEI.spoken.dtd system 'teispok2.dtd'                 >
    %TEI.spoken.dtd;
    ]]&nil;>

    <![ %TEI.dictionaries [
    <!ENTITY % TEI.dictionaries.dtd system 'teidict2.dtd'           >
    %TEI.dictionaries.dtd;
    ]]&nil;>

    <![ %TEI.terminology [
    <!ENTITY % TEI.terminology.dtd system 'teiterm2.dtd'            >
    %TEI.terminology.dtd;
    ]]&nil;>

    <![ %TEI.general [
    <!ENTITY % TEI.general.dtd system 'teigen2.dtd'                 >
    %TEI.general.dtd;
    ]]&nil;>

    <![ %TEI.mixed [
    <!ENTITY % TEI.mixed.dtd system 'teimix2.dtd'                   >
    %TEI.mixed.dtd;
    ]]&nil;>

    <!-- This fragment is used in sec. 3.6.1                      -->

### 3.6.5 Embedding the Additional Tag Sets

The `tei2.dtd` file embeds the appropriate files for any additional base tag set previously enabled by means of the parameter entities described in section 3.2 . A parameter entity for the file containing the relevant DTD fragment is declared and referred to, inside a conditional marked section controlled by the appropriate parameter entity. The relevant fragment of `tei2.dtd` is this:

    <!-- 3.6.5:  Embed additional tag sets                        -->
    <!-- These entities are declared and embedded only when the   -->
    <!-- user has overridden the default declaration of IGNORE    -->
    <!-- for a specific additional tag set.                       -->

    <![ %TEI.linking [
    <!ENTITY % TEI.linking.dtd system 'teilink2.dtd'                >
    %TEI.linking.dtd;
    ]]&nil;>

    <![ %TEI.analysis [
    <!ENTITY % TEI.analysis.dtd system 'teiana2.dtd'                >
    %TEI.analysis.dtd;
    ]]&nil;>

    <![ %TEI.fs [
    <!ENTITY % TEI.fs.dtd system 'teifs2.dtd'                       >
    %TEI.fs.dtd;
    ]]&nil;>

    <![ %TEI.certainty [
    <!ENTITY % TEI.certainty.dtd system 'teicert2.dtd'              >
    %TEI.certainty.dtd;
    ]]&nil;>

    <![ %TEI.transcr [
    <!ENTITY % TEI.transcr.dtd system 'teitran2.dtd'                >
    %TEI.transcr.dtd;
    ]]&nil;>

    <![ %TEI.textcrit [
    <!ENTITY % TEI.textcrit.dtd system 'teitc2.dtd'                 >
    %TEI.textcrit.dtd;
    ]]&nil;>

    <![ %TEI.names.dates [
    <!ENTITY % TEI.names.dates.dtd system 'teind2.dtd'              >
    %TEI.names.dates.dtd;
    ]]&nil;>

    <![ %TEI.nets [
    <!ENTITY % TEI.nets.dtd system 'teinet2.dtd'                    >
    %TEI.nets.dtd;
    ]]&nil;>

    <![ %TEI.figures [
    <!ENTITY % TEI.figures.dtd system 'teifig2.dtd'                 >
    %TEI.figures.dtd;
    ]]&nil;>

    <![ %TEI.corpus [
    <!ENTITY % TEI.corpus.dtd system 'teicorp2.dtd'                 >
    %TEI.corpus.dtd;
    ]]&nil;>

    <!-- This fragment is used in sec. 3.6.1                      -->

## 3.7 Element Classes

The TEI DTD contains over four hundred element types. To aid comprehension, modularity and modification, the majority of these elements are formally classified in some way. This section describes the various element classes recognized in the TEI DTD. Element classes are used to express two distinct kinds of commonality among elements. The elements of a class may share some set of SGML attributes, or they may appear in the same locations in the content models of the TEI DTDs, or both. A class is known as an a-class if its members share attributes, and as an m-class if its members appear at the same locations in the content models of other TEI elements. An element is said to inherit attributes, or the ability to appear at a given point in a document, from any classes of which it is a member. Classes may have subclasses and superclasses, and the characteristics of a superclass are inherited by all members of its subclasses.

Both types of element classes are represented in the TEI DTDs by parameter entities. For other uses of parameter entities in the TEI DTDs, see section 3.8 .

This section describes the major element classes of each type together with the formal declarations for their parameter entities, which are contained in the file `teiclas2.ent` . All element classes are documented in the alphabetical reference section in Part VII.

### 3.7.1 Classes Which Share Attributes

An attribute class (a-class) groups together elements which share some set of common attributes. For example, the members of the class `names` are all elements which contain proper nouns: e.g. `<name>` , `<placeName>` , or `<persName>` . All of these elements use the same attributes (`key` and `reg` ) to record information about the referent or the regularized form of the proper nouns. Similarly, the members of the `pointer` class share a set of attributes useful for managing cross-reference links and other pointers. [ see note 22 ]

The attributes shared by the members of an a-class are defined in a parameter entity; member elements inherit the attributes by referring to the parameter entity within their attribute-list declaration (examples below). This practice helps ensure that if the attribute definitions for the class change, all members of the class will automatically inherit the new definitions. Parameter entities used for this purpose form their names by taking the name of the class they define and prefixing the string `a.'; we refer to these entities as a-dot entities.

For example, the declaration for the `names` class includes attribute definitions for its two attributes `reg` and `key` :

    <!-- 3.7.1:  Sample class declaration                         -->
    <!ENTITY % a.names '
              reg                CDATA               #IMPLIED
              key                CDATA               #IMPLIED'      >

Members of the class typically inherit these definitions by referring to `a.names` :

    <!-- 3.7.1:  Sample element declarations                      -->
    <!-- The members of a class refer to its a-dot entity in      -->
    <!-- their attribute-list declaration, as shown here.         -->

    <!ELEMENT name          - -  (%phrase.seq;)                     >
    <!ATTLIST name               %a.global;
                                 %a.names;
              type               CDATA               #IMPLIED       >

Subclasses of a-classes inherit the attributes of their superclass similarly, by referring to the a-dot entity of the superclass in defining their own a-dot entity. For example, the class `xPointer` is a subclass of the class `pointer` , as shown implicitly by the declaration of its a-dot entity:

    <!-- 3.7.1: Sample subclass declaration, with inheritance     -->
    <!-- from superclass                                          -->
    <!ENTITY % a.xPointer '      %a.pointer;
              to                 %extPtr;            "DITTO"
              doc                ENTITY              #IMPLIED
              from               %extPtr;            "ROOT"'        >

(For an explanation of the parameter entity `extptr` used in the above example, see section 3.8.3 .)

The a-classes declared in the core tag sets of these Guidelines are:

- `declaring` elements which have a `decls` attribute for specifying which declarations in the header apply to the element, as described in section 23.3
- `declarable` header elements containing declarations, which can be pointed at by the `decls` attribute, as described in section 23.3
- `divn` structural elements which behave in the same way as divisions, as described in section 7.1
- `enjamb` elements which carry the `enjamb` attribute for indicating metrical enjambement
- `interpret` elements which contain overtly interpretive or extra-textual analysis or commentary on a text or some portion of it.
- `metrical` elements which carry metrical information (metrical pattern, realization of the pattern, rhyme)
- `names` elements which contain proper nouns and share attributes for identifying their referents and regularizing their spelling (section 6.4.1 )
- `personPart` elements which contain personal names or parts of them
- `placePart` elements which contain place names or parts of them
- `pointer` elements which point from one location in the document to another (section 6.6 )
- `seg` elements for the systematic or arbitrary segmentation of the text
- `temporalExpr` elements which contain temporal expressions
- `timed` elements (in the base tag set for spoken texts) which have a duration in time expressible with the attributes, as described in section 11.2.5
- `typed` elements which carry an additional semantic or functional classification
- `xPointer` elements which point from one location in the document to other locations within or outside the current document (section 14.2 )

All elements are considered members of the class `global` and thus include a reference to `a.global;` in their attribute definition list declaration. Some tag sets add specialized attributes to the set of global attributes; these additions are declared in the `ent' file of each tag set, using the following entity names. If the tag set does not define new global attributes, no entity of this type is declared.

- `a.analysis` additional global attributes for the analysis tag set
- `a.linking` additional global attributes for the linking tag set
- `a.terminology` additional global attributes for the terminology base

These entities are included in the `teiclas2.ent` file indirectly, when the entity-declaration files of each tag set are embedded, as shown below in section 3.7.6 . For purposes of documentation, these attributes are treated as if inherited by the class `global` from superclasses called `terminology` , etc., and are documented under the class name.

One further complication to the inheritance mechanism should be mentioned here. In rare cases, a member of an a-class may override the definition of an inherited attribute. For example, the element `<anchor>` inherits the global `id` attribute from the class `global` --- as does every other element. On `<anchor>` elements, however, `id` is not optional but required. The declaration of `<anchor>` therefore does not refer to the class `global` , but instead defines all the inherited attributes explicitly, using its own declaration for `id` and the default inherited declarations for the other global attributes:

    <!-- 3.7.1: Sample of local declaration overriding inherited  -->
    <!-- attributes                                               -->
    <!-- ANCHOR overrides the default ID, but uses the default    -->
    <!-- declarations for the other global attributes.            -->

    <!ELEMENT anchor        - O  EMPTY                              >
    <!ATTLIST anchor             %a.analysis;
                                 %a.linking;
                                 %a.terminology;
              lang               IDREF               %INHERITED
              rend               CDATA               #IMPLIED
              n                  CDATA               #IMPLIED
                                 %a.typed;
              id                 ID                  #REQUIRED      >

Because this declaration does not use the parameter entity `a.global` , clearly any change in the definition for that entity will not be reflected in this declaration. Consequently, any changes made to the global attributes as such will not be inherited by the `<anchor>` element. Instead, such changes must be replicated manually. Care must thus be taken in modifying attribute definitions for a-classes if any members of the class override the inherited definitions, to ensure that all members of the class really do get the modified definitions.

    <!-- 3.7.1:  Attribute classes                                -->
    <!ENTITY % a.declaring '
              decls              IDREFS              #IMPLIED'      >
    <!ENTITY % a.declarable '
              default            (YES | NO)          NO'            >
    <!ENTITY % a.divn '
              sample             (initial | medial | final |
                                 unknown | complete) complete
              part               (Y | N | I | M | F) N
              type               CDATA               #CURRENT
              org                (composite | uniform)
                                                     uniform'       >
    <!ENTITY % a.enjamb '
              enjamb             CDATA               #IMPLIED'      >
    <!ENTITY % a.interpret '
              resp               CDATA               %INHERITED
              inst               IDREFS              #IMPLIED
              type               CDATA               %INHERITED'    >
    <!ENTITY % a.metrical '
              real               CDATA               #IMPLIED
              met                CDATA               %INHERITED
              rhyme              CDATA               #IMPLIED'      >
    <!ENTITY % a.names '
              reg                CDATA               #IMPLIED
              key                CDATA               #IMPLIED'      >
    <!ENTITY % a.personPart '    %a.names;
              sort               NUMBER              #IMPLIED
              type               CDATA               #IMPLIED
              full               (yes | abb | init)  yes'           >
    <!ENTITY % a.placePart '     %a.names;
              type               CDATA               #IMPLIED
              full               (yes | abb | init)  yes'           >
    <!ENTITY % a.pointer '
              crdate             CDATA               #IMPLIED
              evaluate           (all | one | none)  #IMPLIED
              resp               CDATA               #IMPLIED
              targOrder          (Y | N | U)         U
              type               CDATA               #IMPLIED
              targType           NAMES               #IMPLIED'      >
    <!ENTITY % a.seg '
              function           CDATA               #IMPLIED
              part               (Y | N | I | M | F) N
              type               CDATA               #IMPLIED'      >
    <!ENTITY % a.temporalExpr '
              reg                CDATA               #IMPLIED
              value              CDATA               #IMPLIED
              type               CDATA               #IMPLIED
              full               (yes | abb | init)  yes'           >
    <!ENTITY % a.timed '
              dur                CDATA               #IMPLIED
              end                IDREF               #IMPLIED
              start              IDREF               #IMPLIED'      >
    <!ENTITY % a.typed '
              type               CDATA               #IMPLIED
              subtype            CDATA               #IMPLIED'      >
    <!ENTITY % a.xPointer '      %a.pointer;
              to                 %extPtr;            "DITTO"
              doc                ENTITY              #IMPLIED
              from               %extPtr;            "ROOT"'        >
    <!-- This fragment is used in sec. 3.7.3                      -->

### 3.7.2 Classes Used in Content Models

When the members of a class are structurally similar and can appear at the same kinds of structural locations in the document, they are grouped together into an m-class (or `model-class'). M-classes are implemented by defining a parameter entity for use in the formal declaration of element content models. The parameter entity takes the name of the class it defines, and prefixes the string `m.', which can be interpreted as model or as members. The replacement text of the entity is a list of the members of the class, separated by `|', the SGML symbol for alternation.

For each class an additional entity is defined, which also takes the name of the class, this time prefixed by the string `x.' (for extension); the default value of these x-dot entities is always the empty string. A reference to the corresponding x-dot entity is always included within the replacement string for each m-dot entity. This enables an encoder to add new members to a class simply by declaring a new value for an x-dot entity.

For example, the class `bibl` has the three members `<bibl>` , `<bibl.full>` , and `<bibl.struct>` . Its content-model entity is defined thus:

     <!ENTITY % x.bibl '' >
     <!ENTITY % m.bibl '%x.bibl bibl | bibl.full | bibl.struct' >

With the default value of the x-dot entity, this is the same as defining `m.bibl` with the replacement text `bibl | bibl.full | bibl.struct` . If an encoder wishes to add a new bibliographic element called `<myBib>` , it can be added to the `bibl` class by redefining the x-dot entity thus:

     <!ENTITY % x.bibl 'myBib |' >

This changes the replacement text of `m.bibl` from its default value to `myBib | bibl | bibl.full | bibl.struct` . If more than one element is to be added to a class, the x-dot entity for the class should be redefined as a list of the new generic identifiers, each one (including the last) followed by a vertical bar. The same effect could be achieved simply by redefining the whole of the new `m.bibl` entity directly, but the x-dot method requires no repetition of the already existing members of the class and thus minimizes the chance of error.

Like a-classes, m-classes may have subclasses or superclasses. Just as elements inherit from a class the ability to appear in certain locations of a document (wherever the class can appear), so all members of a subclass inherit the ability to appear wherever any superclass can appear. Superclasses transmit their location characteristics to their subclasses by referring, in declaring their m-dot entity, to the m-dot entities of the subclasses.

For example, the class `phrase` includes the classes `data` , `edit` , `hqphrase` , `loc` , and `seg` as members, as can be seen in the declaration for its m-dot entity:

    <!-- 3.7.2: Sample class declaration with inclusion of        -->
    <!-- subclasses                                               -->
    <!ENTITY % x.phrase ''                                          >
    <!ENTITY % m.phrase '%x.phrase %m.data; | %m.edit; |
               %m.formPointers; | %m.hqphrase; | %m.loc; |
               %m.phrase.verse; | %m.seg; | %m.sgmlKeywords; |
               formula | fw | handShift'                            >

When the entity `m.phrase` is referred to in content models, all members of all subclasses are included in the model.

### 3.7.3 The TEICLAS2.ENT File

The most important element classes used in TEI content models are declared in the DTD file `teiclas2.ent` , which is the default replacement text for the entity `TEI.elementClasses` and is embedded by the `tei2.dtd` file. These element classes are described, and their declarations reproduced, in the following sections.

The class system is structured around the following threefold division of elements:

- chunks elements such as paragraphs and other paragraph-level elements, which can appear directly within texts or within text subdivisions (i.e. `<div>` elements), but not within other chunks
- phrase-level elements elements such as highlighted phrases, book titles, or editorial corrections which can occur only within chunks (paragraphs or paragraph-level elements), but not between them (and thus cannot appear directly within a `<div>` ) [ see note 23 ]
- inter-level elements elements such as lists, notes, quotations, etc. which can appear either between chunks (as children of a `<div>` ) or within them

Together the two sets of chunks and inter-level elements make up the set of:

- text components elements which can appear directly within texts or text divisions; also called simply components or `component-level elements'

In general, the body of any text comprises a series of components, optionally grouped into `<div>` elements.

Some elements belong to none of these classes; these include high-level structural elements like `<tei.2>` and `<group>` as well as some specialized elements which appear only within particular structures (like `<analytic>` , `<monographic>` , and `<series>` ). The majority of elements found in normal running text, however, are assigned by the TEI DTDs to one or the other of these classes.

Some component elements (e.g. `<p>` or `<note>` ) are common to all base tag sets, while others are unique to individual tag sets. This distinction is reflected in the parameter entity declarations, as shown below.

The `teiclas2.ent` file has the following overall structure:

    <!-- 3.7.3:  Element classes for TEI DTDs                     -->
    <!-- Text Encoding Initiative: Guidelines for Electronic      -->
    <!-- Text Encoding and Interchange. Document TEI P3, 1994.    -->

    <!-- Copyright (c) 1994 ACH, ACL, ALLC. Permission to copy    -->
    <!-- in any form is granted, provided this notice is          -->
    <!-- included in all copies.                                  -->

    <!-- These materials may not be altered; modifications to     -->
    <!-- these DTDs should be performed as specified in the       -->
    <!-- Guidelines in chapter "Modifying the TEI DTD."           -->

    <!-- These materials subject to revision. Current versions    -->
    <!-- are available from the Text Encoding Initiative.         -->

    <!-- First, we declare the 'low-level' core classes: these    -->
    <!-- are classes of semantically and structurally similar     -->
    <!-- elements declared as part of the core tag set, e.g. the  -->
    <!-- classes 'data' or 'edit'.                                -->

    <!-- ... declarations from section 3.7.4                      -->
    <!--     (Low-level classes)                                  -->
    <!--     go here ...                                          -->
    <!-- ... declarations from section 3.7.9                      -->
    <!--     (Misc. Element Class Models)                         -->
    <!--     go here ...                                          -->

    <!-- Next, we declare the 'high-level' classes: these group   -->
    <!-- together all phrase-level elements, all inter-level      -->
    <!-- elements, and all chunk-level elements in the core, and  -->
    <!-- identify the 'common' component elements (chunks and     -->
    <!-- inter-level elements), as opposed to the                 -->
    <!-- tagset-specific components.                              -->

    <!-- ... declarations from section 3.7.5                      -->
    <!--     (Common high-level classes)                          -->
    <!--     go here ...                                          -->

    <!-- Next, we embed the portions of each base and additional  -->
    <!-- tag set which declare relevant parameter entities. Only  -->
    <!-- those files are embedded which have been selected by     -->
    <!-- the user in the DTD subset. These files will declare     -->
    <!-- parameter entities for their component-level elements,   -->
    <!-- as well as for any global attributes they define.        -->

    <!-- ... declarations from section 3.7.6                      -->
    <!--     (Embedding tag-set-specific entity definitions)      -->
    <!--     go here ...                                          -->

    <!-- We can now declare the standard content models; one of   -->
    <!-- these varies with the base selected.                     -->

    <!-- ... declarations from section 3.7.7                      -->
    <!--     (Standard Content Models)                            -->
    <!--     go here ...                                          -->

    <!-- Finally, we declare the attribute classes, including     -->
    <!-- the global attributes.                                   -->

    <!-- ... declarations from section 3.7.1                      -->
    <!--     (Attribute classes)                                  -->
    <!--     go here ...                                          -->
    <!-- ... declarations from section 3.5                        -->
    <!--     (Global attributes)                                  -->
    <!--     go here ...                                          -->

### 3.7.4 Low-Level Element Classes

The following low-level classes group together sets of semantically or structurally similar elements. These classes may include both elements in the core and elements declared in particular tag sets; a reference is given at least to the relevant section on the core tags.

The following are phrase-level element classes:

- `hqphrase` elements for highlighted phrases or material marked by quotation marks, including those defined in section 6.3
- `data` elements for recording information about the referents of a text, including those defined in section 6.4
- `date` elements for recording dates, including those defined in section 6.4.4
- `edit` elements for recording simple editorial interventions in a text, including those defined in section 6.5
- `loc` elements for recording location information in a text, including those defined in section 6.9
- `seg` elements for marking arbitrary segments at the level of individual characters or phrases, including those documented in section 14.3 and 15.1
- `sgmlKeywords` elements for marking generic identifiers, attribute names, SGML tags, and sample attribute values, when they occur in the text (used in tag set documentation, for which see chapter 27 )
- `versePhrases` phrase-level elements specific to verse, documented in section 9.3
- `formPointers` elements for referring, within a dictionary entry, to the orthographic form or pronunciation of the headword, documented in section 12.4

The following are inter-level element classes:

- `hqinter` elements for highlighted phrases or material marked by quotation marks, including those defined in section 6.3
- `bibl` elements for bibliographic citations; see section 6.10
- `lists` elements for lists; see section 6.7
- `notes` general-purpose annotation elements; see section 6.8
- `stageDirection` elements for specialized stage-direction elements documented in section 10.2.3

The following classes of elements may appear anywhere within the `<text>` element:

- metadata elements which convey non-textual information about the text (meta-information, as it were)
- refsys milestone elements used in reference systems
- editincl elements marking arbitrary spans of text which has been added, deleted, or omitted from a transcription

These three classes together form the `globincl` class, comprising elements which may appear anywhere within the `<text>` element (because the class is used in an inclusion exception on that element).

The entity declarations for these classes are these:

    <!-- 3.7.4:  Low-level classes                                -->
    <!-- Most of these elements are in the core tag set, but      -->
    <!-- some may be from other tag sets.                         -->

    <!-- Phrase-level classes                                     -->

    <!ENTITY % x.hqphrase ''                                        >
    <!ENTITY % m.hqphrase '%x.hqphrase distinct | emph | foreign |
               gloss | hi | mentioned | soCalled | term | title'    >
    <!ENTITY % x.date ''                                            >
    <!ENTITY % m.date '%x.date date | dateRange | dateStruct'       >
    <!ENTITY % x.data ''                                            >
    <!ENTITY % m.data '%x.data abbr | address | date | dateRange |
               dateStruct | expan | geogName | lang | measure |
               name | num | orgName | persName | placeName | rs |
               time | timeRange | timeStruct'                       >
    <!ENTITY % x.edit ''                                            >
    <!ENTITY % m.edit '%x.edit add | app | corr | damage | del |
               orig | reg | restore | sic | space | supplied |
               unclear'                                             >
    <!ENTITY % x.loc ''                                             >
    <!ENTITY % m.loc '%x.loc link | ptr | ref | xptr | xref'        >
    <!ENTITY % x.seg ''                                             >
    <!ENTITY % m.seg '%x.seg c | cl | m | phr | s | seg | w'        >
    <!ENTITY % x.sgmlKeywords ''                                    >
    <!ENTITY % m.sgmlKeywords '%x.sgmlKeywords att | gi | tag |
               val'                                                 >
    <!ENTITY % x.phrase.verse ''                                    >
    <!ENTITY % m.phrase.verse '%x.phrase.verse caesura'             >
    <!ENTITY % x.formPointers ''                                    >
    <!ENTITY % m.formPointers '%x.formPointers oRef | oVar | pRef |
               pVar'                                                >
    <!ENTITY % x.metadata ''                                        >
    <!ENTITY % m.metadata '%x.metadata alt | altGrp | certainty |
               fLib | fs | fsLib | fvLib | index | interp |
               interpGrp | join | joinGrp | link | linkGrp |
               respons | span | spanGrp | timeline'                 >
    <!ENTITY % x.refsys ''                                          >
    <!ENTITY % m.refsys '%x.refsys cb | lb | milestone | pb'        >
    <!ENTITY % x.editIncl ''                                        >
    <!ENTITY % m.editIncl '%x.editIncl addSpan | delSpan | gap'     >
    <!ENTITY % x.globincl ''                                        >
    <!ENTITY % m.globincl '%x.globincl %m.editIncl; | %m.metadata;
               | %m.refsys; | anchor'                               >

    <!-- Inter-level classes                                      -->

    <!ENTITY % x.hqinter ''                                         >
    <!ENTITY % m.hqinter '%x.hqinter cit | q | quote'               >
    <!ENTITY % x.bibl ''                                            >
    <!ENTITY % m.bibl '%x.bibl bibl | biblFull | biblStruct'        >
    <!ENTITY % x.lists ''                                           >
    <!ENTITY % m.lists '%x.lists label | list | listBibl'           >
    <!ENTITY % x.notes ''                                           >
    <!ENTITY % m.notes '%x.notes note | witDetail'                  >
    <!ENTITY % x.stageDirection ''                                  >
    <!ENTITY % m.stageDirection '%x.stageDirection camera | caption
               | move | sound | tech | view'                        >
    <!-- This fragment is used in sec. 3.7.3                      -->

### 3.7.5 High-Level Element Classes

The following element classes are used to implement the threefold structural distinction among phrases, chunks, and intermediate elements discussed above in section 3.7.3 . In this terminology, chunks (or chunk elements are elements which can occur only in chunk-level sequences (e.g. between but not within paragraphs); inter-level elements can occur either within chunks (at phrase-level) or between chunks (e.g. at paragraph-level), and phrase-level elements can occur only at phrase level, within chunks (e.g. within but not between paragraphs).

The element class `common` includes all component-level (chunk- and inter-level) elements common to more than one base. It is used in implementing the combined bases described in section 3.4 .

The relevant portion of the DTD looks like this:

    <!-- 3.7.5:  Common high-level classes                        -->
    <!-- These are the three fundamental element classes.         -->

    <!ENTITY % x.phrase ''                                          >
    <!ENTITY % m.phrase '%x.phrase %m.data; | %m.edit; |
               %m.formPointers; | %m.hqphrase; | %m.loc; |
               %m.phrase.verse; | %m.seg; | %m.sgmlKeywords; |
               formula | fw | handShift'                            >
    <!ENTITY % x.inter ''                                           >
    <!ENTITY % m.inter '%x.inter %m.bibl; | %m.hqinter; | %m.lists;
               | %m.notes; | %m.stageDirection; | castList | figure
               | stage | table | text'                              >
    <!ENTITY % x.chunk ''                                           >
    <!ENTITY % m.chunk '%x.chunk ab | eTree | graph | l | lg | p |
               sp | tree | witList'                                 >

    <!-- This class isolates all the common component-level       -->
    <!-- elements.                                                -->

    <!ENTITY % x.common ''                                          >
    <!ENTITY % m.common '%x.common %m.bibl; | %m.chunk; |
               %m.hqinter; | %m.lists; | %m.notes; | stage'         >
    <!-- This fragment is used in sec. 3.7.3                      -->

### 3.7.6 Elements Marked for Text Type

The following element classes are used to group together component-level elements which are allowed only in texts of a particular type (i.e. texts using a specific base).

- `comp.verse` elements unique to verse
- `comp.drama` elements unique to drama
- `comp.spoken` elements unique to spoken texts
- `comp.dictionaries` elements unique to dictionaries
- `comp.terminology` elements unique to terminological data

Declarations for these base-specific element classes are included in the entity file of each base, which is in turn embedded by the `teiclas2.dtd` file in the DTD fragment shown below. If the tag set defines additions to the set of global attributes, or declares a class of component-level elements unique to the tag set, then it has an entity file which is embedded here; otherwise not.

    <!-- 3.7.6:  Embedding tag-set-specific entity definitions    -->

    <![ %TEI.verse [
    <!ENTITY % TEI.verse.ent system 'teivers2.ent'                  >
    %TEI.verse.ent;
    ]]&nil;>

    <![ %TEI.drama [
    <!ENTITY % TEI.drama.ent system 'teidram2.ent'                  >
    %TEI.drama.ent;
    ]]&nil;>

    <![ %TEI.spoken [
    <!ENTITY % TEI.spoken.ent system 'teispok2.ent'                 >
    %TEI.spoken.ent;
    ]]&nil;>

    <![ %TEI.dictionaries [
    <!ENTITY % TEI.dictionaries.ent system 'teidict2.ent'           >
    %TEI.dictionaries.ent;
    ]]&nil;>

    <![ %TEI.terminology [
    <!ENTITY % TEI.terminology.ent system 'teiterm2.ent'            >
    %TEI.terminology.ent;
    ]]&nil;>

    <![ %TEI.linking [
    <!ENTITY % TEI.linking.ent system 'teilink2.ent'                >
    %TEI.linking.ent;
    ]]&nil;>

    <![ %TEI.analysis [
    <!ENTITY % TEI.analysis.ent system 'teiana2.ent'                >
    %TEI.analysis.ent;
    ]]&nil;>

    <![ %TEI.transcr [
    <!ENTITY % TEI.transcr.ent system 'teitran2.ent'                >
    %TEI.transcr.ent;
    ]]&nil;>

    <![ %TEI.textcrit [
    <!ENTITY % TEI.textcrit.ent system 'teitc2.ent'                 >
    %TEI.textcrit.ent;
    ]]&nil;>

    <![ %TEI.names.dates [
    <!ENTITY % TEI.names.dates.ent system 'teind2.ent'              >
    %TEI.names.dates.ent;
    ]]&nil;>

    <![ %TEI.figures [
    <!ENTITY % TEI.figures.ent system 'teifig2.ent'                 >
    %TEI.figures.ent;
    ]]&nil;>

    <!-- This fragment is used in sec. 3.7.3                      -->

### 3.7.7 Standard Content Models

As far as possible, the TEI DTDs use the following set of frequently-encountered content models, to help achieve consistency among different elements.

- `phrase` a single sequence of character data or single phrase-level element
- `phrase.seq` sequence of character data and phrase-level elements
- `component` a single chunk- or inter-level element
- `component.seq` sequence of chunk- and inter-level elements; this is the usual content of a `<div>` element
- `paraContent` sequence of character data, phrase-level elements, and inter-level elements; this is the usual content of chunks (including, most prominently, paragraphs)
- `specialPara` specialized content model, allowing either a sequence of chunks or the same content as `paraContent` ; this is used for elements such as notes and list items, which can behave either as chunk-level elements, or else as containers for groups of component-level elements.

The relevant portion of the DTD looks like this:

    <!-- 3.7.7:  Standard Content Models                          -->

    <!-- Here we declare the parameter entities phrase,           -->
    <!-- phrase.seq, component, component.seq, paraContent, and   -->
    <!-- specialPara, for use in the content models of element    -->
    <!-- declarations.                                            -->

    <!-- The entities phrase and phrase.seq are the same in all   -->
    <!-- bases. They may include elements specific to single tag  -->
    <!-- sets; if the tag set is not selected, these elements     -->
    <!-- are undefined and have no effect.                        -->

    <!ENTITY % phrase '(#PCDATA | %m.phrase)'                       >
    <!ENTITY % phrase.seq '(%phrase;)*'                             >

    <!-- The entity component varies with the base. The versions  -->
    <!-- for the combined bases are declared first (so as to      -->
    <!-- take precedence over the declarations in the individual  -->
    <!-- bases).                                                  -->

    <!-- ... declarations from section 3.7.8                      -->
    <!--     (Definition of components for combined bases)        -->
    <!--     go here ...                                          -->

    <![ %TEI.prose [
    <!ENTITY % component '(%m.common)'                              >
    <!ENTITY % TEI.singleBase 'INCLUDE'                             >
    ]]&nil;>

    <![ %TEI.verse [
    <!ENTITY % component '(%m.common | %m.comp.verse)'              >
    <!ENTITY % TEI.singleBase 'INCLUDE'                             >
    ]]&nil;>

    <![ %TEI.drama [
    <!ENTITY % component '(%m.common | %m.comp.drama)'              >
    <!ENTITY % TEI.singleBase 'INCLUDE'                             >
    ]]&nil;>

    <![ %TEI.spoken [
    <!ENTITY % component '(%m.common | %m.comp.spoken)'             >
    <!ENTITY % TEI.singleBase 'INCLUDE'                             >
    ]]&nil;>

    <![ %TEI.dictionaries [
    <!ENTITY % component '(%m.common | %m.comp.dictionaries)'       >
    <!ENTITY % TEI.singleBase 'INCLUDE'                             >
    ]]&nil;>

    <![ %TEI.terminology [
    <!ENTITY % component '(%m.common | %m.comp.terminology)'        >
    <!ENTITY % TEI.singleBase 'INCLUDE'                             >
    ]]&nil;>

    <!-- Default declaration.                                     -->

    <!ENTITY % component '(%m.common)'                              >
    <!ENTITY % TEI.singleBase 'INCLUDE'                             >

    <!-- The entity component.seq is always a starred sequence    -->
    <!-- of component elements. Its definition does not vary      -->
    <!-- with the base (unless we are using the general base, in  -->
    <!-- which case it has already been defined above), but the   -->
    <!-- meaning of the definition does.                          -->

    <!ENTITY % component.seq '(%component;)*'                       >

    <!-- The following entities do not vary with the base.        -->

    <!ENTITY % paraContent '(#PCDATA | %m.phrase | %m.inter)*'      >
    <!ENTITY % specialPara '(((%m.chunk), (%component.seq)) |
    (%paraContent))'                                                >
    <!-- This fragment is used in sec. 3.7.3                      -->

### 3.7.8 Components in Mixed and General Bases

When the mixed or general base is in use, the definitions of the entities `component` and `component.seq` are rather more complex. The relevant portion of the DTD is this:

    <!-- 3.7.8:  Definition of components for combined bases      -->

    <!-- Default declarations for the 'mix.' entities used for    -->
    <!-- mixed and general bases.                                 -->

    <!ENTITY % mix.verse ''                                         >
    <!ENTITY % mix.drama ''                                         >
    <!ENTITY % mix.spoken ''                                        >
    <!ENTITY % mix.dictionaries ''                                  >
    <!ENTITY % mix.terminology ''                                   >
    <![ %TEI.mixed [
    <!ENTITY % TEI.singleBase 'IGNORE'                              >
    <!-- The mixed base allows components from any base; it does  -->
    <!-- so by defining 'component' as including both common      -->
    <!-- components and those specific to one tag set.            -->

    <!ENTITY % component '(%m.common %mix.verse %mix.drama
    %mix.spoken
    %mix.dictionaries %mix.terminology)'                            >
    ]]&nil;>

    <![ %TEI.general [
    <!-- The general base uses the same definition of component   -->
    <!-- as the mixed base.                                       -->

    <!ENTITY % TEI.singleBase 'IGNORE'                              >
    <!ENTITY % component '(%m.common %mix.verse %mix.drama
    %mix.spoken
    %mix.dictionaries %mix.terminology)'                            >
    <!-- But it defines a special version of component.seq,       -->
    <!-- which restricts each div of the text to a single base:   -->
    <!-- bases can shift only in embedded divs or at div          -->
    <!-- boundaries. This entity is constructed out of a series   -->
    <!-- of smaller entities, one for each tag set. If the tag    -->
    <!-- set is not in use, its entity will expand to the empty   -->
    <!-- string.                                                  -->

    <![ %TEI.verse [
    <!-- If the verse base is in use, ...                         -->

    <!ENTITY % gen.verse '((%m.comp.verse), (%m.common |
    %m.comp.verse)*) |'                                             >
    ]]&nil;>

    <![ %TEI.drama [
    <!-- If the drama base is in use, ...                         -->

    <!ENTITY % gen.drama '((%m.comp.drama), (%m.common |
    %m.comp.drama)*) |'                                             >
    ]]&nil;>

    <![ %TEI.spoken [
    <!-- If the spoken base is in use, ...                        -->

    <!ENTITY % gen.spoken '((%m.comp.spoken), (%m.common |
    %m.comp.spoken)*) |'                                            >
    ]]&nil;>

    <![ %TEI.dictionaries [
    <!-- If the dictionary base is in use, ...                    -->

    <!ENTITY % gen.dictionaries '((%m.comp.dictionaries),
    (%m.common | %m.comp.dictionaries)*) |'                         >
    ]]&nil;>

    <![ %TEI.terminology [
    <!-- If the terminology base is in use, ...                   -->

    <!ENTITY % gen.terminology '((%m.comp.terminology), (%m.common
    | %m.comp.terminology)*) |'                                     >
    ]]&nil;>

    <!-- Default declarations for all the entities gen.verse,     -->
    <!-- etc.                                                     -->

    <!ENTITY % gen.verse ''                                         >
    <!ENTITY % gen.drama ''                                         >
    <!ENTITY % gen.spoken ''                                        >
    <!ENTITY % gen.dictionaries ''                                  >
    <!ENTITY % gen.terminology ''                                   >

    <!-- Now we are ready to declare component.seq and            -->
    <!-- component.plus for use in general base tag set.          -->

    <!ENTITY % component.seq '(%m.common)*, (%gen.verse %gen.drama
    %gen.spoken %gen.dictionaries
    %gen.terminology TEI...end)?'                                   >
    <!ENTITY % component.plus '(%gen.verse %gen.drama %gen.spoken
    %gen.dictionaries %gen.terminology
    TEI...end)
    |
    (
    (%m.common)+, (%gen.verse %gen.drama %gen.spoken
    %gen.dictionaries
    %gen.terminology TEI...end)?'                                   >

    <!-- (End of marked section for general base.)                -->

    ]]&nil;>

    <!-- This fragment is used in sec. 3.7.7                      -->

### 3.7.9 Miscellaneous Content-Model Classes

The following element classes occupy specific places in content models; some are relevant only when certain tag sets are selected

- `agent` elements which denote an individual or organization to whom or which responsibility for an action can be assigned
- `addrPart` elements which can occur as part of an address
- `biblPart` elements which can occur in bibliographic citations
- `demographic` elements which record demographic characteristics of the participants in a text or language interaction (used in tag set for corpora and collections)
- `divbot` elements which can occur as part of the closing material of a text division or body
- `divtop` elements which can occur as part of the opening material of a text division or body
- `dramafront` elements which can occur in the front matter of drama and other performance texts
- `front` elements which can occur (at the level of text divisions) in front matter only
- `personPart` elements which contain parts of a personal name
- `placePart` elements which contain parts of a place name
- `tpParts` elements which occur within title pages
- `fmchunk` elements which can occur in place of a title page in front matter only

They are declared in the following DTD fragment:

    <!-- 3.7.9:  Misc. Element Class Models                       -->
    <!ENTITY % x.agent ''                                           >
    <!ENTITY % m.agent '%x.agent name'                              >
    <!ENTITY % x.addrPart ''                                        >
    <!ENTITY % m.addrPart '%x.addrPart name | postBox | postCode |
               street'                                              >
    <!ENTITY % x.biblPart ''                                        >
    <!ENTITY % m.biblPart '%x.biblPart analytic | author |
               biblScope | edition | editor | extent | idno |
               imprint | monogr | note | publisher | pubPlace |
               respStmt | series'                                   >
    <!ENTITY % x.demographic ''                                     >
    <!ENTITY % m.demographic '%x.demographic affiliation | birth |
               education | firstLang | langKnown | occupation |
               persName | residence | socecStatus'                  >
    <!ENTITY % x.divbot ''                                          >
    <!ENTITY % m.divbot '%x.divbot byline | closer | dateline |
               epigraph | salute | signed | trailer'                >
    <!ENTITY % x.divtop ''                                          >
    <!ENTITY % m.divtop '%x.divtop argument | byline | dateline |
               docAuthor | docDate | epigraph | head | opener |
               salute | signed'                                     >
    <!ENTITY % x.dramafront ''                                      >
    <!ENTITY % m.dramafront '%x.dramafront castList | epilogue |
               performance | prologue | set'                        >
    <!ENTITY % x.front ''                                           >
    <!ENTITY % m.front '%x.front %m.dramafront; | divGen |
               titlePage'                                           >
    <!ENTITY % x.personPart ''                                      >
    <!ENTITY % m.personPart '%x.personPart addName | forename |
               genName | nameLink | roleName | surname'             >
    <!ENTITY % x.placePart ''                                       >
    <!ENTITY % m.placePart '%x.placePart bloc | country | distance
               | geog | offset | region | settlement'               >
    <!ENTITY % x.tpParts ''                                         >
    <!ENTITY % m.tpParts '%x.tpParts byline | docAuthor | docDate |
               docEdition | docImprint | docTitle | epigraph |
               figure | imprimatur | titlePart'                     >
    <!ENTITY % x.fmchunk ''                                         >
    <!ENTITY % m.fmchunk '%x.fmchunk argument | byline | docAuthor
               | docDate | docEdition | docImprint | docTitle |
               epigraph | head | titlePart'                         >
    <!-- This fragment is used in sec. 3.7.3                      -->

## 3.8 Other Parameter Entities in TEI DTDs

The TEI DTDs use SGML parameter entities for several purposes:

- to define sets of attributes shared by given classes of elements
- to define classes of elements which can occur at the same locations in content models
- to identify what base tag set should be used for a document
- to identify what additional tag sets should be included
- to include or exclude the declaration of each element
- to specify the name of each element

The first two applications of parameter entities are described above in section 3.7 . This chapter describes the other uses of parameter entities in the TEI DTDs.

The parameter entities used to specify which base tag set and which additional tag sets are to be used in a given document are listed in section 3.2 . Their default definition is always ``IGNORE'': the encoder selects the TEI base and additional tag sets by declaring the appropriate parameter entities with the entity text ``INCLUDE''.

The DTD and entity files are listed in section 3.2 ; if the standard TEI entities are modified to point at locally developed DTD files containing local modifications or extensions to the TEI DTDs, the use of the standard parameter entity names ensures that the modification will be obvious upon examination of the document's DTD.

The following entities are referred to by the main `tei2.dtd` file to embed portions of the TEI DTDs or locally developed extensions.

- `TEI.extensions.ent` identifies a local file containing extensions to the TEI parameter entities; see section 3.6.2
- `TEI.extensions.dtd` identifies a local file containing extensions to the TEI tag set; see section 3.6.2
- `TEI.elementNames` identifies a file containing parameter entity declarations for names of TEI elements; see section 3.8.2
- `TEI.keywords` identifies a file containing parameter entity declarations for TEI keywords, including the default declaration (``IGNORE'') of the marked-section keyword for each tag set; see section 3.8.3
- `TEI.elementClasses` identifies a file containing definitions of parameter entities used in content models; see section 3.7.3
- `TEI.singleBase` defined as `INCLUDE` (for normal bases) or `IGNORE` (for mixed and general base); used to prevent multiple definitions of the default text structure.

### 3.8.1 Inclusion and Exclusion of Elements

The TEI DTDs use marked sections and parameter entity references to allow users to exclude the definitions of individual elements, in order either to make the elements illegal in a document or to allow the element to be redefined, as further described in chapter 29 .

Parameter entities used for this purpose have exactly the same name as the generic identifier of the element concerned. The default definition for these parameter entities is ``INCLUDE'' but they may be changed to ``IGNORE'' in order to exclude the standard element and attribute definition list declarations from the DTD.

The declarations for the element `<p>` , for example, are preceded by a definition for a parameter entity with the name `p` and contained within a marked section whose keyword is given as ``%p;'':

     <!ENTITY % p 'INCLUDE' >
     <![ %p; [
            <!-- element and attlist declaration for p here -->
     ]]>

These parameter entities are defined immediately preceding the element whose declarations they control; because their names are completely regular, they are not documented individually in the reference section of this document.

### 3.8.2 Parameter Entities for Element Generic Identifiers

In the TEI DTDs, elements are not referred to directly by their generic identifiers; instead, the DTDs refer to parameter entities which expand to the standard generic identifiers. This allows users to rename elements by redefining the appropriate parameter entity (as described more fully in chapter 29 ). Parameter entities used for this purpose are formed by taking the standard name (generic identifier) of the element and attaching the string ``n.'' as a prefix. Thus the standard generic identifiers for paragraphs, notes, and quotations, `<p>` , `<note>` , and `<q>` are defined by declarations of the following form:

     <!ENTITY % n.p    'p' >
     <!ENTITY % n.note 'note' >
     <!ENTITY % n.q    'q' >

Since by default parameter entities are case-sensitive, the specific mix of upper and lower case letters in the standard name must be preserved in the entity name.

The formal declarations of the parameter entities used for generic identifiers are contained in the file `teigis2.ent` ; since their names and replacement texts are fully predictable, these parameter entities are not individually documented in the reference section of these Guidelines. The parameter entity `TEI.elementNames` is used to embed the file `teigis2.ent` in the DTD. A full set of alternate generic identifiers can be substituted for the standard set by defining `TEI.elementNames` to point at a different file. [ see note 24 ]

### 3.8.3 Parameter Entities for TEI Keywords

The TEI uses the following parameter entities to signal information which cannot be expressed using SGML keywords:

- INHERITED indicates that an attribute value is inherited from the enclosing element, if not specified
- ISO-date indicates that an attribute value should be a legal ISO date in the form yyyy-mm-dd (e.g. 1993-06-28).
- extptr indicates that an attribute value should be a legal expression in the TEI extended-pointer notation

In addition, the parameter entities which control the selection of base and additional tag sets may be regarded as a keyword.

The parameter entity `INHERITED` is used to signal that the default value for an attribute should be inherited from an enclosing element. The definition for `INHERITED` is the string ``#IMPLIED''; as for all implied defaults, the application program is responsible for deducing the default attribute value when no value is specified in the element start-tag. Since the parameter entity is resolved by the SGML parser, the application program will see no difference between attributes whose default is ``%INHERITED'' and those whose default is ``#IMPLIED'' --- information about which attribute values are inherited and which are inferred in some other way must be built into the application in advance.

The parameter entity `ISO-date` is used to signal that the value for an attribute should be an ISO-standard date value; in this notation, [ see note 25 ] a date like ``September 22, 1968'' would be written ``1968-09-22''. The parameter entity `ISO-date` expands to ``CDATA''.

The keywords controlling the selection of base and additional tag sets (described in section 3.2 ) all have the default value ``IGNORE''; the user can override this by a local declaration, as described in section 3.3 .

The parameter entities for TEI keywords are included in file `teikey2.dtd` , which is the default replacement text for the entity `TEI.keywords` and is embedded by the file `tei2.dtd` .

The file `teikey2.dtd` has the following contents:

    <!-- 3.8.3:  TEI Keywords                                     -->

    <!-- I.  Declare TEI keywords for data types.                 -->

    <!-- These parameter entities are used as keywords to         -->
    <!-- express rules or constraints which cannot be fully       -->
    <!-- expressed in SGML; their expansions show the nearest     -->
    <!-- SGML equivalent.                                         -->

    <!ENTITY % INHERITED '#IMPLIED'                                 >
    <!ENTITY % ISO-date 'CDATA'                                     >
    <!ENTITY % extPtr 'CDATA'                                       >

    <!-- II.  Declare keywords for tag-set selection.             -->

    <!-- Declare all bases and additional tag sets as 'IGNORE'.   -->
    <!-- The user can override this default by declaring the      -->
    <!-- same entity with the replacement text 'INCLUDE', in the  -->
    <!-- document's DTD subset.                                   -->

    <!-- Base tag sets first.                                     -->

    <!ENTITY % TEI.prose 'IGNORE'                                   >
    <!ENTITY % TEI.verse 'IGNORE'                                   >
    <!ENTITY % TEI.drama 'IGNORE'                                   >
    <!ENTITY % TEI.spoken 'IGNORE'                                  >
    <!ENTITY % TEI.dictionaries 'IGNORE'                            >
    <!ENTITY % TEI.terminology 'IGNORE'                             >

    <!-- Now the mixed bases.                                     -->

    <!ENTITY % TEI.general 'IGNORE'                                 >
    <!ENTITY % TEI.mixed 'IGNORE'                                   >

    <!-- Now additional tag sets.                                 -->

    <!ENTITY % TEI.linking 'IGNORE'                                 >
    <!ENTITY % TEI.analysis 'IGNORE'                                >
    <!ENTITY % TEI.fs 'IGNORE'                                      >
    <!ENTITY % TEI.certainty 'IGNORE'                               >
    <!ENTITY % TEI.transcr 'IGNORE'                                 >
    <!ENTITY % TEI.textcrit 'IGNORE'                                >
    <!ENTITY % TEI.names.dates 'IGNORE'                             >
    <!ENTITY % TEI.nets 'IGNORE'                                    >
    <!ENTITY % TEI.figures 'IGNORE'                                 >
    <!ENTITY % TEI.corpus 'IGNORE'                                  >

The relevant portion of the main DTD looks like this:

    <!-- 3.8.3:  TEI Keywords                                     -->
    <!-- We declare and immediately embed the TEI keywords file.  -->

    <!ENTITY % TEI.keywords.ent system 'teikey2.ent'                >
    %TEI.keywords.ent;
    <!-- This fragment is used in sec. 3.6.1                      -->

Previous | Up | Next