Prefatory note

TEI Lite was the name adopted for what the TEI editors originally conceived of as a simple demonstration of how the TEI (Text Encoding Initiative) encoding scheme might be adopted to meet 90% of the needs of 90% of the TEI user community. In retrospect, it was predictable that many people should imagine TEI Lite to be all there is to TEI, or find TEI Lite to be far too heavy for their needs.

The original TEI Lite (1996) was based largely on observations of existing and previous practice in the encoding of texts, particularly as manifest in the collections of the Oxford Text Archive and other collections of the period. It is therefore unsurprising that it seems to have become, if not a de facto standard, at least a common point of departure for electronic text centres and encoding projects world wide. Maybe the fact that we actually produced this shortish, readable, manual for it also helped.

Early adopters of TEI Lite included a number of ‘Electronic Text Centers’ and digital library initiatives. It was also adopted as the basis for some early TEI-conformant authoring systems, and as the basis for introductory tutorials, many of them in languages other than English (see further the list of legacy versions at http://www.tei-c.org/Vault/P4/Lite/).

In 2002, following the publication of TEI P4, the XML version of the TEI Guidelines, which uses the generation of TEI Lite as an example of the TEI modification mechanism, the opportunity was taken to produce a lightly revised XML-conformant version. In 2006, a more substantially revised version based on TEI P5 was produced; this reflected the many changes between TEI P4 and TEI P5, but was not otherwise significantly different. In 2012, the TEI Technical Council, decided that a final revision should be undertaken to ensure that the documentation remained consistent with the latest (2.1) release of TEI P5. This version uses a recently added mechanism in the TEI customization architecture, which permits a customization to define only the TEI elements to be included in a schema, rather than the elements to be excluded from it. As such it is probably more resilient to change than earlier versions.

1. Introduction

The Text Encoding Initiative (TEI) Guidelines are addressed to anyone who wants to interchange information stored in an electronic form. They emphasize the interchange of textual information, but other forms of information such as images and sound are also addressed. The Guidelines are equally applicable in the creation of new resources and in the interchange of existing ones.

The Guidelines provide a means of making explicit certain features of a text in such a way as to aid the processing of that text by computer software running on different machines. This process of making explicit we call markup or encoding. Any textual representation on a computer uses some form of markup; the TEI came into being partly because of the enormous variety of mutually incomprehensible encoding schemes currently besetting scholarship, and partly because of the expanding range of scholarly uses now being identified for texts in electronic form.

The TEI Guidelines describe an encoding scheme which can be expressed using a number of different formal languages. The first editions of the Guidelines used the Standard Generalized Markup Language (SGML); since 2002, this has been replaced by the use of the Extensible Markup Language (XML). These markup languages have in common the definition of text in terms of elements and attributes, and rules governing their appearance within a text. The TEI's use of XML is ambitious in its complexity and generality, but it is fundamentally no different from that of any other XML markup scheme, and so any general-purpose XML-aware software is able to process TEI-conformant texts.

Since 2001, the TEI has been a community initiative supported by an international membership consortium. It was originally an international research project sponsored by the Association for Computers and the Humanities, the Association for Computational Linguistics, and the Association for Literary and Linguistic Computing, with substantial funding over its first five years from the U.S. National Endowment for the Humanities, Directorate General XIII of the Commission of the European Communities, the Andrew W. Mellon Foundation, the Social Science and Humanities Research Council of Canada and others. The Guidelines were first published in May 1994, after six years of development involving many hundreds of scholars from different academic disciplines worldwide. During the years that followed, the Guidelines became increasingly influential in the development of the digital library, in the language industries, and even in the development of the World Wide Web itself. The TEI Consortium was set up in January 2001, and a year later produced an edition of the Guidelines entirely revised for XML compatibility. In 2004, it set about a major revision of the Guidelines to take full advantage of new schema languages, the first release of which appeared in 2005. This revision of the TEI Lite document conforms to version 2.1 of this most recent edition of the Guidelines, TEI P5, released in June 2012.

At the outset of its work, the overall goals of the TEI were defined by the closing statement of a planning conference held at Vassar College, N.Y., in November, 1987; these ‘Poughkeepsie Principles’ were further elaborated in a series of design documents. The Guidelines, say these design documents, should:

• suffice to represent the textual features needed for research;
• be simple, clear, and concrete;
• be easy for researchers to use without special-purpose software;
• allow the rigorous definition and efficient processing of texts;
• provide for user-defined extensions;
• conform to existing and emergent standards.

The world of scholarship is large and diverse. For the Guidelines to have wide acceptability, it was important to ensure that:

1. the common core of textual features be easily shared;
2. additional specialist features be easy to add to (or remove from) a text;
3. multiple parallel encodings of the same feature should be possible;
4. the richness of markup should be user-defined, with a very small minimal requirement;
5. adequate documentation of the text and its encoding should be provided.

The present document describes a manageable selection from the extensive set of elements and recommendations resulting from those design goals, which is called TEI Lite.

In selecting from the several hundred elements defined by the full TEI scheme, we have tried to identify a useful ‘starter set’, comprising the elements which almost every user should know about. Experience working with TEI Lite will be invaluable in understanding the full TEI scheme and in knowing how to integrate specialized parts of it into the general TEI framework.

Our goals in defining this subset may be summarized as follows:

• it should be able to handle adequately a reasonably wide variety of texts, at the level of detail found in existing practice (as demonstrated in, for example, the holdings of the Oxford Text Archive);
• it should be useful for the production of new documents (such as this one) as well as the encoding of existing texts;
• it should be usable with a wide range of existing XML software;
• it should be a pure subset of the full TEI scheme and defined using the customizaticon methods described in the TEI Guidelines;
• it should be as small and simple as is consistent with the other goals.

The reader may judge our success in meeting these goals for him or herself.

Although we have tried to make this document self-contained, as suits a tutorial text, the reader should be aware that it does not cover every detail of the TEI encoding scheme. All of the elements described here are fully documented in the TEI Guidelines themselves, which should be consulted for authoritative reference information on these, and on the many others which are not described here. Some basic knowledge of XML is assumed.

2. A Short Example

We begin with a short example, intended to show what happens when a passage of prose is typed into a computer by someone with little sense of the purpose of mark-up, or the potential of electronic texts. In an ideal world, such output might be generated by a very accurate optical scanner. It attempts to be faithful to the appearance of the printed text, by retaining the original line breaks, by introducing blanks to represent the layout of the original headings and page breaks, and so forth. Where characters not available on the keyboard are needed (such as the accented letter a in faàl or the long dash), it attempts to mimic their appearance.

                                CHAPTER 38

READER, I married him. A quiet wedding we had: he and I, the par-
son and clerk, were alone present. When we got back from church, I
went into the kitchen of the manor-house, where Mary was cooking
the dinner, and John cleaning the knives, and I said --
  'Mary, I have been married to Mr Rochester this morning.' The
housekeeper and her husband were of that decent, phlegmatic
order of people, to whom one may at any time safely communicate a
remarkable piece of news without incurring the danger of having
one's ears pierced by some shrill ejaculation and subsequently stunned
by a torrent of wordy wonderment. Mary did look up, and she did
stare at me; the ladle with which she was basting a pair of chickens
roasting at the fire, did for some three minutes hang suspended in air,
and for the same space of time John's knives also had rest from the
polishing process; but Mary, bending again over the roast, said only --
   'Have you, miss? Well, for sure!'
   A short time after she pursued, 'I seed you go out with the master,
but I didn't know you were gone to church to be wed'; and she
basted away. John, when I turned to him, was grinning from ear to
ear.
   'I telled Mary how it would be,' he said: 'I knew what Mr Ed-
ward' (John was an old servant, and had known his master when he
was the cadet of the house, therefore he often gave him his Christian
name) -- 'I knew what Mr Edward would do; and I was certain he
would not wait long either: and he's done right, for aught I know. I
wish you joy, miss!' and he politely pulled his forelock.
   'Thank you, John. Mr Rochester told me to give you and Mary
