<!-- $Id: p2st.odd,v 1.4 1998/02/01 17:38:08 tei Exp $ -->
<!--*
    * $Log: p2st.odd,v $
    * Revision 1.4  1998/02/01 17:38:08  tei
    * fix Log keyword,
    * normalize SGML
    * replace system identifiers with public identifiers.
    *
    * Revision 1.3  94/04/08  01:36:34  msmcq
    * Last-round changes before publication of P3
    *
    * Revision 1.2  1994/03/24  22:20:40  msmcq
    * typos found by David Barnard et al. corrected
    * -->
<!-- P2.213 : Structure of TEI DTDs                           -->
<!-- Revisions:                                               -->
<!-- 94-03-21f : MSM : typos and stylistic improvements       -->
<!--                   from DB, the WWP team, JLav, EBr       -->
<!-- 93-04-06 : MSM : cosmetic changes                        -->
<!-- 3 apr 93 : LB : revise for publication                   -->
<!--       stylistic changes consequent on singularization    -->
<!--       moved govt health warning about techno-detail here -->
<!-- 1993-03-16 : CMSMcQ : reorder sections to segregate      -->
<!--                       techno-detail at end of chapter    -->
<!--                       only.  Revise overview to match.   -->
<!-- 25 Jan 93 : CMSMcQ : revise lightly for publication      -->
<!-- 26 May 92 : CMSMcQ : draft intro paragraph               -->
<!-- 21 Apr 92 : CMSMcQ : retag for TEI P2, add tag docs.     -->

<div1 id="ST" n="3">
<head>Structure of the TEI Document Type Definition</head>

<!-- goal of this chapter:  make it possible to understand    -->
<!-- how all this fits together.  Some conceptual and         -->
<!-- some technical details need covering, mostly:            -->
<!-- what we are trying to do, and then how we are doing      -->
<!-- it in SGML.                                              -->

<p>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 <ptr
target="SG">.

<!--  < p > The TEI encoding scheme provides a number of      -->
<!-- modules, which function either as complete independent   -->
<!-- < term > document type declarations < /term > ( < term   -->
<!-- > DTDs < /term > ), or as  < term > DTD fragments <      -->
<!-- /term > ; both full and fragmentary DTDs we call         -->
<!-- indifferently  < term > tag sets < /term > .  We         -->
<!-- distinguish:                                             --></p>

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

<!--  < list type=bullets >                                   -->
<!--  < item > main DTDs                                      -->
<!--  < item > auxiliary DTDs                                 -->
<!--  < /list >                                               -->
<!--                                                          -->
<!-- Main DTDs in turn are made up of:                        --></p>

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

<list type="bullets">
<item>core DTD fragments</item>
<item>base DTD fragments</item>
<item>additional DTD fragments</item>
</list></p>

<p>The first two sections of this chapter discuss these distinctions and
list the specific tag sets included in each category.  Section <ptr
target="STin" type="div2"> 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.</p>

<p>The <term>global attributes</term>, characteristics postulated of
every element or tag in the encoding scheme, are defined in section
<ptr target="STga" type="div2">.</p>

<p>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 <ptr target="MD">), 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 <ptr target="STov">.  The <term>element
classes</term> used to define smaller groups of elements and their
characteristics are described in section <ptr target="STec"
type="div2">.
Both global attributes and element classes are implemented using SGML
<term>parameter entities</term>; various other uses of parameter
entities in the TEI DTDs are discussed in section <ptr target="STpe">.
</p>
<!-- $Id: p2stma.odd,v 1.3 1994/04/08 01:36:34 msmcq Exp $ -->
<!-- $Log: p2stma.odd,v $
# Revision 1.3  1994/04/08  01:36:34  msmcq
# Last-round changes before publication of P3
#
# Revision 1.2  1994/03/24  22:20:40  msmcq
# typos found by David Barnard et al. corrected
# -->
<!-- P2.131 : Main and Auxiliary DTDs                         -->
<!-- Revisions:                                               -->
<!-- 1994-03-22 : MSM : typos, corrections, improvements from -->
<!--                    DB, EBr, JLav                         -->
<!-- 1994-03-22 : MSM : retag filenames from TERM to IDENT    -->
<!-- 3 apr 93 : LB revise for publication                     -->
<!--   expand discussion of auxiliaries a bit                 -->
<!-- 1993-03162 : MSM : stylistic, suppress xref to IN        -->
<!-- 1993-02-02 : MSM : stylistic revisions                   -->
<!-- 1993-01-27 : MSM : correct SGML typo                     -->
<!-- 25 Jan 93 : CMSMcQ : reverse labels and items in gl      -->
<!-- 12 Jan 93 : CMSMcQ : revise for clarity                  -->
<!-- 21 Oct 92 : CMSMcQ : new name new id                     -->
<!-- 26 May 92 : CMSMcQ : drafted prose                       -->
<!-- 17 May 92 : CMSMcQ : began draft (outline)               -->

<div2 id=STma><head>Main and Auxiliary DTDs</head>

<!-- document itself in a main DTD, of which TEI has          -->
<!--         several flavors                                  -->
<!-- other information in auxiliary documents                 -->
<!-- list of auxiliary dtds                                   -->
<!-- tei interchange basically the main doc, plus any         -->
<!--         relevant additional things.                      -->

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

<p>All tags used to transcribe documents are available for use within
the <term>main DTD</term> 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 <ptr target=STba>.

<p>A number of <term>auxiliary DTDs</term> 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:

<list type=gloss>

<label>independent header<item>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 <ptr target=HD> and
<ptr target=SH>).

<label>writing system declaration<item>used to define and document
character sets or transliteration schemes (see chapters <ptr target=CH>
and <ptr target=WD>).

<label>feature system declaration<item>used to define and document sets
of analytic features (see chapters <ptr target=FS> and <ptr
target=FD>).

<label>tag set declaration<item>used to define and document descriptive
documentation for TEI-conformant tag sets (see chapter <ptr
target=TD>).

<!-- shd also cross ref CF? -->
</list>


<p>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.

<p>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 <ptr target=IN>.

<p>The DTD files containing these auxiliary DTDs are:
<list type=gloss>
<label><ident type=file>teishd2.dtd</ident>
<item>independent header
<label><ident type=file>teiwsd2.dtd</ident>
<item>writing system declaration
<label><ident type=file>teifsd2.dtd</ident>
<item>feature system declaration
<label><ident type=file>teitsd2.dtd</ident>
<item>tag set declaration
</list>

<p>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.
<!-- 1 Main and Aux DTDs      -->
<!-- $Id: p2stba.odd,v 1.4 1994/04/08 18:54:36 msmcq Exp $ -->
<!-- $Log: p2stba.odd,v $
# Revision 1.4  1994/04/08  18:54:36  msmcq
# Last-second fixes for P3
#
# Revision 1.3  1994/04/08  01:36:34  msmcq
# Last-round changes before publication of P3
#
# Revision 1.2  1994/03/24  22:20:40  msmcq
# typos found by David Barnard et al. corrected
# -->
<!-- P2STba: Base Tag Sets and Additional Tag Sets            -->
<!-- was:  P2.132                                             -->
<!-- Revisions:                                               -->
<!-- 94-04-08 : MSM : fix typo / invalid tag                  -->
<!-- 94-04-07 : MSM : typos from MSM                          -->
<!-- 94-03-22 : MSM : typos from DB, JLav, EBr                -->
<!-- 94-03-22 : MSM : retag some TERMs, Qs, as CODE, IDENT    -->
<!-- 94-03-21 : MSM : typos and stylistic changes from WWP    -->
<!--                  team, to whom thanks                    -->
<!-- 93-04-06 : MSM : cosmetic, stylistic, and one typo fixed -->
<!-- 3 apr 93 : LB revise for publication                     -->
<!--  further revamping for clarity  -->
<!-- 93-03-30 : MSM : late changes before giving to LB        -->
<!-- 93-03-29 : MSM : correct ref:  AH to CC                  -->
<!-- 93-03-16 : MSM : revamp for clarity:                     -->
<!--                  list all tagset-related entities        -->
<!--                  include and list only used entities     -->
<!--                  add sec on user-defined tag sets        -->
<!--                    (despite its effect on clarity!)      -->
<!-- 93-03-06 : MSM : minor stylistic changes for clarity     -->
<!-- 93-03-06 : MSM : some additions for completeness         -->
<!-- 93-03-04 : MSM : change lists to type=gloss              -->
<!-- 93-03-01 : MSM : vicious shortening of intro (to 115)    -->
<!-- 93-02-02 : MSM : add marked section mechanism            -->
<!-- 93-02-02 : MSM : merge PC and VM versions                -->
<!-- 93-02-01 : MSM : revision, add detail                    -->
<!-- 93-01-27 : MSM : add more DTD fragments                  -->
<!-- 25 Jan 93 : CMSMcQ : revise, fill out a bit.             -->
<!-- 21 Oct 92 : CMSMcQ : new name new id, add mix, gen       -->
<!-- 26 May 92 : CMSMcQ : add file names                      -->
<!-- 26 May 92 : CMSMcQ : draft prose (begin)                 -->
<!-- 17 May 92 : CMSMcQ : began draft (outline)               -->

<div2 id=STba><head>Core, Base, and Additional Tag Sets</head>

<!-- definition of base and additional                        -->
<!-- arbitrary combination of additionals                     -->
<!-- list of each type in this draft (sec. 3, 4)              -->
<!-- 'core' tags an 'additional' set you get free             -->
<!-- how you specify which base and which toppings?           -->
<!--         see invocations...                               -->

<p>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:

<list type=gloss>

<label><term>core tag sets</term> <item>standard components of the TEI
main DTD in all its forms; these are always included without any special
action by the encoder;

<label><term>base tag sets</term> <item>basic
building blocks for specific text types; exactly one base must be
selected by the encoder (unless one of the <soCalled>combined</soCalled>
bases is used);

<label><term>additional tag sets</term> <item>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.

</list>

Each tag set is contained in one or more system files, which are
defined by appropriate SGML <term>parameter entity declarations</term>
and invoked as a unit by appropriate SGML
<term>parameter entity references</term>.
<note>A <term>parameter entity</term> is an SGML entity used only in
markup declarations; references to parameter entities are delimited by a
percent sign and a semicolon rather than the ampersand and colon used
for <term>general entity</term> references.  The entity <ident
type=pe>TEI.core.ent</ident>, for example, would be referred to using
the string <code>%TEI.core.ent;</code>.  Parameter entities can also be
used to control the inclusion or exclusion of <term>marked
sections</term> of the document or DTD; the TEI DTD uses marked
sections to handle the selection of different base and additional tag
sets.</note>
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 <ident type=class
rend=noindex>xxx</ident>, the following parameter entities may be
encountered:

<list type=gloss>

<label>TEI.xxx <item>used to enable or disable tag set <ident type=class
rend=noindex>xxx</ident>; must have the value <code
type=kw>INCLUDE</code> (tag set is enabled) or, by default, <code
type=kw>IGNORE</code> (tag set not enabled).