this.'
   I put into his hand a five-pound note.  Without waiting to hear
more, I left the kitchen. In passing the door of that sanctum some time
after, I caught the words --
   'She'll happen do better for him nor ony o' t' grand ladies.' And
again, 'If she ben't one o' th' handsomest, she's noan faa\l, and varry
good-natured; and i' his een she's fair beautiful, onybody may see
that.'
   I wrote to Moor House and to Cambridge immediately, to say what
I had done: fully explaining also why I had thus acted. Diana and

                            474

                 JANE EYRE                      475

Mary approved the step unreservedly. Diana announced that she
would just give me time to get over the honeymoon, and then she
would come and see me.
   'She had better not wait till then, Jane,' said Mr Rochester, when I
read her letter to him; 'if she does, she will be too late, for our honey-
moon will shine our life long: its beams will only fade over your
grave or mine.'
   How St John received the news I don't know: he never answered
the letter in which I communicated it: yet six months after he wrote
to me, without, however, mentioning Mr Rochester's name or allud-
ing to my marriage. His letter was then calm, and though very serious,
kind. He has maintained a regular, though not very frequent correspond-
ence ever since: he hopes I am happy, and trusts I am not of those who
live without God in the world, and only mind earthly things.

      

This transcription suffers from a number of shortcomings:

• the page numbers and running titles are intermingled with the text in a way which makes it difficult for software to disentangle them;
• no distinction is made between single quotation marks and apostrophe, so it is difficult to know exactly which passages are in direct speech;
• the preservation of the copy text's hyphenation means that simple-minded search programs will not find the broken words;
• the accented letter in faàl and the long dash have been rendered by ad hoc keying conventions which follow no standard pattern and will be processed correctly only if the transcriber remembers to mention them in the documentation;
• paragraph divisions are marked only by the use of white space, and hard carriage returns have been introduced at the end of each line. Consequently, if the size of type used to print the text changes, reformatting will be problematic.

This particular encoding represents a set of choices or priorities. As a trivial example, note that in the second example, end-of-line hyphenation has been silently removed. Conceivably Brontë (or her printer) intended the word ‘honeymoon’ to appear as ‘honey-moon’ on its second appearance, though this seems unlikely: our decision to focus on Brontë's text, rather than on the printing of it in this particular edition, makes it impossible to be certain. This is an instance of the fundamental selectivity of any encoding. An encoding makes explicit only those textual features of importance to the encoder. It is not difficult to think of ways in which the encoding of even this short passage might readily be extended. For example:

• a regularized form of the passages in dialect could be provided;
• footnotes glossing or commenting on any passage could be added;
• pointers linking parts of this text to others could be added;
• proper names of various kinds could be distinguished from the surrounding text;
• detailed bibliographic information about the text's provenance and context could be prefixed to it;
• a linguistic analysis of the passage into sentences, clauses, words, etc., could be provided, each unit being associated with appropriate category codes;
• the text could be segmented into narrative or discourse units;
• systematic analysis or interpretation of the text could be included in the encoding, with potentially complex alignment or linkage between the text and the analysis, or between the text and one or more translations of it;
• passages in the text could be linked to images or sound held on other media.

TEI-recommended ways of carrying out most of these are described in the remainder of this document. The TEI scheme as a whole also provides for an enormous range of other possibilities, of which we cite only a few:

• detailed analysis of the components of names;
• detailed meta-information providing thesaurus-style information about the text's origins or topics;
• information about the printing history or manuscript variations exhibited by a particular series of versions of the text.

For recommendations on these and many other possibilities, the full Guidelines should be consulted.

3. The Structure of a TEI Text

All TEI-conformant texts contain (a) a TEI header (marked up as a <teiHeader> element) and (b) the transcription of the text proper (marked up as a <text> element). These two elements are combined together to form a single <TEI> element, which must be declared within the TEI namespace¹.

The TEI header provides information analogous to that provided by the title page of a printed text. It has up to four parts: a bibliographic description of the machine-readable text, a description of the way it has been encoded, a non-bibliographic description of the text (a text profile), and a revision history. The header is described in more detail in section [[undefined U5-header]].

A TEI text may be unitary (a single work) or composite (a collection of single works, such as an anthology). In either case, the text may have an optional front or back. In between is the body of the text, which, in the case of a composite text, may consist of groups, each containing more groups or texts.

In the remainder of this document, we discuss chiefly simple text structures. The discussion in each case consists of a short list of relevant TEI elements with a brief definition of each, followed by definitions for any attributes specific to that element, and a reference to any classes of which the element is a member. These references are linked to full specifications for each object, as given in the TEI Guidelines. In most cases, short examples are also given.

For example, here are the elements discussed so far:

• TEI (TEI document) contains a single TEI-conformant document, containing a single TEI header, a single text, one or more members of the model.resourceLike class, or a combination of these. A series of <TEI> elements may be combined together to form a <teiCorpus> element.
• teiHeader (TEI header) supplies the descriptive and declarative information making up an electronic title page for every TEI-conformant document.
• text contains a single text of any kind, whether unitary or composite, for example a poem or drama, a collection of essays, a novel, a dictionary, or a corpus sample.
• UNKNOWN ELEMENT teiCorpus

4. Encoding the Body

As indicated above, a simple TEI document at the textual level consists of the following elements:

• front (front matter) contains any prefatory matter (headers, title page, prefaces, dedications, etc.) found at the start of a document, before the main body.
• group contains the body of a composite text, grouping together a sequence of distinct texts (or groups of such texts) which are regarded as a unit for some purpose, for example the collected works of an author, a sequence of prose essays, etc.
• body (text body) contains the whole body of a single unitary text, excluding any front or back matter.
• back (back matter) contains any appendixes, etc. following the main part of a text.

Elements specific to front and back matter are described below in section [[undefined U5-fronbac]]. In this section we discuss the elements making up the body of a text.

5. Page and Line Numbers

Page and line breaks etc. may be marked with the following elements.

• UNKNOWN ELEMENT pb
• UNKNOWN ELEMENT lb
• UNKNOWN ELEMENT milestone

These elements mark a single point in the text, not a span of text. The global n attribute should be used to supply the number of the page or line beginning at the tag.

When working from a paginated original, it is often useful to record its pagination, if only to simplify later proof-reading. It is also useful for synchronizing an encoded text with a set of page images. Recording the line breaks may be useful for similar reasons.

A special attribute break may be used to indicate whether or not this empty element is considered as a word-breaking, irrespective of any adjacent whitespace. For example, in the following encoded sample:

The <pb> and <lb> elements are special cases of the general class of milestone elements which mark reference points within a text. The generic <milestone> element can mark any kind of reference point: for example, a column break, the start of a new kind of section not otherwise tagged, or in general any significant change in the text not marked by an XML element. The names used for types of unit and for editions referred to by the ed and unit attributes may be chosen freely, but should be documented in the header <refsDecl> element (see [[undefined refsdecl]]). The <milestone> element may be used to replace the others, or the others may be used as a set; they should not be mixed arbitrarily.

6. Marking Highlighted Phrases

7. Notes

All notes, whether printed as footnotes, endnotes, marginalia, or elsewhere, should be marked using the same element:

• UNKNOWN ELEMENT note

Where possible, the body of a note should be inserted in the text at the point at which its identifier or mark first appears. This may not be possible for example with marginalia, which may not be anchored to an exact location. For simplicity, it may be adequate to position marginal notes before the relevant paragraph or other element. Notes may also be placed in a separate division of the text (as end-notes are, in printed books) and linked to the relevant portion of the text using their target attribute.

The n attribute may be used to supply the number or identifier of a note if this is required. The resp attribute should be used consistently to distinguish between authorial and editorial notes, if the work has both kinds.

8. Cross References and Links

Explicit cross references or links from one point in a text to another in the same or another document may be encoded using the elements described in this section. Implicit links (such as the association between two parallel texts, or that between a text and its interpretation) may be encoded using the linking attributes discussed in section [[undefined xatts]].

9. Editorial Interventions

The process of encoding an electronic text has much in common with the process of editing a manuscript or other text for printed publication. In either case a conscientious editor may wish to record both the original state of the source and any editorial correction or other change made in it. The elements discussed in this and the next section provide some facilities for meeting these needs.

... for his nose was as sharp as a pen and a table of green feelds

10. Names, Dates, and Numbers

The TEI scheme defines elements for a large number of ‘data-like’ features which may appear almost anywhere within almost any kind of text. These features may be of particular interest in a range of disciplines; they all relate to objects external to the text itself, such as the names of persons and places, numbers and dates. They also pose particular problems for many natural language processing (NLP) applications because of the variety of ways in which they may be presented within a text. The elements described here, by making such features explicit, reduce the complexity of processing texts containing them.

11. Lists

The element <list> is used to mark any kind of list. A list is a sequence of text items, which may be numbered, bulleted, or arranged as a glossary list. Each item may be preceded by an item label (in a glossary list, this label is the term being defined):