<label>TEI.xxx.ent <item>refers to a system file containing any
parameter entity declarations unique to tag set <ident type=class
rend=noindex>xxx</ident>.

<label>TEI.xxx.dtd <item>refers to a system file containing the element
and attribute list declarations for tag set <ident type=class
rend=noindex>xxx</ident>.

<label>a.xxx <item>contains definitions of attributes which are to be
added to the set of global attributes when tag set <ident type=class
rend=noindex>xxx</ident> is enabled.

<label>m.comp.xxx <item>if <ident type=class rend=noindex>xxx</ident> 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
<ptr target=STec>).

<label>mix.xxx <item>a special entity for use in defining the set of
component-level elements when the mixed base tag set is in use.

<label>gen.xxx <item>a special entity for use in defining the set of
component-level elements when the general base tag set is in use.

<!--  < label > tagset.seq  < item > contains a list of all   -->
<!-- chunk- and inter-level elements legal in a base tag      -->
<!-- set (both those unique to it, and those defined in the   -->
<!-- core)                                                    -->

</list>

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

<p>The interpretation of the parameter entity declarations, and the
inclusion of the appropriate tag sets, are handled by a single
<soCalled>driver file</soCalled> for the main TEI DTD.  This file,
<ident type=file>tei2.dtd</ident>, is described in detail below in
section <ptr target=STov>.  The remainder of the present section
identifies the files in which each tag set is contained, and the
parameter entities associated with them.

<div3 id=STbaco><head>The Core Tag Sets</head>

<p>Two <soCalled>core</soCalled> 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:

<list type=gloss>

<label><ident type=pe>TEI.core.dtd</ident> <item>refers to the file
<ident type=file>teicore2.dtd</ident>, which declares the core tags
defined in chapter <ptr target=CO>

<label><ident type=pe>TEI.header.dtd</ident> <item>refers to the file
<ident type=file>teihdr2.dtd</ident>, which declares the tags of the TEI
header defined in chapter <ptr target=HD>

</list>

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.

<div3 id=STbaba><head>The Base Tag Sets</head>

<p>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.

<p>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 <term>mixed base</term> or the <term>general
base</term> may be used; see section <ptr target=STco>.

<!-- see chapter <ptr target=CB>.                            -->

These bases require the encoder to specify which of the other bases are
to be combined.

<p>The encoder selects a base tag set by declaring the appropriate SGML
parameter entity with the replacement text <code type=kw>INCLUDE</code>.
To invoke the base tag set for prose, for example, the encoder must
ensure that the DTD subset in the document contains the declaration:

<eg>
<![ CDATA [
 <!ENTITY % TEI.prose 'INCLUDE' >
]]>
</eg>

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

<list type=gloss>

<label><ident type=pe>TEI.prose</ident> <item>selects the base tag set
for prose, contained in <ident type=file>teipros2.dtd</ident>.

<!-- and < term >teipros2.ent< /term >                        -->

<label><ident type=pe>TEI.verse</ident> <item>selects the base tag set
for verse, contained in <ident type=file>teivers2.dtd</ident> and
<ident type=file>teivers2.ent</ident>.

<label><ident type=pe>TEI.drama</ident> <item>selects the base tag set
for drama, contained in <ident type=file>teidram2.dtd</ident> and <ident
type=file>teidram2.ent</ident>.

<label><ident type=pe>TEI.spoken</ident> <item>selects the base tag set
for transcriptions of spoken texts, contained in
<ident type=file>teispok2.dtd</ident> and
<ident type=file>teispok2.ent</ident>.

<!-- <label><ident type=pe>TEI.letters</ident> <item>selects  -->
<!-- the base tag set for letters and memos, contained in     -->
<!-- <ident type=file>teilett2.dtd</ident> and <ident         -->
<!-- type=file>teilett2.ent</ident>                           -->

<label><ident type=pe>TEI.dictionaries</ident> <item>selects the base
tag set for print dictionaries, contained in
<ident type=file>teidict2.dtd</ident> and
<ident type=file>teidict2.ent</ident>.

<label><ident type=pe>TEI.terminology</ident> <item>selects the base tag
set for terminological data files, contained in
<ident type=file>teiterm2.dtd</ident>,
<ident type=file>teiterm2.ent</ident>,
<ident type=file>teite2n.dtd</ident>, and
<ident type=file>teite2f.ent</ident>.

<label><ident type=pe>TEI.general</ident> <item>selects the generic
mixed-mode base base tag set, contained in
<ident type=file>teigen2.dtd</ident>.

<!-- and < term >teigen2.ent< /term >                         -->

<label><ident type=pe>TEI.mixed</ident> <item>selects the base tag set
for free mixed-mode texts, contained in
<ident type=file>teimix2.dtd</ident>.

<!-- and < term >teimix2.ent< /term >                         -->

</list>

<p>As shown in the list, each base tag set is normally contained in one
or two system files:  a required one (with the extension
<mentioned>dtd</mentioned>) defining the elements in the tag set and their
attributes, and an optional one (with the file extension
<mentioned>ent</mentioned>) 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 <mentioned>ent</mentioned> and <mentioned>dtd</mentioned>
respectively:  the prose base, for example, is enabled by declaring the
parameter entity <ident type=pe>TEI.prose</ident> as <code
type=kw>INCLUDE</code>; this in turn enables declarations of <ident
type=pe>TEI.prose.ent</ident> and <ident type=pe>TEI.prose.dtd</ident>
as the system files <ident type=file>teipros2.ent</ident> and
<ident type=file>teipros2.dtd</ident>.  For further details, see
section <ptr target=STov>.

<!-- cut, because too detailed for this overview (LB) -->

<!-- < p > The base tag set for terminology defines two       -->
<!-- styles of tagging for terminological data, the  <        -->
<!-- soCalled > flat < /soCalled >  and the < soCalled >      -->
<!-- nested < /soCalled > .  As described further in          -->
<!-- chapter  < xref target=TE > , the choice between these   -->
<!-- is indicated by the definition of the parameter entity   -->
<!-- < term > termtags < /term > :                            -->
<!--                                                          -->
<!--  < list type=gloss >                                     -->
<!--  < label >  < term > termtags < /term >   < item >       -->
<!-- selects either the nested form for terminological data   -->
<!-- files ( < term > teite2n.dtd < /term > ) or the flat     -->
<!-- form ( < term > teite2f.dtd < /term > )                  -->
<!--  < /list >                                               -->

<p>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:

<list type=gloss>

<label><ident type=pe>TEI.structure.dtd</ident> <item>refers to the file
<ident type=file>teistr2.dtd</ident>, with default definitions for
<gi>text</gi>, <gi>div</gi>, etc.

<label><ident type=pe>TEI.front.dtd</ident> <item>refers to the file
<ident type=file>teifron2.dtd</ident>, with tags for front matter

<label><ident type=pe>TEI.back.dtd</ident> <item>refers to the file
<ident type=file>teiback2.dtd</ident>, with tags for back matter

</list>

These default-structure tags are documented in chapter <ptr target=DS>.

<div3 id=STbaad><head>The Additional Tag Sets</head>

<p>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 <code type=kw>INCLUDE</code>; the
relevant parameter entities, and the files containing the additional tag
sets, are these:

<list type=gloss>

<label><ident type=pe>TEI.linking</ident> <item>embeds the files
<ident type=file>teilink2.dtd</ident> and
<ident type=file>teilink2.ent</ident>, with tags for linking,
segmentation, and alignment (chapter <ptr target=SA>)

<label><ident type=pe>TEI.analysis</ident> <item>embeds the files
<ident type=file>teiana2.dtd</ident> and
<ident type=file>teiana2.ent</ident>,
with tags for simple analytic mechanisms (chapter <ptr target=AI>)

<label><ident type=pe>TEI.fs</ident> <item>embeds the file
<ident type=file>teifs2.dtd</ident>,
with tags for feature structure analysis (chapter <ptr target=FS>)

<label><ident type=pe>TEI.certainty</ident> <item>embeds the file
<ident type=file>teicert2.dtd</ident>,
with tags for indicating uncertainty and
probability in the markup (chapter <ptr target=CE>)

<label><ident type=pe>TEI.transcr</ident> <item>embeds the files
<ident type=file>teitran2.dtd</ident> and
<ident type=file>teitran2.ent</ident>,
with tags for manuscripts, analytic bibliography, and transcription of
primary sources (chapter <ptr target=PH>)

<label><ident type=pe>TEI.textcrit</ident> <item>embeds the files
<ident type=file>teitc2.dtd</ident> and
<ident type=file>teitc2.ent</ident>,
with tags for critical editions (chapter <ptr target=TC>)

<label><ident type=pe>TEI.names.dates</ident> <item>embeds the files
<ident type=file>teind2.dtd</ident> and
<ident type=file>teind2.ent</ident>,
with specialized tags for names and dates (chapter <ptr target=ND>)

<label><ident type=pe>TEI.nets</ident> <item>embeds the file <ident
type=file>teinet2.dtd</ident>, with tags for graphs, digraphs, trees,
and other networks (chapter <ptr target=GD>) --- not to be confused
with the graphics markup of <ident type=pe>TEI.figures</ident>

<label><ident type=pe>TEI.figures</ident> <item>embeds the files
<ident type=file>teifig2.dtd</ident> and
<ident type=file>teifig2.ent</ident>,
with tags for graphics, figures,
illustrations, tables, and formulae (chapter <ptr target=FT>) --- not
to be confused with the graph-theoretic markup of <ident
type=pe>TEI.nets</ident>

<!-- <label><ident type=pe>TEI.formulas</ident> <item>embeds  -->
<!-- the file <ident type=file>teiform2.dtd</ident>, with     -->
<!-- tags for formul&aelig; and tables (chapter <ptr         -->
<!-- target=FT>)                                              -->

<label><ident type=pe>TEI.corpus</ident> <item>embeds the file <ident
type=file>teicorp2.dtd</ident>, with tags for additional tags for
language corpora (chapter <ptr target=CC>)

</list>

<p>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
<mentioned>dtd</mentioned>) defining the elements in the tag set and their
attributes, and an optional one (with the file extension
<mentioned>ent</mentioned>) 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 <mentioned>ent</mentioned> and <mentioned>dtd</mentioned>
respectively:  the additional tag set for linking, segmentation, and
alignment, for example, is enabled by declaring the parameter entity
<ident type=pe>TEI.linking</ident> as <code type=kw>INCLUDE</code>;
this in turn
enables declarations of <ident type=pe>TEI.linking.ent</ident> and
<ident type=pe>TEI.linking.dtd</ident> as the system files
<ident type=file>teilink2.ent</ident> and
<ident type=file>teilink2.dtd</ident>.

<div3 id=STbaus><head>User-Defined Tag Sets</head>

<p>As described in chapter <ptr target=MD>, 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:

<list type=gloss>
<label><ident type=pe>TEI.extensions.ent</ident>
<item>local modifications to parameter entities
<label><ident type=pe>TEI.extensions.dtd</ident>
<item>declarations of new elements and modified
declarations for existing elements
</list>

<p>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
<soCalled>entity files</soCalled> and <soCalled>DTD files</soCalled> 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 <ptr target=STovlo>.

<p>Further recommendations for the creation of user-defined extension or
modification are provided in chapters <ptr target=MD> and <ptr
target=CF>.

<!-- cut following scarey stuff -->

<!-- The notes which follow may be of interest to those       -->
<!-- undertaking this task, but do not constitute a guide     -->
<!-- to the process.  Other readers should ignore them.       -->
<!--                                                          -->
<!-- < p > If locally defined base or additional tag sets     -->
<!-- are to be used, local driver files must be constructed   -->
<!-- to define the necessary parameter entities and perform   -->
<!-- the selection of the local tag sets; they must be        -->
<!-- associated with the parameter entities  < term >         -->
<!-- TEI.extensions.ent < /term > and  < term >               -->
<!-- TEI.extensions.dtd < /term > , and should be modeled     -->
<!-- on the appropriate sections of the  < term > tei2.dtd    -->
<!-- < /term >  file described in section  < xref             -->
<!-- target=STov > .  Since the standard TEI extension        -->
<!-- mechanisms are thus in use, users of such a locally      -->
<!-- extended scheme will not be able to use them for         -->
<!-- extensions unique to a document.  It is a good idea to   -->
<!-- implement a  < soCalled > second-level < /soCalled >     -->
<!-- extension mechanism, to allow the extended local         -->
<!-- scheme to support further extensions; this               -->
<!-- second-level scheme may be modeled on the first-level    -->
<!-- scheme found in < term > tei2.dtd < /term > . < note     -->
<!-- place=foot > Local bases and additional tag sets may     -->
<!-- be more simply implemented by modifying the < term >     -->
<!-- tei2.dtd < /term >  file to refer to them.   < emph >    -->
<!-- Such modifications are not, however, TEI conformant. <   -->
<!-- /emph >  < /note >                                       -->
<!-- 2 Base Sets and Addtnls  -->
<!-- $Id: p2stin.odd,v 1.4 1998/02/01 17:38:08 tei Exp $ -->
<!--*
    * $Log: p2stin.odd,v $
    * Revision 1.4  1998/02/01 17:38:08  tei
    * fix Log keyword,
    * normalize SGML
    * replace system identifiers with public identifiers.
    *
    * Revision 1.3  94/04/08  01:36:34  msmcq
    * Last-round changes before publication of P3
    *  -->
<!-- P2.STin:  Invocation of the TEI DTD                      -->
<!-- Revisions:                                               -->
<!-- 94-04-07 : MSM : typo / wording changes from MSM         -->
<!-- 94-03-22 : MSM : typo / wording changes from JLav        -->
<!-- 94-03-22 : MSM : retag some TERMs, Qs, as CODE, IDENT    -->
<!-- 3 apr 93 : LB revise for publication                     -->
<!--       stylistic changes consequent on singularization    -->
<!-- 93-03-30 : MSM : cosmetic change only                    -->
<!-- 93-03-16 : MSM : move mixed bases to STco, add drama ex  -->
<!-- 93-03-06 : MSM : revise selection of mixed bases         -->
<!-- 17 May 92 : CMSMcQ : began draft                         -->

<div2 id="STin"><head>Invocation of the TEI DTD</head>

<p>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 <emph>must</emph> 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.</p>

<p>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 <ptr
target="STba">.  For example, a document using the base tag set for prose
will begin with a document type declaration something like this:

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

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

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

<p>If one or more of the <term>additional tag sets</term> 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:

<eg>
<![ CDATA [
 <!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' >
 ]>
]]>
</eg></p>

<p>If local modifications are used, they may be stored in separate
files and pointed to using the parameter entities <ident
type="pe">TEI.extensions.ent</ident> and <ident
type="pe">TEI.extensions.dtd</ident>.  If such local modifications are
added to the example just given, this is the result:

<eg>
<![ CDATA [
 <!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' >
 ]>
]]>
</eg>

<!-- changed following para to reflect fact that mixed base needed when -->
<!-- different bases are mixed, not just when prose and verse are needed -->

<!-- <p>If the document has a mixture of different text types (e.g. prose and -->
<!-- verse) or embeds smaller texts of different text types, one of the -->
<!-- mixed-type bases must be used.  Their proper invocation is described -->
<!-- below in section <ptr target=STco>. --></p>

<p>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 <ptr
target="STco">.
</p></div2>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-default-dtd-file:"~/lib/psgml/p2odd.ced"
sgml-parent-document:(quote ("/home/tei/P3/Master/Odds/p2.odd" "tei.1" "text" "body" "div1" "div2"))
sgml-omittag:t
sgml-shorttag:t
End:
-->
<!-- 3 Invocation of TEI DTDs -->
<!-- $Id: p2stco.odd,v 1.6 1998/02/01 17:38:08 tei Exp $ -->
<!--*
    * $Log: p2stco.odd,v $
    * Revision 1.6  1998/02/01 17:38:08  tei
    * fix Log keyword,
    * normalize SGML
    * replace system identifiers with public identifiers.
    *
    * Revision 1.5  94/04/08  01:36:34  msmcq
    * Last-round changes before publication of P3
    *
    * Revision 1.4  1994/04/01  16:36:47  msmcq
    * changes / fixes during validation of DTD
    *
    * Revision 1.3  1994/03/24  22:20:40  msmcq
    * typos found by David Barnard et al. corrected
    * -->
<!-- P2.136 :  Combining TEI DTD fragments                    -->
<!-- Revisions:                                               -->
<!-- 94-04-07 : MSM : minor changes                           -->
<!-- 94-03-31 : MSM : define files teimix2, teigen2           -->
<!-- 94-03-22 : MSM : typos and wording changes from JLav     -->
<!-- 94-03-22 : MSM : retag some TERMs, Qs, as CODE, IDENT    -->
<!-- 94-03-21 : MSM : typos, suppress xref to CB              -->
<!-- 93-09-14 : MSM : dictionar-ies not dictionar-y           -->
<!-- 93-04-06 : MSM : one minor fix for clarity               -->
<!-- 3 apr 93 : LB revise for publication                     -->
<!--       changed title                                     -->
<!--      stylistic changes consequent on singularization    -->
<!--      simplified discussion/examples at end               -->
<!-- 93-03-30 : MSM : minor cosmetic changes for LB           -->
<!-- 93-03-06 : MSM : light revision, notes for more revision -->
<!-- 17 May 92 : CMSMcQ : began draft                         -->

<div2 id="STco"><head>Combining TEI Base Tag Sets</head>

<p>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.</p>

<p>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:

<list type="bullets">
<item>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</item>
<item>when the text contains other smaller, embedded texts:  e.g. a poem
or song included in a prose narrative</item>
<item>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</item>
<item>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</item>
</list></p>

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

<list type="bullets">
<item>a definition of a corpus or collection as a series of
<gi>tei.2</gi>
documents, sharing a common TEI header (see chapter <ptr target="CC">)</item>
<item>a definition of composite texts which comprise front matter, a
group or several possibly nested groups of collected texts,
themselves possibly composite (see section <ptr target="DSgrp">)</item>
<item>a notion of <term>embedded text</term>
which allows one text to be embedded within another (that is,
<gi>text</gi> is defined as a component-level element, as described
briefly at the conclusion of section <ptr target="DSgrp">)</item>

</list></p>

<p>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:

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

<p>When either of these <socalled>combined</socalled> 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.

<!-- it's an error to specify both mixed and general, tho we can't -->
<!-- stop you -->

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:

<eg>
<![ CDATA [
 <!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 ... -->
 ]>
]]>
</eg>

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 <ident type="class">divn</ident>) must be homogenous with
respect to the mixture of available bases.  Because in a
<socalled>general</socalled> base, each <gi>div</gi> 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:

<eg>
<![ CDATA [
 <!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' >
 ]>
]]>
</eg>

<!-- <p>For further discussion of mixing TEI bases, see       -->
<!-- chapter <ptr target=CB>.                                --></p>

<p>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 <ident type="file">teimix2.dtd</ident>:

<eg id=dstcbmx>
<![ CDATA [
<!-- 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;
]]>
</eg>


The general-base tag set is in file
<ident type="file">teigen2.dtd</ident>:
<eg id=dstcbgn>
<![ CDATA [
<!-- 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;
]]>
</eg>

</p></div2>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-default-dtd-file:"~/lib/psgml/p2odd.ced"
sgml-parent-document:(quote ("/home/tei/P3/Master/Odds/p2.odd" "tei.1" "text" "body" "div1" "div2"))
sgml-omittag:t
sgml-shorttag:t
End:
-->
<!-- 4 Combining TEI DTDfrags -->
<!-- $Id: p2stga.odd,v 1.9 1998/02/05 17:14:35 tei Exp $ -->
<!--*
    * $Log: p2stga.odd,v $
    * Revision 1.9  1998/02/05 17:14:35  tei
    * make examples parse
    *
    * Revision 1.8  94/04/08  01:36:34  msmcq
    * Last-round changes before publication of P3
    *
    * Revision 1.7  1994/03/28  16:34:42  msmcq
    * back out version 1.6, which once more overwrites msm changes in error
    *
    * Revision 1.5  1994/03/27  23:03:43  msmcq
    * restore changes made in version 1.3, overwritten by 1.4 in error.
    *
    * Revision 1.3  1994/03/24  22:20:40  msmcq
    * typos found by David Barnard et al. corrected
    * -->
<!-- P2.133 :  Global Attributes                              -->
<!-- Revisions:                                               -->
<!-- 94-04-07 : MSM : typos, minor fixes from MSM             -->
<!-- 94-03-22 : MSM : typos from DB, EBr, JLav                -->
<!-- 94-03-22 : MSM : retag some TERMs, Qs, as CODE, IDENT    -->
<!-- 94-03-21 : MSM : typos, corrections, stylistic changes   -->
<!--                  as suggested by WWP proofreading team   -->
<!--                  Including new paras on TEIform att      -->
<!-- 93-09-13 : MSM : add default declarations of inherited global atts -->
<!-- 93-04-06 : MSM : mostly cosmetic changes                 -->
<!-- 3 apr 93 : LB revise for publication                     -->
<!--     cut some kindergarten stuff; tried to obscure probs  -->
<!--   w. rendition and teiform; plus minor changes in wording -->
<!-- 93-03-30 : MSM : minor changes for LB                    -->
<!-- 93-03-16 : MSM : minor fixes for clarity, from J.Lav.    -->
<!-- 93-03-06 : MSM : fix xrefs to CO, HD                     -->
<!-- 93-03-06 : MSM : minor fixes for clarity                 -->
<!-- 93-03-06 : MSM : minor changes for pedantry              -->
<!-- 93-03-04 : MSM : trivial sgml fix                        -->
<!-- 93-01-27 : MSM : correct ref to ccedil                   -->
<!-- 21 Oct 92 : CMSMcQ : new name new id some text.          -->
<!-- 17 May 92 : CMSMcQ : began draft                         -->

<div2 id=STga><head>Global Attributes</head>

<p>The following attributes are defined for every TEI element.<note>More
exactly, these are the attributes of the element class
<ident type=class>global</ident>, to which all elements belong; for
further discussion of attribute classes and ways in which attributes
may be inherited and over-ridden, see section <ptr target=STecat>.
</note>

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

<p>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 <ptr
target=STecat>.

<p>An additional attribute, <att>TEIform</att>, is also defined
for every TEI element.  Unlike the other attributes defined for every
element, <att>TEIform</att> is not defined by class <ident
type=class>global</ident> because its default value is different in
every case and must be defined individually for each element.<note
place=foot>A dummy element class <ident type=class>TEIform</ident> is
defined in the reference section, solely for documentary purposes.
</note>

<list type=gloss>
<label><att>TEIform</att></label>
<item>indicates the standard TEI name (generic identifier) for a 
given element.</item>
</list>

<p>Any TEI element may be given values for <att>id</att>, <att>n</att>,
<att>lang</att>, <att>rend</att>, or <att>TEIform</att>, simply by
specifying values for these attributes.

<!-- not sure if this is not too obvious here, but left it in for now -->

The following two examples convey the same information about the text:
that the material transcribed occurs within a <gi>p</gi> 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.

<eg>
<![ CDATA [
<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>
]]>
</eg>

<eg>
<![ CDATA [
<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>
]]>
</eg>
<!-- Merchant of Venice, I.ii, speech 5 (Portia)              -->

<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 <mentioned>a23</mentioned> and
<mentioned>A23</mentioned> are identical, and may not be used to identify two
distinct elements.

<!-- delete from here .... -->

<!--                                                          -->
<!-- Under the reference concrete syntax of SGML, ID values   -->
<!-- do not distinguish between upper and lower case.  The    -->
<!-- following are thus legal names and thus legal values     -->
<!-- for  < att > id < /att > , of which the first two pairs are -->
<!-- synonyms:                                                -->
<!--                                                          -->
<!--  < list type=simple >                                    -->
<!--  < item > A                                              -->
<!--  < item > a                                              -->
<!--  < item > e23                                            -->
<!--  < item > E23                                            -->
<!--  < item > init.                                          -->
<!--  < item > Chapter.1                                      -->
<!--  < item > Ovid.Met.9.10-11                               -->
<!--  < item > x78y                                           -->
<!--  < /list >                                               -->
<!--                                                          -->
<!-- while the following are  < emph > not < /emph >  legal   -->
<!-- names in the default SGML syntax (though the SGML        -->
<!-- declaration might be modified to make some of them       -->
<!-- legal): < note place=foot > The first three are          -->
<!-- illegal because they do not begin with a letter; the     -->
<!-- last four because they contain non-name characters. <    -->
<!-- /note >                                                  -->
<!--                                                          -->
<!--  < list type=simple >                                    -->
<!--  < item > 23                                             -->
<!--  < item > 35mm                                           -->
<!--  < item > .init                                          -->
<!--  < item > a_name_with_underscores                        -->
<!--  < item > a name with spaces                             -->
<!--  < item > fran&ccedil;ais                                -->
<!--  < item > x*#$@!                                         -->
<!--  < /list >                                               -->
<!--                                                          -->
<!--  < p > ID values must be unique within the SGML          -->
<!-- document; if two elements                                -->
<!-- to here -->

If two elements are given the same identifier, the SGML parser will
signal a syntax error.  The following example, therefore, is
<emph>not</emph> valid:

<eg>
<![ CDATA [
<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>
]]>
</eg>
<!-- Clockwork Orange, opening -->

<p>For a discussion of methods of providing unique identifiers for
elements, see section <ptr target=COrs2>.

<p>The <att>n</att> attribute allows identifying information (e.g.
chapter numbers, etc.) to be encoded even if it would not be a legal
<att>id</att> 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 <att>n</att> 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:

<eg>
<![ CDATA [
<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>
]]>
</eg>

The <att>n</att> 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:

<eg>
<![ CDATA [
  <div type=chap n='One' id='TXT0101'>
]]>
</eg>

<eg>
<![ CDATA [
  <div type=stanza n='xlii'>
]]>
</eg>

<p>The <att>lang</att> 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 <gi>tei.2</gi> element, and
allow most elements to take the default value for <att>lang</att>; the
language of an element then need be explicitly specified only for
elements in languages other than the base language.

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

<eg>
<![ CDATA [
 <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>
]]>
</eg>

<eg>
<![ CDATA [
 <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>
]]>
</eg>

<!-- Lincoln's Second Inaugural Address, 4 March 1865, rpt.   -->
<!-- (from Richardson, ed., Messages and Papers, 6:276ff) in  -->
<!-- H. S. Commager, ed., Documents of American History, 5th  -->
<!-- ed.  (New York:  Appleton-Century-Crofts, 1949), p.      -->
<!-- 442.                                                     -->

<p>In the following example, by contrast, the <att>lang</att> attribute
on the <gi>term</gi> element must be given if we wish to record the fact
that the technical terms used are Latin rather than English; no
<att>lang</att> attribute is needed on the <gi>q</gi> 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 <att>lang</att> attribute, as
described in chapter <ptr target=CH>.

<!-- Choose one?  i vote to keep both. -MSM -->
<!-- I chose one. -->
<!-- < eg > -->
<!-- < ! [ CDATA [ -->
<!--  < p lang=en > ... If they do afford him a remedy, is it -->
<!--  a < term lang=la >mandamus< /term> issuing from this court? ... -->
<!--  < / p > -->
<!-- ] ]> -->
<!-- < / eg > -->
<!-- Marbury v. Madison, 1 Cranch, 137 (1803), rpt. in H. S.  -->
<!-- Commager, ed., Documents of American History, 5th ed.    -->
<!-- (New York:  Appleton-Century-Crofts, 1949), p. 191.      -->

<eg>
<![ CDATA [
 <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>
]]>
</eg>

<!-- Marbury v. Madison, 1 Cranch, 137 (1803), rpt. in H. S.  -->
<!-- Commager, ed., Documents of American History, 5th ed.    -->
<!-- (New York:  Appleton-Century-Crofts, 1949), p. 192.      -->

<p>Formally, the <att>lang</att> attribute is an
<code type=kw>IDREF</code>; a reference
to the <att>id</att> value of a <gi>language</gi> element in the TEI
header.<note place=foot>SGML validation checks that all
<code type=kw>IDREF</code> values
exist as <att>id</att> values on elements somewhere in the current SGML
document.  It is a requirement of the TEI scheme, not of SGML, that the
<att>lang</att> attribute point to a <gi>language</gi> element.</note>
This means that each language used in the document should be declared in
the TEI header using the <gi>language</gi> element defined in section
<ptr target=HD41>.

<p>The <att>rend</att> 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:

<eg>
<![ CDATA [
 <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>
]]>
</eg>

<!-- Gibbon, Decline and Fall, chapter 58, para beginning     -->
<!-- 'In some Oriental tale I have read ...', p. 391 of       -->
<!-- Britannica edition.                                      -->
<!--  ... played fast and loose with by LB for pedagogic purposes -->
<!-- Shame, shame.                                            -->

If all or most <gi>emph</gi> and <gi>name</gi> 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 <att>rend</att> value
only for any elements which deviate from the usual rendition.

<p>The contents of the <att>rend</att> 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 <gi>rendition</gi>
element of the TEI header.

<!-- Although no consensus exists in practice, however, to    -->
<!-- allow for standardization of such vocabularies for all   -->
<!-- projects. The standard vo                                -->
<!--                                                          -->
<!-- < note place=foot >  [However, the < gi >                -->
<!-- encodingDesc < /gi >  or the  < gi > profileDesc < /gi   -->
<!-- >  does need to be able to document the language used,   -->
<!-- somehow.  Formal facilities for language definition      -->
<!-- would be useful but are out of the question:  no one     -->
<!-- knows how best to construct a rendition language.  It    -->
<!-- would be nice to be able at least to include prose or    -->
<!-- a bibliographic reference, though.  -MSM]  <  /note  >   -->

<p>The <att>TEIform</att> 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.  <note
place=foot>The <att>TEIform</att> attribute is based on the notion of
<term>architectural forms</term> developed for HyTime (ISO 10744).
<!-- The details, however, vary. -->
</note>

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

<p>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 <att>TEIform</att>
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 <gi>div1</gi> element as <gi
tei=no>chapter</gi> and also modified its formal declarations (e.g. to
change its content model), then the <att>TEIform</att> attribute on the
modified element should be given the default value <code
type=val>div1</code>, in order to indicate that the local <gi
tei=no>chapter</gi> element is a modification of the standard TEI
<gi>div1</gi>.

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

<eg>
<![ CDATA [
 <!ELEMENT quatrain - O (l, l, l, l)            >
 <!ATTLIST quatrain     %a.global
           TEIform      (lg)            'lg'    >
]]>
</eg>


<!-- Following paragraph deleted as being, alas, not true.    -->
<!-- It should be made true for P4.  (msm)                    -->

<!-- <p>Constraints on the use of <att>TEIform</att> (rules   -->
<!-- determining when it is legitimate, and when not, to      -->
<!-- identify a new element as corresponding to a given TEI   -->
<!-- element) are given in chapter <ptr target=MD>.          -->
<!-- Further discussion of the relationship between the TEI   -->
<!-- DTD and other standard DTDs is given in chapter <ptr    -->
<!-- target=OS>.                                              -->


<!-- < p >N.B. Future versions of the TEI encoding scheme     -->
<!-- may add new global attributes to relate TEI elements     -->
<!-- to the architectural forms of HyTime and the DTD being   -->
<!-- prepared by ICADD (International Committee on            -->
<!-- Accessible Document Design) to aid in the automatic      -->
<!-- conversion of electronic text to level-2 Braille.        -->
<!-- Would have been this version if their draft had been ready. -->

<p>The formal definition of the global attributes is as follows:

<eg id=dstga>
<![ CDATA [
<!-- 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                      -->
]]>
</eg>

<!-- <claDecl type=atts classDoc=dftspok>                     -->
<!-- <claDecl type=atts classDoc=dftcert>                     -->
<!-- <claDecl type=atts classDoc=dftfs>                       -->
<!-- 5 Global Attributes      -->
<!-- $Id: p2stov.odd,v 1.8 1998/02/01 17:38:08 tei Exp $ -->
<!--*
    * $Log: p2stov.odd,v $
    * Revision 1.8  1998/02/01 17:38:08  tei
    * fix Log keyword,
    * normalize SGML
    * replace system identifiers with public identifiers.
    *
    * Revision 1.7  94/04/08  18:54:36  msmcq
    * Last-second fixes for P3
    *
    * Revision 1.6  1994/04/08  01:36:34  msmcq
    * Last-round changes before publication of P3
    *
    * Revision 1.5  1994/04/01  16:36:47  msmcq
    * changes / fixes during validation of DTD
    *
    * Revision 1.4  1994/03/24  22:20:40  msmcq
    * typos found by David Barnard et al. corrected
    *
    * Revision 1.3  1994/03/16  03:28:24  msmcq
    * changes a propos of PH
    * -->