• UNKNOWN ELEMENT list
• UNKNOWN ELEMENT item
• UNKNOWN ELEMENT label

Where the internal structure of a list item is more complex, it may be preferable to regard the list as a table, for which special-purpose tagging is defined below ([[undefined U5-tables]]).

Lists of bibliographic items should be tagged using the <listBibl> element, described in the next section.

12. Bibliographic Citations

It is often useful to distinguish bibliographic citations where they occur within texts being transcribed for research, if only so that they will be properly formatted when the text is printed out. The element <bibl> is provided for this purpose. Where the components of a bibliographic reference are to be distinguished, the following elements may be used as appropriate. It is generally useful to mark at least those parts (such as the titles of articles, books, and journals) which will need special formatting. The other elements are provided for cases where particular interest attaches to such details.

• bibl (bibliographic citation) contains a loosely-structured bibliographic citation of which the sub-components may or may not be explicitly tagged.
• author in a bibliographic reference, contains the name(s) of an author, personal or corporate, of a work; for example in the same form as that provided by a recognized bibliographic name authority.
• UNKNOWN ELEMENT biblScope
• date contains a date in any format.
• editor contains a secondary statement of responsibility for a bibliographic item, for example the name of an individual, institution or organization, (or of several such) acting as editor, compiler, translator, etc.
• publisher provides the name of the organization responsible for the publication or distribution of a bibliographic item.
• pubPlace (publication place) contains the name of the place where a bibliographic item was published.
• title contains a title for any kind of work.

For lists of bibliographic citations, the <listBibl> element should be used; it may contain a series of <bibl> elements.

13. Tables

Tables represent a challenge for any text processing system, but simple tables, at least, appear in so many texts that even in the simplified TEI tag set presented here, markup for tables is necessary. The following elements are provided for this purpose:

• table contains text displayed in tabular form, in rows and columns.
• row contains one row of a table.
• cell contains one cell of a table.

14. Figures and Graphics

Not all the components of a document are necessarily textual. The most straightforward text will often contain diagrams or illustrations, to say nothing of documents in which image and text are inextricably intertwined, or electronic resources in which the two are complementary.

The encoder may simply record the presence of a graphic within the text, possibly with a brief description of its content, and may also provide a link to a digitized version of the graphic, using the following elements:

• UNKNOWN ELEMENT graphic
• figure groups elements representing or containing graphic information such as an illustration, formula, or figure.
• figDesc (description of figure) contains a brief prose description of the appearance or content of a graphic figure, for use when documenting an image without displaying it.

Any textual information accompanying the graphic, such as a heading and/or caption, may be included within the <figure> element itself, in a <head> and one or more <p> elements, as also may any text appearing within the graphic itself. It is strongly recommended that a prose description of the image be supplied, as the content of a <figDesc> element, for the use of applications which are not able to render the graphic, and to render the document accessible to vision-impaired readers. (Such text is not normally considered part of the document proper.)

15. Interpretation and Analysis

It is often said that all markup is a form of interpretation or analysis. While it is certainly difficult, and may be impossible, to distinguish firmly between ‘objective’ and ‘subjective’ information in any universal way, it remains true that judgments concerning the latter are typically regarded as more likely to provide controversy than those concerning the former. Many scholars therefore prefer to record such interpretations only if it is possible to alert the reader that they are considered more open to dispute, than the rest of the markup. This section describes some of the elements provided by the TEI scheme to meet this need.

16. Technical Documentation

Although the focus of this document is on the use of the TEI scheme for the encoding of existing ‘pre-electronic’ documents, the same scheme may also be used for the encoding of new documents. In the preparation of new documents (such as this one), XML has much to recommend it: the document's structure can be clearly represented, and the same electronic text can be re-used for many purposes — to provide both online hypertext or browsable versions and well-formatted typeset versions from a common source for example.

To facilitate this, the TEI Lite schema includes some elements for marking features of technical documents in general, and of XML-related documents in particular.

<p>A list should be encoded as
       follows: <eg><![ CDATA [ <list> <item>First item in the
       list</item> <item>Second item</item> </list> ]]> </eg> The
       <gi>list</gi> element consists of a series of <gi>item</gi>
       elements.

17. Character Sets, Diacritics, etc.