<!-- Revisions:                                               -->
<!-- 94-04-08 : MSM : use ftdtd, not gfdtd ent                -->
<!-- 94-04-07 : MSM : confuse discussion of conformance       -->
<!-- 94-03-30 : MSM : suppress ref to lmdtd                   -->
<!-- 94-03-22 : MSM : retag some TERMs, Qs, as CODE, IDENT    -->
<!-- 94-03-22 : MSM : typos from WWP team, EBr, JLav          -->
<!-- 94-03-07 : MSM : rename physical as transcr              -->
<!-- 93-09-14 : MSM : move IGNORE keywords to dSTpekw         -->
<!-- 93-09-14 : MSM : dictionar-ies not -y                    -->
<!-- 93-04-06 : MSM : minor changes:  style, typos, slips     -->
<!-- 3 apr 93 : LB revise for publication                     -->
<!--       stylistic changes consequent on singularization    -->
<!--       extended discussion of example a bit (and fixed typo) -->
<!-- 93-03-30 : MSM : changes, cleanup for LB                 -->
<!-- 93-03-24 : MSM : remove dup decls for XXtop entities     -->
<!-- 93-03-23 : MSM : fill out dtd frags, misc rev            -->
<!-- 93-03-16 : MSM : add health warning at beginning, add    -->
<!--                  discussion of user tag sets             -->
<!-- 93-03-06 : MSM : add initial overview                    -->
<!-- 93-03-06 : MSM : break out local mods into separate section -->
<!-- 93-03-04 : MSM : change p2st- ids to ST                  -->
<!-- 93-03-04 : MSM : trivial sgml fix                        -->
<!-- 93-03-04 : MSM : remove TERM gi from inside commdecl     -->

<div2 id="STov"><head>The TEI2.DTD File</head>

<p>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.

<!--                                                          -->
<!-- Most readers can skip or skim these sections:  they      -->
<!-- document the precise usage of SGML marked sections and   -->
<!-- parameter entities to perform various operations         -->
<!-- behind the scenes with which most users need not         -->
<!-- concern themselves.  Those who do need to know exactly   -->
<!-- what is happening at a detailed level should study the   -->
<!-- following description carefully.                         -->
<!--                                                          -->
<!--                                                          -->
<!-- < p > In addition to the files for core, base, and       -->
<!-- additional tag sets described in section  < xref         -->
<!-- target=STba > , the TEI DTD uses the following files:    -->
<!--                                                          -->
<!--   < list type=gloss >                                    -->
<!--   < label >  < term > tei2.dtd < /term >   < item >      -->
<!-- main, top-level DTD driver file                          -->
<!--   < label >  < term > teigis2.ent < /term >   < item >   -->
<!-- declares parameter entities for                          -->
<!--  TEI generic identifiers; see section  < xref            -->
<!-- target=STpegi >                                          -->
<!--   < label >  < term > teiclas2.ent < /term >   < item    -->
<!-- > declares parameter entities for                        -->
<!--  TEI element classes; see section  < xref                -->
<!-- target=STecov >                                          -->
<!--   < /list >                                              -->
<!--                                                          -->
<!--  Fragments of these files are included in other          -->
<!-- sections of this chapter;                                -->
<!--  this section provides the top-level overview of the     --></p>

<p>The main TEI DTD is always invoked by specifying the file
<ident type="file">tei2.dtd</ident>.  This file:

<list type="ordered">

<item>takes care of certain necessary preliminaries:

<list type="ordered">

<item>embeds any locally defined changes to the standard TEI
parameter entities, so that local modifications can take precedence
over default declarations;</item>

<item>declares TEI-specific keywords used in other declarations and
declares default values of <code type="kw">IGNORE</code> for all the
parameter entities used to select base and additional tag sets (see
section <ptr target="STpekw">);</item>

<item>declares parameter entities for TEI generic identifiers (by
embedding the file <ident type="file">teigis2.ent</ident>; see section
<ptr target="STpegi">);</item>

</list></item>

<item>declares parameter entities for element classes, content models,
and global attributes (by embedding <ident type="file">teiclas2.ent</ident>; see section <ptr target="STecov">);</item>

<item>declares the top-level elements <gi>TEI.2</gi> and
<gi>teiCorpus.2</gi>;</item>

<item>embeds DTD files containing local modifications (if any),
the core tag sets, the base tag set, and the additional tag sets.</item>

</list></p>

<div3 id="STovov"><head>Structure of the TEI2.DTD File</head>

<p>Each parameter entity associated with a tag set controls several
marked sections in the main DTD file <ident type="file">tei2.dtd</ident>.
If the entity has been declared in the DTD subset with the text <code
type="kw">INCLUDE</code>, then the marked sections it controls will be
parsed; otherwise, they will be ignored.  The marked sections controlled
by each entity:

<list type="ordered">
<item>declare and refer to the entity file for the tag set,
which defines its global attributes and element classes</item>
<item>declare and refer to the DTD file for the tag set,
which defines its elements and their attributes</item>
<item>declare the parameter entity <ident type="pe">component</ident>) in
a form suitable for texts using that base</item>
</list></p>

<p>The <ident type="file">tei2.dtd</ident> file has the following
structure:

<eg id=dsttei2>
<![ CDATA [
<!-- 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 ...                                          -->
]]>
</eg>
</p>

<p>A TEI-conformant document <emph>must</emph> use the <ident
type="file">tei2.dtd</ident> file, or one derived from it in the manner
described in chapter <ptr target="MD">.
It must also specify which base and
which additional tag sets are to be invoked, using the mechanisms
described in section <ptr target="STin">.</p></div3>

<div3 id="STovlo"><head>Embedding Local Modifications</head>

<p>As noted above in section <ptr target="STbaus">, 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
<ident type="pe">TEI.extensions.ent</ident> and
<ident type="pe">TEI.extensions.dtd</ident> by declarations included in
the document's DTD subset.</p>

<p>For example, if the relevant files are called <ident rend="noindex"
type="file">project.ent</ident> and <ident rend="noindex" type="file">project.dtd</ident>, then declarations like the following
would be appropriate:

<eg>
<![ CDATA [
 <!ENTITY % TEI.extensions.ent SYSTEM 'project.ent' >
 <!ENTITY % TEI.extensions.dtd SYSTEM 'project.dtd' >
]]>
</eg></p>

<p>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 <ident type="file">tei2.dtd</ident>.  The entity <ident type="pe">TEI.extensions.ent</ident> 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 <ident type="pe">TEI.extensions.ent</ident> entity, the entity will be expanded
to the empty string.</p>

<p>For example the encoder might wish to add two phrase-level elements
<gi tei="no">it</gi> and <gi tei="no">bd</gi>, perhaps as synonyms for
<tag>hi rend='italics'</tag> and <tag>hi rend='bold'</tag>.  As
described in chapter <ptr target="MD">, 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
<ident type="pe">x.phrase</ident> 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:

<eg>
<![ CDATA [
 <!ENTITY % x.phrase 'it | bd |' >
]]>
</eg></p>

<p>The relevant fragment of the DTD is this:

<eg id=dstovle>
<![ CDATA [
<!-- 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                      -->
]]>
</eg>
</p>

<p>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
<ident type="pe">TEI.extensions.dtd</ident> is used to embed local element
declarations <emph>before</emph> any of the TEI tag sets are embedded by
the file <ident type="file">tei2.dtd</ident>, but <emph>after</emph> all
the TEI element classes and other parameter entities have been declared.</p>

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

<eg>
<![ CDATA [
 <!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'   >
]]>
</eg></p>

<p>For further examples of local modifications to both parameter
entities and element declarations, see chapter <ptr target="MD">.</p>

<p>The relevant fragment of the DTD is this:
<eg id=dstovlo>
<![ CDATA [
<!-- 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                      -->
]]>
</eg>
</p></div3>

<div3 id="STovco"><head>Embedding the Core Tag Sets</head>

<p>The core tag sets are embedded by the file <ident type="file">tei2.dtd</ident> using the parameter entities <ident
type="pe">TEI.header</ident> and <ident type="pe">TEI.core</ident>.  The
relevant fragment of the DTD is this:

<eg id=dstovco>
<![ CDATA [
<!-- 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                      -->
]]>
</eg>
</p>

<p>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.</p></div3>

<div3 id="STovba"><head>Embedding the Base Tag Set</head>

<p>The <ident type="file">tei2.dtd</ident> file embeds the appropriate
files for the base tag set previously selected by means of the parameter
entities described in section <ptr target="STba">.  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 <ident
type="file">tei2.dtd</ident> is this:

<eg id=dstovba>
<![ CDATA [
<!-- 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                      -->
]]>
</eg>

<!-- <msection keywords='%TEI.letters'>                       -->
<!-- <entDecl entDoc=lmdtd>                                   -->
<!-- <peRef n='TEI.letters.dtd'>                              -->
<!-- </msection>                                              --></p></div3>


<div3 id="STovad"><head>Embedding the Additional Tag Sets</head>

<p>The <ident type="file">tei2.dtd</ident> file embeds the appropriate
files for any additional base tag set previously enabled by means of the
parameter entities described in section <ptr target="STba">.  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 <ident
type="file">tei2.dtd</ident> is this:


<eg id=dstovad>
<![ CDATA [
<!-- 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                      -->
]]>
</eg>

 <!-- <msection keywords='%TEI.formulas'>                      -->
<!-- <entDecl entDoc=ftdtd>                                   -->
<!-- <peRef n='TEI.formulas.dtd'>                             -->
<!-- </msection>                                              -->
</p>
</div3></div2>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-default-dtd-file:"~/lib/psgml/p2odd.ced"
sgml-parent-document:(quote ("/home/tei/P3/Master/Odds/p2.odd" "tei.1" "text" "body" "div1" "div2"))
sgml-omittag:t
sgml-shorttag:t
End:
-->
<!-- 6 The TEI2.DTD File      -->
<!-- $Id: p2stec.odd,v 1.14 1998/01/31 18:32:23 tei Exp $ -->
<!--*
    * $Log: p2stec.odd,v $
    * Revision 1.14  1998/01/31 18:32:23  tei
    * add fmchunk
    *
    * Revision 1.13  98/01/28  11:05:29  cmsmcq
    * LB's changes of January 1998
    *
    * Revision 1.12  1994/08/29  15:43:52  cmsmcq
    * Fixes for unreachability problems
    *
    * Revision 1.11  1994/04/08  01:36:34  msmcq
    * Last-round changes before publication of P3
    *
    * Revision 1.10  1994/04/01  16:36:47  msmcq
    * changes / fixes during validation of DTD
    *
    * Revision 1.9  1994/03/28  15:23:18  lou
    * fix duff xrefs
    *
    * Revision 1.8  1994/03/24  22:20:40  msmcq
    * typos found by David Barnard et al. corrected
    *
    * Revision 1.7  1994/03/16  03:27:47  msmcq
    * minor interim changes (PH, typo)
    *
    * Revision 1.6  1994/03/01  03:49:01  msmcq
    * first cut at restoring consistency, while checking FT
    *
    * Revision 1.5  1994/01/04  13:02:04  lou
    * add verse attrib classes etc; reorder cladecls
    *
    * Revision 1.3  1993/09/15  22:51:45  msmcq
    * Changes for publication of TD
    *
    * Revision 1.2  1993/06/22  14:29:49  msmcq
    * Changes a propos of DTD generation
    * -->