With the advent of XML and its adoption of Unicode as the required character set for all documents, most problems previously associated with the representation of the divers languages and writing systems of the world are greatly reduced. For those working with standard forms of the European languages in particular, almost no special action is needed: any XML editor should enable you to input accented letters or other ‘non-ASCII’ characters directly, and they should be stored in the resulting file in a way which is transferable directly between different systems.

There are two important exceptions: the characters & and < may not be entered directly in an XML document, since they have a special significance as initiating markup. They must always be represented as entity references, like this: & or <. Other characters may also be represented by means of entity reference where necessary, for example to retain compatibility with a pre-Unicode processing system.

18. Front and Back Matter

19. The Electronic Title Page

Every TEI text has a header which provides information analogous to that provided by the title page of printed text. The header is introduced by the element <teiHeader> and has four major parts:

• fileDesc (file description) contains a full bibliographic description of an electronic file.
• encodingDesc (encoding description) documents the relationship between an electronic text and the source or sources from which it was derived.
• profileDesc (text-profile description) provides a detailed description of non-bibliographic aspects of a text, specifically the languages and sublanguages used, the situation in which it was produced, the participants and their setting.
• revisionDesc (revision description) summarizes the revision history for a file.

A corpus or collection of texts with many shared characteristics may have one header for the corpus and individual headers for each component of the corpus. In this case the type attribute indicates the type of header. <teiHeader type="corpus"> introduces the header for corpus-level information.

Some of the header elements contain running prose which consists of one or more <p>s. Others are grouped:

• Elements whose names end in Stmt (for statement) usually enclose a group of elements recording some structured information.
• Elements whose names end in Decl (for declaration) enclose information about specific encoding practices.
• Elements whose names end in Desc (for description) contain a prose description.

[title of source]: a machine readable transcription [title of source]: electronic edition A machine readable version of: [title of source]

Appendix A List of Elements Described

The TEI Lite schema is a pure subset of TEI P5. In the following list of elements and classes used, some information, notably the examples, derives from the canonical definition for the element in TEI P5 and may therefore refer to elements or attributes not provided by TEI Lite. Note however that only the elements listed here are available within the TEI Lite schema. These specifications also refer to many attributes which although available in TEI Lite are not discussed in this tutorial for lack of space.

element TEI
{
   att.global.attributes,
   ( teiHeader, ( ( model.resourceLike+, text? ) | text ) )
}

element ab
{
   att.global.attributes,
   att.typed.attributes,
   att.declaring.attributes,
   att.fragmentable.attributes,
   macro.paraContent
}

element author
{
   att.global.attributes,
   att.naming.attributes,
   macro.phraseSeq
}

element authority { att.global.attributes, macro.phraseSeq.limited }

data.enumerated

element availability
{
   att.global.attributes,
   att.declarable.attributes,
   attribute status { "free" | "unknown" | "restricted" }?,
   ( model.availabilityPart | model.pLike )+
}

element back
{
   att.global.attributes,
   att.declaring.attributes,
   (
      (
         model.frontPart
       | model.pLike.front
       | model.pLike
       | model.listLike
       | model.global
      )*,
      (
         (
            (
               ( model.div1Like ),
               ( model.frontPart | model.div1Like | model.global )*
            )
          | (
               ( model.divLike ),
               ( model.frontPart | model.divLike | model.global )*
            )
         )?
      ),
      ( ( ( model.divBottomPart ), ( model.divBottomPart | model.global )* )? )
   )
}

element bibl
{
   att.global.attributes,
   att.declarable.attributes,
   att.typed.attributes,
   att.sortable.attributes,
   att.docStatus.attributes,
   (
      text
    | model.gLike
    | model.highlighted
    | model.pPart.data
    | model.pPart.edit
    | model.segLike
    | model.ptrLike
    | model.biblPart
    | model.global
   )*
}

element body
{
   att.global.attributes,
   att.declaring.attributes,
   (
      model.global*,
      ( ( model.divTop ), ( model.global | model.divTop )* )?,
      ( ( model.divGenLike ), ( model.global | model.divGenLike )* )?,
      (
         ( ( model.divLike ), ( model.global | model.divGenLike )* )+
       | ( ( model.div1Like ), ( model.global | model.divGenLike )* )+
       | (
            ( ( model.common ), model.global* )+,
            (
               ( ( model.divLike ), ( model.global | model.divGenLike )* )+
             | ( ( model.div1Like ), ( model.global | model.divGenLike )* )+
            )?
         )
      ),
      ( ( model.divBottom ), model.global* )*
   )
}