<!-- P2STec :  Element Classes                                -->
<!-- Revisions:                                               -->
<!-- 31 Jan 98: LB : add fmchunk class -->
<!-- 8 Jan 98: LB : add typed class; revise clseg accordingly -->
<!-- 4 Jan 98 : LB  : add editincl as further child of globincl -->
<!-- 94-08-04 : MSM : make refsys a child of globincl         -->
<!-- 94-03-31 : MSM : declare default mix-dot entities here   -->
<!-- 94-03-31 : MSM : add ref to names.dates.ent              -->
<!-- 94-03-30 : MSM : suppress readings again (in TC)         -->
<!-- 94-03-30 : MSM : add ref to TEI.textcrit.ent             -->
<!-- 94-03-30 : MSM : add clseg to atts classes               -->
<!-- 94-03-30 : MSM : suppress ref to lmgenxx                 -->
<!-- 94-03-29 : MSM : add readings                            -->
<!-- 94-03-29 : MSM : work toward sorting out class problems  -->
<!-- 94-03-22 : MSM : typos, etc. from DB, JLav               -->
<!-- 94-03-22 : MSM : retag some TERMs, Qs, as CODE, IDENT    -->
<!-- 94-03-22 : MSM : typos, stylistic changes from Team WWP  -->
<!-- 94-03-14 : MSM : add clinterp                            -->
<!-- 94-03-07 : MSM : add tei.transcr.ent                     -->
<!-- 94-02-28 : MSM : add clloc model class                   -->
<!-- 94-02-28 : MSM : suppress pointer, xpointer, ptrgrp      -->
<!-- 94-02-28 : MSM : (which are no longer model classes)     -->
<!-- 94-02-25 : MSM : suppress pname, plname classes          -->
<!-- 94-02-25 : MSM : suppress CE ent, add FT ent             -->
<!-- 29 dec LB: add cladecls for vephr.cla et al              -->
<!-- 20 dec 93 : LB : change name of seg class to avoid nameclash -->
<!-- 93-09-14 : MSM : dictionar-ies not -y                    -->
<!-- 93-09-13 : MSM : add agent class                         -->
<!-- 93-09-13 : MSM : add stagedir, sgmlkw, drfront, clfront  -->
<!-- 93-09-13 : MSM : add default component decl              -->
<!-- 93-09-13 : MSM : change ref to conana to conars          -->
<!-- 93-06-21 : MSM : suppress reference to flatterm          -->
<!-- 93-06-21 : MSM : add plname, pname, tempexp              -->
<!-- 93-06-21 : MSM : (di and tc classes *not* added yet)     -->
<!-- 93-06-21 : MSM : add cladecls for a-classes              -->
<!-- 93-06-21 : MSM : correct typo in termologg.ent           -->
<!-- 93-06-21 : MSM : clean up dtdfrag refs                   -->
<!-- 93-04-07 : MSM : some changes for clarity, consistency   -->
<!--                  cosmetic changes                        -->
<!-- 93-04-06 : MSM : distinguish phrase (cla), pephrase (pe) -->
<!-- 3 apr 93 : LB revise for publication                     -->
<!--    added ref to divn class; various changes of wording   -->
<!-- 93-03-30 : MSM : cleanup for LB                          -->
<!-- 93-03-29 : MSM : correct ref to TSbati                   -->
<!-- 93-03-29 : MSM : change id to teflne was teflattm        -->
<!-- 93-03-27 : MSM : ids on dummy dtdfrags                   -->
<!-- 93-03-23f : MSM : revise for clarity, correctness        -->
<!-- 93-03-06 : MSM : correct duplicat id                     -->
<!-- 93-03-06 : MSM : correct ref:  for copb read cors        -->
<!-- 93-03-06 : MSM : finish work-through                     -->
<!-- 93-03-06 : MSM : fill in dtd fragments (all but misc)    -->
<!-- 93-03-06 : MSM : add general section on m. and x. ents   -->
<!-- 93-03-06 : MSM : add section on inheritance              -->
<!-- 93-03-05 : MSM : rev toward pub                          -->
<!-- 93-03-05 : MSM : revise dtdfrags                         -->
<!-- 93-03-01 : MSM : remove other parameter entities         -->
<!-- 93-02-02 : MSM : add dtd fragments                       -->
<!-- 93-02-02 : MSM : merge VM and PC changes                 -->
<!-- 25 Jan 93 : CMSMcQ : first revision for publication      -->
<!-- 21 Oct 92 : CMSMcQ : new id new name quick full draft    -->
<!-- 17 May 92 : CMSMcQ : began draft                         -->

<div2 id=STec><head>Element Classes</head>

<p>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 <term>element classes</term> 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
<term>a-class</term> if its members share attributes, and as an
<term>m-class</term> if its members appear at the same locations in the
content models of other TEI elements.  An element is said to
<term>inherit</term> 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.

<p>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 <ptr target=STpe>.

<p>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 <ident type=file>teiclas2.ent</ident>.
All element classes are documented in the alphabetical reference section
in Part VII.

<div3 id=STecat><head>Classes Which Share Attributes</head>

<p>An attribute class (a-class) groups together elements which share
some set of common attributes.  For example, the members of the class
<ident type=class>names</ident> are all elements which contain proper
nouns: e.g.  <gi>name</gi>, <gi>placeName</gi>, or <gi>persName</gi>.
All of these elements use the same attributes (<att>key</att> and
<att>reg</att>) to record information about the referent or the
regularized form of the proper nouns.  Similarly, the members of the
<ident type=class>pointer</ident> class share a set of attributes
useful for managing cross-reference links and other pointers.<note
place=foot>Because the details of their pointing mechanism differ, the
members of the <ident type=class>pointer</ident> class do not,
however, share their pointing attributes.</note>

<p>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 <mentioned>a.</mentioned>; we refer to these entities as
<term>a-dot entities.</term>

<p>For example, the declaration for the <ident type=class>names</ident>
class includes attribute definitions for its two attributes
<att>reg</att> and <att>key</att>:

<eg id=dstecx1>
<![ CDATA [
<!-- 3.7.1:  Sample class declaration                         -->
<!ENTITY % a.names '
          reg                CDATA               #IMPLIED
          key                CDATA               #IMPLIED'      >
]]>
</eg>


Members of the class typically inherit these definitions by referring to
<ident type=class>a.names</ident>:

<eg id=dstecx2>
<![ CDATA [
<!-- 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       >
]]>
</eg>


<p>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 <ident
type=class>xPointer</ident> is a subclass of the class <ident
type=class>pointer</ident>, as shown implicitly by the declaration of
its a-dot entity:

<eg id=dstecx3>
<![ CDATA [
<!-- 3.7.1: Sample subclass declaration, with inheritance     -->
<!-- from superclass                                          -->
<!ENTITY % a.xPointer '      %a.pointer;
          to                 %extPtr;            "DITTO"
          doc                ENTITY              #IMPLIED
          from               %extPtr;            "ROOT"'        >
]]>
</eg>


(For an explanation of the parameter entity <ident
type=pe>extptr</ident> used in the above example, see section <ptr
target=STpekw>.)

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

<!-- <note place=foot>This list includes all a-classes        -->
<!-- defined at the time this chapter was being completed;    -->
<!-- others may be added as the current draft is being        -->
<!-- completed.  -Ed.</note>                                  -->

<list type=gloss>

<label><ident type=class>declaring</ident> <item>elements which have a
<att>decls</att> attribute for specifying which declarations in the
header apply to the element, as described in section <ptr target=CCas>

<label><ident type=class>declarable</ident> <item>header elements
containing declarations, which can be pointed at by the <att>decls</att>
attribute, as described in section <ptr target=CCas>

<label><ident type=class>divn</ident> <item>structural elements which
behave in the same way as divisions, as described in section <ptr
target=DSdiv>

<label><ident type=class>enjamb</ident> <item>elements which carry the
<att>enjamb</att> attribute for indicating metrical enjambement

<!-- < label > flatterm  < item > elements used in the        -->
<!-- < soCalled > flat < /soCalled >  style of terminological -->
<!-- data, which take specialized attributes for              -->
<!-- indicating logical dependencies, as described in         -->
<!-- section  < xref target=TEflne >                          -->

<label><ident type=class>interpret</ident> <item>elements which contain
overtly interpretive or extra-textual analysis or commentary on a text
or some portion of it.

<label><ident type=class>metrical</ident> <item>elements which carry
metrical information (metrical pattern, realization of the pattern,
rhyme)

<label><ident type=class>names</ident> <item>elements which contain
proper nouns and share attributes for identifying their referents and
regularizing their spelling (section <ptr target=COnars>)

<label><ident type=class>personPart</ident> <item>elements which contain
personal names or parts of them

<label><ident type=class>placePart</ident> <item>elements which contain
place names or parts of them

<label><ident type=class>pointer</ident> <item>elements which point from
one location in the document to another (section <ptr target=COxr>)

<label><ident type=class>seg</ident> <item>elements for the systematic
or arbitrary segmentation of the text

<label><ident type=class>temporalExpr</ident> <item>elements which
contain temporal expressions

<label><ident type=class>timed</ident> <item>elements (in the base tag
set for spoken texts) which have a duration in time expressible with the
attributes, as described in section <ptr target=TSbati>

<label><ident type=class>typed</ident> <item>elements which carry
an additional semantic or functional classification

<label><ident type=class>xPointer</ident> <item>elements which point
from one location in the document to other locations within or outside
the current document (section <ptr target=SAxr>)

</list>

<p>All elements are considered members of the class <ident
type=class>global</ident> and thus include a reference to <ident
type=pe>a.global;</ident> in their attribute definition list
declaration.  Some tag sets add specialized attributes to the set of
global attributes; these additions are declared in the
<soCalled>ent</soCalled> 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.

<list type=gloss>

<!-- <label><ident type=pe>a.spoken</ident>                   -->
<!-- <item>additional global attributes for the spoken-text   -->
<!-- base                                                     -->

<label><ident type=pe>a.analysis</ident> <item>additional global
attributes for the analysis tag set

<label><ident type=pe>a.linking</ident> <item>additional global
attributes for the linking tag set

<label><ident type=pe>a.terminology</ident> <item>additional global
attributes for the terminology base