element catDesc
{
   att.global.attributes,
   ( text | model.limitedPhrase | model.catDescPart )*
}

data.pointer

element catRef
{
   att.global.attributes,
   att.pointing.attributes,
   attribute scheme { data.pointer }?,
   empty
}

element category
{
   att.global.attributes,
   ( ( catDesc+ | ( model.descLike | model.glossLike )* ), category* )
}

element cell
{
   att.global.attributes,
   att.tableDecoration.attributes,
   macro.specialPara
}

data.pointer

element change
{
   att.ascribed.attributes,
   att.datable.attributes,
   att.docStatus.attributes,
   att.global.attributes,
   att.typed.attributes,
   attribute target { list { data.pointer+ } }?,
   macro.specialPara
}

data.pointer

element classCode
{
   att.global.attributes,
   attribute scheme { data.pointer },
   macro.phraseSeq.limited
}

element classDecl { att.global.attributes, taxonomy+ }

element creation
{
   att.global.attributes,
   att.datable.attributes,
   ( text | model.limitedPhrase | listChange )*
}

element date
{
   att.global.attributes,
   att.datable.attributes,
   att.editLike.attributes,
   att.typed.attributes,
   ( text | model.gLike | model.phrase | model.global )*
}

element distributor { att.global.attributes, macro.phraseSeq }

element div
{
   att.global.attributes,
   att.divLike.attributes,
   att.typed.attributes,
   att.declaring.attributes,
   (
      ( model.divTop | model.global )*,
      (
         (
            ( ( ( model.divLike | model.divGenLike ), model.global* )+ )
          | (
               ( ( model.common ), model.global* )+,
               ( ( model.divLike | model.divGenLike ), model.global* )*
            )
         ),
         ( ( model.divBottom ), model.global* )*
      )?
   )
}

element edition { att.global.attributes, macro.phraseSeq }

element editionStmt
{
   att.global.attributes,
   ( model.pLike+ | ( edition, model.respLike* ) )
}

element editor
{
   att.global.attributes,
   att.naming.attributes,
   macro.phraseSeq
}

element editorialDecl
{
   att.global.attributes,
   att.declarable.attributes,
   model.pLike+
}

element email { att.global.attributes, macro.phraseSeq }

element encodingDesc
{
   att.global.attributes,
   ( ( model.encodingDescPart | model.pLike )+ )
}

element extent { att.global.attributes, macro.phraseSeq }

element figDesc { att.global.attributes, macro.limitedContent }

element figure
{
   att.global.attributes,
   att.placement.attributes,
   att.typed.attributes,
   (
      model.headLike
    | model.common
    | figDesc
    | model.graphicLike
    | model.global
    | model.divBottom
   )*
}

element fileDesc
{
   att.global.attributes,
   (
      (
         titleStmt,
         editionStmt?,
         extent?,
         publicationStmt,
         seriesStmt?,
         notesStmt?
      ),
      sourceDesc+
   )
}

data.enumerated

element formula
{
   att.global.attributes,
   attribute notation { data.enumerated }?,
   ( text | model.graphicLike | model.hiLike )*
}

element front
{
   att.global.attributes,
   att.declaring.attributes,
   (
      ( ( model.frontPart | model.pLike | model.pLike.front | model.global )* ),
      (
         (
            (
               model.div1Like,
               ( model.div1Like | model.frontPart | model.global )*
            )
          | (
               model.divLike,
               ( model.divLike | model.frontPart | model.global )*
            )
         ),
         ( ( ( model.divBottom ), ( model.divBottom | model.global )* )? )
      )?
   )
}

element funder
{
   att.global.attributes,
   att.canonical.attributes,
   macro.phraseSeq.limited
}

element group
{
   att.global.attributes,
   att.declaring.attributes,
   att.typed.attributes,
   (
      ( model.divTop | model.global )*,
      ( ( text | group ), ( text | group | model.global )* ),
      model.divBottom*
   )
}

element head
{
   att.global.attributes,
   att.typed.attributes,
   (
      text
    | lg
    | model.gLike
    | model.phrase
    | model.inter
    | model.lLike
    | model.global
   )*
}

element hi { att.global.attributes, macro.paraContent }