<!-- <label><ident type=pe>a.fs</ident> <item>additional      -->
<!-- global attributes for the feature structure tag set      -->

<!-- <label><ident type=pe>a.certainty</ident>                -->
<!-- <item>additional global attributes for the uncertainty   -->
<!-- tag set                                                  -->

</list>

<p>These entities are included in the <ident
type=file>teiclas2.ent</ident> file indirectly, when the
entity-declaration files of each tag set are embedded, as shown below in
section <ptr target=STecmk>.  For purposes of documentation, these
attributes are treated as if inherited by the class <ident
type=class>global</ident> from superclasses called
<ident type=class>terminology</ident>, etc.,
and are documented under the class name.
<!-- suppress class 'spoken' (vacuous)                        -->

<p>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
<gi>anchor</gi> inherits the global <att>id</att> attribute from the
class <ident type=class>global</ident> --- as does every other element.
On <gi>anchor</gi> elements, however, <att>id</att> is not optional but
required.  The declaration of <gi>anchor</gi> therefore does not refer
to the class <ident type=class>global</ident>, but instead defines all
the inherited attributes explicitly, using its own declaration for
<att>id</att> and the default inherited declarations for the other
global attributes:

<eg id=dstecx4>
<![ CDATA [
<!-- 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      >
]]>
</eg>


Because this declaration does not use the parameter entity <ident
type=pe>a.global</ident>, 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 <gi>anchor</gi> 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.

<eg id=dstecat>
<![ CDATA [
<!-- 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                      -->
]]>
</eg>

<!-- claDecl type=atts classDoc=flatterm -->
<!-- <claDecl type=atts classDoc=pname>                       -->
<!-- <claDecl type=atts classDoc=plname>                      -->
<!-- <claDecl type=atts classDoc=readings>                    -->

<div3 id=STeccm><head>Classes Used in Content Models</head>

<p>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
<soCalled>model-class</soCalled>).  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 <mentioned>m.</mentioned>, which can be
interpreted as <gloss>model</gloss> or as <gloss>members</gloss>.  The
replacement text of the entity is a list of the members of the class,
separated by <mentioned>|</mentioned>, the SGML symbol for alternation.

<p>For each class an additional entity is defined, which also takes the
name of the class, this time prefixed by the string <mentioned>x.</mentioned>
(for extension); the default value of these <term>x-dot entities</term>
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.

<p>For example, the class <ident type=class>bibl</ident> has the three
members <gi>bibl</gi>, <gi>bibl.full</gi>, and <gi>bibl.struct</gi>.
Its content-model entity is defined thus:

<eg>
<![ CDATA [
 <!ENTITY % x.bibl '' >
 <!ENTITY % m.bibl '%x.bibl bibl | bibl.full | bibl.struct' >
]]>
</eg>

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

<eg>
<![ CDATA [
 <!ENTITY % x.bibl 'myBib |' >
]]>
</eg>

This changes the replacement text of <ident type=pe>m.bibl</ident> from
its default value to <code type=frag>myBib | bibl | bibl.full |
bibl.struct</code>.  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 <emph>(including the last)</emph> followed
by a vertical bar.  The same effect could be achieved simply by
redefining the whole of the new <ident type=pe>m.bibl</ident> 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.

<p>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.

<p>For example, the class <ident type=class>phrase</ident> includes the
classes <ident type=class>data</ident>, <ident type=class>edit</ident>,
<ident type=class>hqphrase</ident>, <ident type=class>loc</ident>, and
<ident type=class>seg</ident> as members, as can be seen in the
declaration for its m-dot entity:

<eg id=dstecx5>
<![ CDATA [
<!-- 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'                            >
]]>
</eg>


When the entity <ident type=pe>m.phrase</ident> is referred to in
content models, all members of all subclasses are included in the model.

<div3 id=STecov><head>The TEICLAS2.ENT File</head>

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

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

<list type=gloss>
<label><term>chunks</term> <item>elements such as paragraphs and other
paragraph-level elements, which can appear directly within texts or
within text subdivisions (i.e. <gi>div</gi> elements), but not within
other chunks
<label><term>phrase-level elements</term> <item>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 <gi>div</gi>)
<note place=foot>Note that in this context, <term>phrase</term> means
any string of characters, and can apply to individual words, parts of
words, and groups of words indifferently; it does not refer only to
linguistically motivated phrasal units.  This may cause confusion for
readers accustomed to applying the word in a more restrictive sense.
</note>
<label><term>inter-level elements</term> <item>elements such as lists,
notes, quotations, etc. which can appear either between chunks (as
children of a <gi>div</gi>) or within them
</list>

<p>Together the two sets of <term>chunks</term> and <term>inter-level
elements</term> make up the set of:
<list type=gloss>
<label><term>text components</term> <item>elements which can appear
directly within texts or text divisions; also called simply
<term>components</term> or <soCalled>component-level elements</soCalled>
</list>
In general, the body of any text comprises a series of components,
optionally grouped into <gi>div</gi> elements.

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

<p>Some <term>component</term> elements (e.g. <gi>p</gi> or
<gi>note</gi>) 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.

<p>The <ident type=file>teiclas2.ent</ident> file has the following
overall structure:

<eg id=dstecov>
<![ CDATA [
<!-- 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 ...                                          -->

]]>
</eg>


<div3 id=STeclo><head>Low-Level Element Classes</head>

<p>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.

<p>The following are phrase-level element classes:

<list type=gloss>

<label><ident type=class>hqphrase</ident> <item>elements for highlighted
phrases or material marked by quotation marks, including those defined
in section <ptr target=COhq>

<label><ident type=class>data</ident> <item>elements for recording
information about the referents of a text, including those defined in
section <ptr target=COna>

<label><ident type=class>date</ident> <item>elements for recording
dates, including those defined in
section <ptr target=COnada>

<label><ident type=class>edit</ident> <item>elements for recording
simple editorial interventions in a text, including those defined in
section <ptr target=COed>

<label><ident type=class>loc</ident> <item>elements for recording
location information in a text, including those defined in section <ptr
target=COrs>

<label><ident type=class>seg</ident><item>elements for marking arbitrary
segments at the level of individual characters or phrases, including
those documented in section <ptr target=SAse> and <ptr target=AIlc>

<label><ident type=class>sgmlKeywords</ident><item>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 <ptr target=TD>)

<label><ident type=class>versePhrases</ident><item>phrase-level elements
specific to verse, documented in section <ptr target=VEse>

<label><ident type=class>formPointers</ident><item>elements for
referring, within a dictionary entry, to the orthographic form or
pronunciation of the headword, documented in section <ptr target=DIhw>

</list>

<p>The following are inter-level element classes:

<list type=gloss>

<label><ident type=class>hqinter</ident> <item>elements for highlighted
phrases or material marked by quotation marks, including those defined
in section <ptr target=COhq>

<label><ident type=class>bibl</ident> <item>elements for bibliographic
citations; see section <ptr target=CObi>

<label><ident type=class>lists</ident> <item>elements for lists; see
section <ptr target=COli>

<label><ident type=class>notes</ident> <item>general-purpose annotation
elements; see section <ptr target=COno>

<label><ident type=class>stageDirection</ident><item>elements for
specialized stage-direction elements documented in section <ptr
target=DRsta>

</list>

<p>The following classes of elements may appear anywhere within the
<gi>text</gi> element:

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

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


<p>The entity declarations for these classes are these:
<eg id=dsteclo>
<![ CDATA [
<!-- 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                      -->
]]>
</eg>


<div3 id=STechi><head>High-Level Element Classes</head>

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

<p>The element class <ident type=class>common</ident> 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 <ptr target=STco>.

<!-- in chapter <ptr target=CB>.                             -->

<p>The relevant portion of the DTD looks like this:
<eg id=dstechi>
<![ CDATA [
<!-- 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                      -->
]]>
</eg>


<div3 id=STecmk><head>Elements Marked for Text Type</head>

<p>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).

<list type=gloss>

<label><ident type=class>comp.verse</ident> <item>elements unique to
verse

<label><ident type=class>comp.drama</ident> <item>elements unique to
drama

<label><ident type=class>comp.spoken</ident> <item>elements unique to
spoken texts

<!-- <label><ident type=class>comp.letters</ident>            -->
<!-- <item>elements unique to letters and memoranda           -->

<label><ident type=class>comp.dictionaries</ident> <item>elements unique
to dictionaries

<label><ident type=class>comp.terminology</ident> <item>elements unique
to terminological data

</list>

<p>Declarations for these base-specific element classes are included in
the <term>entity file</term> of each base, which is in turn embedded by
the <ident type=file>teiclas2.dtd</ident> 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.

<eg id=dstecmk>
<![ CDATA [
<!-- 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                      -->
]]>
</eg>


<!-- <msection keywords='%TEI.letters'>                       -->
<!-- <entDecl entDoc=lment>                                   -->
<!-- <peRef n='TEI.letters.ent'>                              -->
<!-- </msection>                                              -->
<!-- <msection keywords='%TEI.fs'>                            -->
<!-- <entDecl entDoc=fsent>                                   -->
<!-- <peRef n='TEI.fs.ent'>                                   -->
<!-- </msection>                                              -->

<div3 id=STecst><head>Standard Content Models</head>

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

<list type=gloss>

<label><ident type=pe>phrase</ident> <item>a single sequence of
character data or single phrase-level element

<label><ident type=pe>phrase.seq</ident> <item>sequence of character
data and phrase-level elements

<label><ident type=pe>component</ident> <item>a single chunk- or
inter-level element

<label><ident type=pe>component.seq</ident> <item>sequence of chunk- and
inter-level elements; this is the usual content of a <gi>div</gi>
element

<label><ident type=pe>paraContent</ident> <item>sequence of character
data, phrase-level elements, and inter-level elements; this is the usual
content of chunks (including, most prominently, paragraphs)

<label><ident type=pe>specialPara</ident> <item>specialized content
model, allowing <emph>either</emph> a sequence of chunks <emph>or</emph>
the same content as <ident type=pe>paraContent</ident>; 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.

</list>

<p>The relevant portion of the DTD looks like this:

<eg id=dstecst>
<![ CDATA [
<!-- 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                      -->
]]>
</eg>


<!-- <msection keywords='%TEI.letters'>                       -->
<!-- <entDecl entDoc=lmcomp>                                  -->
<!-- </msection>                                              -->


<div3 id=STecmx><head>Components in Mixed and General Bases</head>

<p>When the mixed or general base is in use, the definitions of the
entities <ident type=pe>component</ident> and
<ident type=pe>component.seq</ident> are rather more complex.
The relevant portion of the DTD is this:

<eg id=dstecmx>
<![ CDATA [
<!-- 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                      -->
]]>
</eg>


<!-- <msection keywords='%TEI.letters'>                       -->
<!-- <commDecl>If the letters base is in use, ...</commDecl>  -->
<!-- <entDecl entDoc=lmgen>                                   -->
<!-- </msection>                                              -->

<!-- <entDecl entDoc=lmgenxx>                                 -->

<div3 id=STecmi><head>Miscellaneous Content-Model Classes</head>

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

<list type=gloss>

<label><ident type=class>agent</ident> <item>elements which denote an
individual or organization to whom or which responsibility for an action
can be assigned

<label><ident type=class>addrPart</ident> <item>elements which can occur
as part of an address

<label><ident type=class>biblPart</ident> <item>elements which can occur
in bibliographic citations

<label><ident type=class>demographic</ident> <item>elements which record
demographic characteristics of the participants in a text or language
interaction (used in tag set for corpora and collections)

<label><ident type=class>divbot</ident> <item>elements which can occur
as part of the closing material of a text division or body

<label><ident type=class>divtop</ident> <item>elements which can occur
as part of the opening material of a text division or body

<label><ident type=class>dramafront</ident> <item>elements which can
occur in the front matter of drama and other performance texts

<label><ident type=class>front</ident> <item>elements which can occur
(at the level of text divisions) in front matter only

<label><ident type=class>personPart</ident> <item>elements which contain
parts of a personal name

<label><ident type=class>placePart</ident> <item>elements which contain
parts of a place name

<label><ident type=class>tpParts</ident> <item>elements which occur
within title pages

<label><ident type=class>fmchunk</ident> <item>elements which can
occur in place of a title page in front matter only


</list>

<p>They are declared in the following DTD fragment:

<eg id=dstecmi>
<![ CDATA [
<!-- 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                      -->
]]>
</eg>


<!-- < note place=inline > [CO says  < gi > lb < /gi >  and   -->
<!-- < gi > pb < /gi >  are part of class loc, not of class   -->
<!-- refsys.  Is this an error?  Should they be moved to      -->
<!-- loc? -MSM] < /note > I believe this is an error. (LB)    -->
<!-- ... and have duly moved them to refsys -->
<!-- 7 Elem Classes           -->
<!-- $Id: p2stpe.odd,v 1.4 1994/04/08 18:54:36 msmcq Exp $ -->
<!-- $Log: p2stpe.odd,v $
# Revision 1.4  1994/04/08  18:54:36  msmcq
# Last-second fixes for P3
#
# Revision 1.3  1994/04/01  16:36:47  msmcq
# changes / fixes during validation of DTD
# -->
<!-- P2STpe :  Parameter Entities in TEI DTDs                 -->
<!-- Revisions:                                               -->
<!-- 94-04-08 : MSM : suppress reference to GFtop             -->
<!-- 94-04-08 : MSM : (it was renamed FTtop some time ago)    -->
<!-- 94-03-31 : MSM : add mention of TEI.singlebase           -->
<!-- 94-03-30 : MSM : suppress ref to lmtop                   -->
<!-- 94-03-30 : MSM : Added RCS id                            -->
<!-- 93-09-14 : MSM : move keyword defs to sep file           -->
<!-- 93-09-11 : MSM : rename teigis.ent as teigis2.ent        -->
<!-- 93-04-07 : MSM : cosmetic changes                        -->
<!--                  supply more info on ISO 8601            -->
<!--                  tag entities as terms (temporarily)     -->
<!-- 3 apr 93 : LB revise for publication                     -->
<!--   removed typo; added bib ref for ISO-date (ta, Domo)    -->
<!-- 93-03-30 : MSM : revise for LB                           -->
<!-- 93-03-16 : MSM : move technoid warning to STov.          -->
<!-- 93-03-06 : MSM : quick check before distribution to tei-tech -->
<!-- 93-03-01 : MSM : extract p2STpe from p2STec              -->
<!-- 93-02-02 : MSM : add dtd fragments                       -->
<!-- 93-02-02 : MSM : merge VM and PC changes                 -->
<!-- 25 Jan 93 : CMSMcQ : first revision for publication      -->
<!-- 21 Oct 92 : CMSMcQ : new id new name quick full draft    -->
<!-- 17 May 92 : CMSMcQ : began draft                         -->

<div2 id=STpe><head>Other Parameter Entities in TEI DTDs</head>

<!-- point:  you need to know what the pe's are to read the DTDs. -->
<!-- uses of p.e.'s in TEI DTDs:                              -->
<!--         - identify base, toppings                        -->
<!--         - specify groups of attributes common to several -->
<!--           elements                                       -->
<!--         - specify groups of elements which appear in     -->
<!--           content models                                 -->
<!--         - include or exclude each element                -->
<!--         - specify name for each element                  -->
<!-- notion of element class:  common locations or atts       -->
<!-- Major p.e.'s of the TEI DTDs:                            -->
<!--         soup                                             -->
<!--         broth                                            -->
<!--         chunks                                           -->
<!--         p.e.s for bases and toppings                     -->

<p>The TEI DTDs use SGML parameter entities for several purposes:

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

The first two applications of parameter entities are described above in
section <ptr target=STec>.  This chapter describes the other uses of
parameter entities in the TEI DTDs.

<p>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 <ptr target=STba>.  Their default definition is
always <q>IGNORE</q>:  the encoder selects the TEI base and additional
tag sets by declaring the appropriate parameter entities with the
entity text <q>INCLUDE</q>.

<p>The DTD and entity files are listed in section <ptr target=STba>; 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.

<p>The following entities are referred to by the main
<ident type=file>tei2.dtd</ident> file to embed portions of the TEI DTDs
or locally developed extensions.

<list type=gloss>
<label><ident type=pe>TEI.extensions.ent</ident>
<item>identifies a local file containing
extensions to the TEI parameter entities; see section
<ptr target=STovlo>
<label><ident type=pe>TEI.extensions.dtd</ident>
<item>identifies a local file containing
extensions to the TEI tag set; see section <ptr target=STovlo>
<label><ident type=pe>TEI.elementNames</ident>
<item>identifies a file containing parameter
entity declarations for names of TEI elements; see section
<ptr target=STpegi>
<label><ident type=pe>TEI.keywords</ident>
<item>identifies a file containing parameter
entity declarations for TEI keywords, including the default
declaration (<q>IGNORE</q>) of the marked-section keyword for
each tag set; see section
<ptr target=STpekw>
<label><ident type=pe>TEI.elementClasses</ident> <item>identifies a file
containing definitions of parameter entities used in content models; see
section <ptr target=STecov>
<label><ident type=pe>TEI.singleBase</ident> <item>defined as
<code>INCLUDE</code>
(for normal bases) or <code>IGNORE</code> (for mixed and general base);
used to prevent multiple definitions of the default text structure.
</list>

<div3 id=STpeex><head>Inclusion and Exclusion of Elements</head>

<p>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
<ptr target=MD>.

<p>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 <q>INCLUDE</q> but they may
be changed to <q>IGNORE</q> in order to exclude the standard element and
attribute definition list declarations from the DTD.

<p>The declarations for the element <gi>p</gi>, for example, are
preceded by a definition for a parameter entity with the name
<ident type=ge rend=noindex>p</ident> and contained within a marked
section whose keyword is
given as <q>%p;</q>:

<eg>
<![ RCDATA [
 <!ENTITY % p 'INCLUDE' >
 <![ %p; [
        <!-- element and attlist declaration for p here -->
 ]&nil;]>
]]>
</eg>

<p>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.

<div3 id=STpegi><head>Parameter Entities for Element Generic Identifiers</head>

<p>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 <ptr target=MD>).
Parameter entities used for this purpose are formed
by taking the standard name (generic identifier) of the element and
attaching the string <q>n.</q> as a prefix.  Thus the standard generic
identifiers for paragraphs, notes, and quotations, <gi>p</gi>,
<gi>note</gi>, and <gi>q</gi> are defined by declarations of the
following form:

<eg>
<![ CDATA [
 <!ENTITY % n.p    'p' >
 <!ENTITY % n.note 'note' >
 <!ENTITY % n.q    'q' >
]]>
</eg>

<p>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.

<p>The formal declarations of the parameter entities used for generic
identifiers are contained in the
file <ident type=file>teigis2.ent</ident>; 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 <ident type=pe>TEI.elementNames</ident> is
used to embed the file <ident type=file>teigis2.ent</ident> in the DTD.
A full set
of alternate generic identifiers can be substituted for the standard set
by defining <ident type=pe>TEI.elementNames</ident> to point at a
different
file.<note place=foot>It is expected that after completion of the full
text of these Guidelines, the TEI will prepare alternate sets of generic
identifiers in languages other than English.  It should be noted,
however, that in the interests of simplicity parameter entities are
used only for generic identifiers; attribute names, standard attribute
values, and parameter entity names are less easily modified.
</note>

<div3 id=STpekw><head>Parameter Entities for TEI Keywords</head>

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

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

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

<!-- no % for consistency with other p.e. names -->
<p>The parameter entity <ident type=pe>INHERITED</ident> is used
to signal that the default value for an attribute should be inherited
from an enclosing element.
The definition for <ident type=pe>INHERITED</ident> is
the string <q>#IMPLIED</q>; 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 <q>%INHERITED</q> and
those whose default is <q>#IMPLIED</q> --- information about which
attribute values are inherited and which are inferred in some other way
must be built into the application in advance.

<p>The parameter entity <ident type=pe>ISO-date</ident> is used to
signal that
the value for an attribute should be an ISO-standard date value; in
this notation,<note>Defined by ISO 8601: 1988,
<!-- < title > Codes for the representation of dates          -->
<!-- and times < /title >                                     -->
<title>Data elements and interchange formats --- Information
interchange ---  Representation of dates and times</title>
([Geneva]:  International Organization for Standardization, 1988).
</note>
a date like <q>September 22, 1968</q> would be written
<q>1968-09-22</q>.  The parameter entity <ident type=pe>ISO-date</ident>
expands to <q>CDATA</q>.

<p>The keywords controlling the selection of base and additional tag
sets (described in section <ptr target=STba>) all have the default
value <q>IGNORE</q>; the user can override this by a local declaration,
as described in section <ptr target=STin>.

<p>The parameter entities for TEI keywords are included in file
<ident type=file>teikey2.dtd</ident>, which is the default replacement
text for the entity <ident type=pe>TEI.keywords</ident> and is embedded
by the file <ident type=file>tei2.dtd</ident>.

<p>The file <ident type=file>teikey2.dtd</ident> has the following
contents:

<eg id=dstkeys>
<![ CDATA [
<!-- 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'                                  >

]]>
</eg>


<p>The relevant portion of the main DTD looks like this:
<eg id=dstpekw>
<![ CDATA [
<!-- 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                      -->
]]>
</eg>

<!-- <entDecl entDoc='LMtop'>                                 -->
<!-- 8 Other Parameter Ents   -->
</div1>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-default-dtd-file:"~/lib/psgml/p2odd.ced"
sgml-parent-document:("/home/tei/P3/Master/Odds/p2.odd" "TEI.1" "TEXT" "BODY" "DIV1")
sgml-omittag:t
sgml-shorttag:t
End:
-->
            <!-- 3 Structure of TEI DTDs   -->
<!>

