<!-- $Id: p2hd.odd,v 1.4 1998/01/28 11:09:58 cmsmcq Exp $ -->
<!-- $Log: p2hd.odd,v $
# Revision 1.4  1998/01/28  11:09:58  cmsmcq
# LB changes of January 1998
#
# Revision 1.3  1994/03/24  22:14:56  msmcq
# typo corrections from David Barnard, Peter Robinson, and others
#
# Revision 1.2  1993/06/23  01:41:20  msmcq
# add keywords at top
# -->
<!-- Revisions:                                               -->
<!-- 4 jan 98 : LB : added explanatoryu sentence about computer file -->
<!-- 94-03-22 : CMSMcQ : wording changes from DB              -->
<!-- 94-03-22 : CMSMcQ : typos, TEI - &tei, code, ident tags  -->
<!-- 93-06-02 : MSM : add ref to SH                           -->
<!-- 93-06-01 : MSM : post-Eynsham:  normalize teiHeader      -->
<!-- 93-06-01 : MSM : post-Eynsham:  suppress AH refs         -->
<!-- 93-02-11 : MSM : change N value on div1                  -->
<!-- 93-02-10 : MSM : update xref targets                     -->
<!-- 93-02-10 : MSM : comment out reference to hdtags (refer in p2hddriv) -->
<!-- 93-02-10 : MSM : put entity refs for subfiles on own lines -->
<!-- 92-08-18 : MSM : replace separate tag files with hdtags  -->
<!-- 92-08-18 : MSM : Changes to xrefs                        -->
<!-- 14 Aug 92 : MSM : more changes                           -->
<!-- 5 Aug 92: LB : last check: fixed xrefs                   -->
<!-- 1 Aug 92 : LB : Further revisions; adding xrefs and final para  -->
<!-- 22 Jul 92 : MSM : Redivide, recast slightly.             -->

<div1 n='5' id=hd><head>The TEI Header</head>

<p>This chapter addresses the problems of describing an encoded work so
that the text itself, its source, its encoding, and its revisions are
all thoroughly documented.  Such documentation is equally necessary for
scholars using the texts, for software processing them, and for
cataloguers in libraries and archives.  Together these descriptions and
declarations provide an electronic analogue to the title page attached
to a printed work.  They also constitute an equivalent for the content
of the code books or introductory manuals customarily accompanying
electronic data sets.

<p>Every TEI-conformant text must carry such a set of descriptions,
prefixed to it and encoded as described in this chapter.  The set is
known as the <term>TEI header</term>, tagged <gi>teiHeader</gi>,
and it has four major parts:

<list type=bullets>

<item>a <term>file description</term>, tagged <gi>fileDesc</gi>,
containing a full bibliographical description of the computer file
itself, from which a user of the text could derive a proper
bibliographic citation, or which a librarian or archivist could use in
creating a catalogue entry recording its presence within a library or
archive.  The term <term>computer file</term> here is to be understood
as referring to the whole entity or document described by the header,
even when this is stored in several distinct operating system files.
The file description also includes information about the
source or sources from which the electronic document was derived.  The TEI
elements used to encode a file description are described in section
<ptr target=hd2> below.

<item>an <term>encoding description</term>, tagged <gi>encodingDesc</gi>,
which describes the relationship between an electronic text and its
source or sources.  It allows for detailed description of whether (or
how) the text was normalized during transcription, how the encoder
resolved ambiguities in the source, what levels of encoding or analysis
were applied, and similar matters. The TEI elements used to encode the
encoding description are described in section <ptr target=hd5> below.

<item>a <term>text profile</term>, tagged <gi>profileDesc</gi>,
containing classificatory and contextual information about the text,
such as its subject matter, the situation in which it was produced, the
individuals described by or participating in producing it, and so forth.
Such a text profile is of particular use in highly structured composite
texts such as corpora or language collections, where it is often highly
desirable to enforce a controlled descriptive vocabulary or to perform
retrievals from a body of text in terms of text type or origin.  The
text profile may however be of use in any form of automatic text
processing.  The TEI elements used to encode the profile description
are described in section <ptr target=hd4> below.

<item>a <term>revision history</term>, tagged <gi>revisionDesc</gi>,
which allows the encoder to provide a history of changes made during the
development of the electronic text.  The revision history is important
for <term>version control</term> and for resolving questions about the
history of a file.  The TEI elements used to encode the revision
description are described in section <ptr target=hd6> below.</list>

<p>A TEI header can be a very large and complex object, or it may be a
very simple one.  Some application areas (for example, the construction
of language corpora and the transcription of spoken texts) will require
more specialized and detailed information than others.  The present
proposals therefore define both a <term>core</term> set of elements,
(all of which may be used without formality in any TEI header) and
<term>additional tagsets</term>, which may be invoked as extensions as
needed.  For more details of this extension mechanism, see chapter <ptr
target=STba>; the header extensions are fully described in chapter <ptr
target=cc>, which should be read in conjunction with the present
chapter.

<p>The next section of the present chapter briefly introduces the
overall structure of the header, and the kinds of data it may contain.
This is followed by a detailed description of all the constituent
elements which may be used in the core header.  Section <ptr
target=hd7>, at the end of the present chapter, discusses the
recommended content of a minimal TEI header, and its relation to
standard library cataloguing practices.  Recommendations relevant to the
use of TEI headers as free-standing documents, for interchange among
libraries, data archives, and similar institutions may be found in
chapter <ptr target=SH>.

<!-- $Id: p2hd1.odd,v 1.4 1998/01/28 11:09:58 cmsmcq Exp $ -->
<!-- $Log: p2hd1.odd,v $
# Revision 1.4  1998/01/28  11:09:58  cmsmcq
# LB changes of January 1998
#
# Revision 1.3  1994/03/24  22:14:56  msmcq
# typo corrections from David Barnard, Peter Robinson, and others
# -->
<!-- Revision:                                                -->
<!-- 10 jan 98 : LB : tweak egs to disappear -->
<!-- 94-03-22 : CMSMcQ : typos, TEI - &tei, code, ident tags  -->
<!-- 93-06-04 : MSM : replace ref to PR3 with ref to DSfront  -->
<!-- 93-06-02 : MSM : use std dtdstart entity in dtdfrag      -->
<!-- 93-06-01 : MSM : normalize teiHeader                     -->
<!-- 93-02-10 : MSM : update xref targets                     -->
<!-- 92-08-18 : MSM : fixed xrefs                             -->
<!-- 92-08-14 : MSM : more changes, typos, ...                -->
<!-- 5 Aug 92 : LB : last check: to UIC                       -->
<!-- 1 Aug 92 : LB  : further revisions                       -->
<!-- 22 Jul 92 : MSM : Redivide, recast slightly.             -->
<!-- 25 Jul 92 : MSM : rigorous application of ML name rules  -->
<!--                   the results seem odd, either because   -->
<!--                   unfamiliar or because ML rules need    -->
<!--                   revision.  See how they wear.          -->

<div2 id=hd1><head>Organization of the TEI Header</head>

<div3 id=hd11><head>The TEI Header and Its Components</head>

<p>The <gi>teiHeader</gi> element should be clearly distinguished both
from the <term>SGML prolog</term>, which comprises the SGML declaration
and the document type declaration (see chapter <ptr target=SG>), and
from the <term>front matter</term> of the text itself (for which see
section <ptr target='DSfront'>).  A composite text, such as a corpus or
collection, may contain several headers, as further discussed below.  In
the usual case however, a TEI-conformant text will contain a single
<gi>teiHeader</gi> element, followed by a single <gi>text</gi> element.

<p>The header element has the following description:

<list type=gloss>
<label><gi>teiHeader</gi></label>
<item>supplies the descriptive and declarative information making 
up an
<q>electronic title page</q> prefixed to every

TEI-conformant text.
Attributes include:
<list type=gloss>
<label><att>type</att></label>
<item>specifies the kind of document to which the header is 
attached.
Legal values are:
<list type=gloss>
<label><term>corpus</term></label>
<item>the header is attached to a corpus.</item>
<label><term>text</term></label>
<item>the header is attached to a single text.</item>
</list></item>
</list>
</item>
</list>


<p>As discussed above, the <gi>teiHeader</gi> element has four principal
components:

<list type=gloss>
<label><gi>fileDesc</gi></label>
<item>contains a full bibliographic description of an electronic

file.</item>
<label><gi>encodingDesc</gi></label>
<item>documents the relationship between an electronic text and 
the
source or sources from which it was derived.</item>
<label><gi>profileDesc</gi></label>
<item>provides a detailed description of non-bibliographic 
aspects of a
text, specifically the languages and 
sublanguages used, the situation in
which it was produced, 
the participants and their setting.</item>
<label><gi>revisionDesc</gi></label>
<item>summarizes the revision history for a file.</item>
</list>


<p>Of these, only the <gi>fileDesc</gi> element is required in all TEI
headers; the others are optional.  The full form of a TEI header is
thus:

<eg rend=skel>
<![ CDATA [
<teiHeader>
    <fileDesc> ... </fileDesc>
    <encodingDesc> ... </encodingDesc>
    <profileDesc> ... </profileDesc>
    <revisionDesc> ... </revisionDesc>
</teiHeader>
]]>
</eg>

while a minimal header takes the form:

<eg rend=skel>
<![ CDATA [
<teiHeader>
    <fileDesc> ... </fileDesc>
</teiHeader>
]]>
</eg>

<p>In the case of language corpora or collections, it may be
desirable to record header information either at the level of individual
components in the corpus or collection, or once for all at the level of
the corpus or collection itself, or at both levels.  More details
concerning the tagging of composite texts are given in section <ptr
target='CC'>, which should be read in conjunction with the current
chapter.  An optional <att>type</att> attribute may also be supplied on
the <gi>teiHeader</gi> element to indicate whether the header applies
to a corpus or a single text.  A corpus may thus take the form:

<eg rend=skel>
<![ CDATA [
<tei.2>
    <teiHeader type=corpus> ...
    <!-- header for corpus-level information -->
    </teiHeader>
    <tei.2>
         <teiHeader type=text> ...
         <!-- header for text-level information -->
         </teiHeader>
         <text> ... </text>
    </tei.2>
    <tei.2>
         <teiHeader type=text> ... </teiHeader>
         <text> ... </text>
    </tei.2>
    <!-- etc. -->
</tei.2>
]]>
</eg>

<!-- left this in for now, but I dont think it's very helpful (LB) -->
<!-- that's cause you already know it.  the reader don't. -msm     -->

<p>The tags required for the TEI header are defined in the DTD file
<ident type=file>teihdr2</ident> which first defines the
<gi>teiHeader</gi> element:

<eg id=d221>
<![ CDATA [
<!-- 5.1.1:  The TEI Header                                   -->
<!-- teihdr2.dtd  Tags for TEI Header.                        -->

<!-- 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.         -->
<!ELEMENT teiHeader     - -  (fileDesc, encodingDesc*, 
                             profileDesc*, revisionDesc?)       >
<!ATTLIST teiHeader          %a.global;
          creator            CDATA               #IMPLIED
          date.created       CDATA               #IMPLIED
          status             (new | update)      new
          type               CDATA               text
          date.updated       CDATA               #IMPLIED       >
<!-- (continued in sec. 5.1.1)                                -->
]]>
</eg>


<p>Then it defines the rest of the header elements, embedding the
DTD fragments found later in this chapter:

<eg id=d221b>
<![ CDATA [
<!-- 5.1.1:  The TEI Header (cont'd)                          -->
<!-- (continuation of sec. 5.1.1)                             -->
<!-- ... declarations from section 5.2                        -->
<!--     (The file description)                               -->
<!--     go here ...                                          -->
<!-- ... declarations from section 5.2.7                      -->
<!--     (The source description)                             -->
<!--     go here ...                                          -->
<!-- ... declarations from section 5.3                        -->
<!--     (The encoding description)                           -->
<!--     go here ...                                          -->
<!-- ... declarations from section 5.4                        -->
<!--     (The profile description)                            -->
<!--     go here ...                                          -->
<!-- ... declarations from section 5.5                        -->
<!--     (The Revision Description)                           -->
<!--     go here ...                                          -->
]]>
</eg>


<div3 id=hd12><head>Types of Content in the TEI Header</head>

<p>The elements occurring within the TEI header may contain several
types of content; the following list indicates how these types of
content are described in the following sections:

<list type=gloss>

<label>free prose <item>Most elements contain simple running prose at
some level.  Many elements may contain either prose (possibly organized
into paragraphs) or more specific elements, which themselves contain
prose.  In this chapter's descriptions of element content, the phrase
<mentioned>prose description</mentioned> should be understood to imply a series of
paragraphs, each marked with the <tag>p</tag> tag.  The word
<mentioned>phrase</mentioned>, by contrast, should be understood to imply
character data, interspersed as need be with phrase-level elements, but
not organized into paragraphs.  For more information on paragraphs,
highlighted phrases, lists, etc., see section <ptr target='COpa'>.
<!-- or target=COpara -->

<label>grouping elements <item>Elements whose names end with the
suffix <mentioned>Stmt</mentioned> (e.g. <gi>editionStmt</gi>,
<gi>situationStmt</gi>) usually enclose a group of specialized elements
recording some structured information.  In the case of the bibliographic
elements, the suffix <mentioned>Stmt</mentioned> is used in names of elements
corresponding to the <soCalled>areas</soCalled> of the International
Standard Bibliographic Description.
<note>
<!-- need bibliographic reference for ISBD -->
On the relation between the TEI proposals and other standards for
bibliographic description, see further section <ptr
target='HD8'>.</note>
<!-- or target=p2.228 -->

In most cases grouping elements may contain prose descriptions as an
alternative to the set of specialized elements, thus allowing the
encoder to choose whether or not the information concerned should be
presented in a structured form or in prose.

<label>declarations <item>Elements whose names end with the suffix
<mentioned>Decl</mentioned> (e.g.  <gi>subjectDecl</gi>, <gi>refsDecl</gi>)
enclose information about specific encoding practices applied in the
electronic text; often these practices are described in coded form.
Typically, such information takes the form of a series of declarations,
identifying a code with some more complex structure or description.  A
declaration which applies to more than one text or division of a text
need not be repeated in the header of each such text.  Instead, the
<att>decls</att> attribute of each text (or subdivision of the text) to
which the sampling declaration applies may be used to supply a cross
reference to it, as further described in section <ptr target='CCas'>.
<!-- was:  target=p2.3431>. -->
<!-- was:  target=SP31>. -->

<label>descriptions <item>Elements whose name end with the suffix
<mentioned>Desc</mentioned> (e.g.  <gi>settingDesc</gi>, <gi>projectDesc</gi>)
contain a prose description, possibly organized under some specific
headings by suggested sub-elements, but not necessarily so.

</list>

<!-- $Id: p2hd2.odd,v 1.5 1998/01/28 11:09:58 cmsmcq Exp $ -->
<!-- $Log: p2hd2.odd,v $
# Revision 1.5  1998/01/28  11:09:58  cmsmcq
# LB changes of January 1998
#
# Revision 1.4  1994/03/24  22:14:56  msmcq
# typo corrections from David Barnard, Peter Robinson, and others
# -->
<!-- Revisions:                                               -->
<!-- 11 jan 98 : LB : fix egs, first pass -->
<!-- 94-03-22 : CMSMcQ : typos, TEI - &tei, code, ident tags  -->
<!--                     typos from DB                        -->
<!-- 28 dec 93: LB: change CITY to PUBPLACE passim -->
<!-- 93-08-18 : MSM : suppress respStmt, resp (resp, role)    -->
<!-- 93-08-18 : MSM : decls:  they go in core not here        -->
<!-- 93-06-03 : MSM : replace PLACE tag by CITY               -->
<!-- 93-06-01 : MSM : normalize citn, teihead, xrefs to ah    -->
<!--                  give example of copyright claim         -->
<!-- 93-02-10 : MSM : update xref targets                     -->
<!-- 92-08-18 : MSM : minor punctuation, typo fixes           -->
<!-- 92-08-18 : MSM : revisions                               -->
<!-- 92-08-18 : MSM : fix some xrefs                          -->
<!-- 92-08-18 : MSM : provide citn for AACR 2                 -->
<!-- 92-08-14 : MSM : revise, fix details                     -->
<!-- 5 Aug 92 : LB : fixed up xrefs                           -->
<!-- 1 Aug 92 : LB : further revision                         -->
<!-- 23-6 Jul 92 : CMSMcQ : revision                          -->
<!-- 28 May 92 : CMSMcQ : changed all simple lists to bullets -->

<div2 id=HD2><head>The File Description</head>

<p>This section describes the <gi>fileDesc</gi> element, which is the
first component of the <gi>teiHeader</gi> element.

<p>The bibliographic description of a machine-readable text
resembles in structure that of a book, an article, or any other kind of
textual object.  The file description element of the TEI header has
therefore been closely modelled on existing standards in library
cataloguing; it should thus provide enough information to allow users
to give standard bibliographic references to the electronic text, and
to allow cataloguers to catalogue it.  Bibliographic citations
occurring elsewhere in the header, and also in the text itself, are
derived from the same model (on bibliographic citations in general, see
further section <ptr target=CObi>).  See further section <ptr
target=hd8>.

<!-- or target='CObibl' -->

<p>The bibliographic description of the electronic text (not its
source) is given in the mandatory <gi>fileDesc</gi> element:
<list type=gloss>
<label><gi>fileDesc</gi></label>
<item>contains a full bibliographic description of an electronic

file.</item>
</list>


<p>The <gi>fileDesc</gi> element contains three mandatory elements and
four optional elements, each of which is described in more detail in
sections <ptr target=hd21> to <ptr target=hd27> below. These elements
are listed below in the order in which they must be given within the
<gi>fileDesc</gi> element.
<list type=gloss>
<label><gi>titleStmt</gi></label>
<item>groups information about the title of a work and those

responsible for its intellectual content.</item>
<label><gi>editionStmt</gi></label>
<item>groups information relating to one edition of a text.</item>
<label><gi>extent</gi></label>
<item>describes the approximate size of the electronic text as 
stored on
some carrier medium, specified in any convenient 
units.</item>
<label><gi>publicationStmt</gi></label>
<item>groups information concerning the publication or 
distribution
of an electronic or other text. </item>
<label><gi>seriesStmt</gi></label>
<item>groups information about the <term>series</term>, if any, 
to which
a publication belongs.</item>
<label><gi>notesStmt</gi></label>
<item>collects together any notes providing information about a 
text
additional to that recorded in other parts of the 
bibliographic
description.</item>
<label><gi>sourceDesc</gi></label>
<item>supplies a bibliographic description of the copy text(s) 
from
which an electronic text was derived or generated.</item>
</list>


<p>A file description containing all possible subelements has the
following structure:

<eg rend="skel">
<![ CDATA [
<teiHeader>
    <fileDesc>
         <titleStmt> ... </titleStmt>
         <editionStmt> ... </editionStmt>
         <extent> ... </extent>
         <publicationStmt> ... </publicationStmt>
         <seriesStmt> ... </seriesStmt>
         <notesStmt> ... </notesStmt>
         <sourceDesc> ... </sourceDesc>
    </fileDesc>
    <!-- remainder of TEI Header here -->
</teiHeader>
]]>
</eg>

Several of these elements may be omitted; a minimal file description has
the following structure:

<eg rend=skel>
<![ CDATA [
<teiHeader>
    <fileDesc>
         <titleStmt> ... </titleStmt>
         <publicationStmt> ... </publicationStmt>
         <sourceDesc> ... </sourceDesc>
    </fileDesc>
    <!-- remainder of TEI Header here -->
</teiHeader>
]]>
</eg>

<p>The <gi>fileDesc</gi> itself has the following formal definition:

<eg id=d222>
<![ CDATA [
<!-- 5.2:  The file description                               -->
<!ELEMENT fileDesc      - -  (titleStmt, editionStmt?, extent?, 
                             publicationStmt, seriesStmt?, 
                             notesStmt?, sourceDesc+ )          >
<!ATTLIST fileDesc           %a.global;                         >
<!-- ... declarations from section 5.2.1                      -->
<!--     (The title statement)                                -->
<!--     go here ...                                          -->
<!-- ... declarations from section 5.2.2                      -->
<!--     (The edition statement)                              -->
<!--     go here ...                                          -->
<!-- ... declarations from section 5.2.3                      -->
<!--     (The extent statement)                               -->
<!--     go here ...                                          -->
<!-- ... declarations from section 5.2.4                      -->
<!--     (The publication statement)                          -->
<!--     go here ...                                          -->
<!-- ... declarations from section 5.2.5                      -->
<!--     (The series statement)                               -->
<!--     go here ...                                          -->
<!-- ... declarations from section 5.2.6                      -->
<!--     (The notes statement)                                -->
<!--     go here ...                                          -->
<!-- This fragment is used in sec. 5.1.1                      -->
]]>
</eg>


<div3 id=HD21><head>The Title Statement</head>
<p>The <gi>titleStmt</gi> element is the first component of the
<gi>fileDesc</gi> element, and is mandatory:
<list type=gloss>
<label><gi>titleStmt</gi></label>
<item>groups information about the title of a work and those

responsible for its intellectual content.</item>
</list>

It contains the title given to the electronic work, together with
optionally one or more <term>statements of responsibility</term> which
identify the encoder, author, compiler, or other parties responsible
for it:

<list type=gloss>
<label><gi>title</gi></label>
<item>contains the title of a work, whether article, book, 
journal, or
series, including any alternative titles or 
subtitles.</item>
<label><gi>author</gi></label>
<item>in a bibliographic reference, contains the name of the 
author(s),
personal or corporate,
of a work; the primary 
<term>statement of responsibility</term> for any

bibliographic item. </item>
<label><gi>sponsor</gi></label>
<item>specifies the name of a sponsoring organization or

institution.</item>
<label><gi>funder</gi></label>
<item>specifies the name of an individual, institution, or 
organization
responsible for the funding of a project or 
text.</item>
<label><gi>principal</gi></label>
<item>supplies the name of the principal researcher responsible 
for the
creation of an electronic text.</item>
<label><gi>respStmt</gi></label>
<item>supplies a statement of responsibility for someone 
responsible for
the intellectual content of a text, 
edition, recording, or series, where
the specialized 
elements for authors, editors, etc. do
not suffice or do 
not apply.</item>
<label><gi>resp</gi></label>
<item>contains a phrase describing the nature of a person's

intellectual responsibility.</item>
<label><gi>name</gi></label>
<item>contains a proper noun or noun phrase.</item>
</list>


<!-- < div4 id=HD211>< head>Title< /head>                     -->

<p>The <gi>title</gi> element contains the chief name of the
file, including any alternative title or subtitles it may have.
It may be repeated, if the file has more than one title,
(perhaps in different languages) and takes whatever form is
considered appropriate by its creator.  Where the electronic work
is derived from an existing source text, it is strongly
recommended that the title for the former should also be derived
from the latter, but that it should be clearly distinguishable
from it.  For example, do not call the computer file <q>A
Sanskrit-English Dictionary, based upon the St. Petersburg
Lexicons</q>.  Call it, rather, <q>Sanskrit-English Dictionary,
based upon the St. Petersburg Lexicons: a machine readable
transcription</q>.  If you wish to retain some or all of the
title of the source text in the title of the computer file, then
introduce one of the following phrases:

<list type=bullets>
<item>[title of source]:  a machine readable transcription.
<item>[title of source]:  electronic edition.
<item>A machine readable version of:  [title of source].
</list>

This will distinguish the computer file from the source text in
citations and in catalogues which contain descriptions of both types of
material.

<p>The computer file will almost certainly have an external name (its
<soCalled>filename</soCalled> or <soCalled>data set name</soCalled>) or reference number on the
computer system where it resides at any time.  This name is likely to
change frequently, as new copies of the file are made on the computer
system.  Its form is entirely dependent on the particular computer
system in use and thus cannot always easily be transferred from one
system to another.  For these reasons, these Guidelines strongly
recommend that such names should <emph>not</emph> be used as the title
for any computer file.

<p>Helpful guidance on the formulation of useful descriptive titles in
difficult cases may be found in the Anglo-American Cataloguing Rules
(AACR 2), chapter 25, or in equivalent national-level bibliographical
documentation.<note place=foot>
<bibl>Michael Gorman and Paul W. Winkler, eds.,
<title>Anglo-American Cataloguing Rules</title>, Second Edition
(Chicago:  American Library Association; London:  Library Association;
Ottawa:  Canadian Library Association, 1978).
</bibl>
</note>

<!-- < div4 id=HD212>< head>Statements of responsibility< /head> -->

<p>The specialized elements <gi>author</gi>, <gi>sponsor</gi>,
<gi>funder</gi>, and <gi>principal</gi>, and the more general
<gi>respStmt</gi> provide the <term>statements of responsibility</term>
which identify the persons responsible for the intellectual or artistic
content of an item and any corporate bodies from which it emanates.

<p>Any number of statements of responsibility may occur within the title
statement.  At a minimum, identify the author of the text and the
creator of the machine-readable file.  If the bibliographic description
is for a corpus, identify the creator of the corpus.  These
identifications are mandatory when applicable, though not enforceable by
the SGML parser.  Optionally include also names of others involved in
the transcription or elaboration of the text, sponsors, and funding
agencies.  The name of the person responsible for physical data input
need not normally be recorded, unless that person is also intellectually
responsible for some aspect of the creation of the file.

<p>Where the person whose responsibility is to be documented is not an
author, sponsor, funding body or principal researcher, the <gi>respStmt</gi>
element should be used.  This has two subcomponents: a <gi>name</gi>
element identifying a responsible individual or organization, and a
<gi>resp</gi> element indicating the nature of the responsibility.  No
specific recommendations are made at this time as to appropriate content
for the <gi>resp</gi>:  it should make clear the nature of the
responsibility concerned, as in the examples below.

<p>Names given may be personal names or corporate names.  Give all names
in the form in which the persons or bodies wish to be publicly cited.
This would usually be the fullest form of the name, including first
names.  <note place=foot>Agencies compiling catalogues of
machine-readable files are recommended to use available authority lists,
such as the Library of Congress Name Authority List, for all common
personal names.
<!-- bib ref needed here --> </note>

<p>Examples:

<eg><![ CDATA[
<titleStmt>
  <title>Capgrave's Life of St. John Norbert:  a
     machine-readable transcription</title>
  <respStmt>
      <resp>compiled by</resp> <name>P.J. Lucas</name>
  </respStmt>
</titleStmt>
]]>
</eg>
<eg><![ CDATA[
<titleStmt>
  <title>Two stories by Edgar Allen Poe:
           electronic version</title>
  <author>Poe, Edgar Allen (1809-1849)
  <respStmt><resp>compiled by</resp>
  <name>James D. Benson</name></respStmt>
</titleStmt>
]]>
</eg>
<eg><![ CDATA[
<titleStmt>
  <title>Yogadar&sacute;anam (arth&amacr;t
         yogas&umacr;trap&macr;&tdot;ha&hdot;):
         a machine readable transcription.</title>
  <title>The Yogas&umacr;utras of Pata&ntilde;jali:
         a machine readable transcription.</title>
  <funder>Wellcome Institute for the History of Medicine
  </funder>
  <principal>Dominik Wujastyk</principal>
  <respStmt><name>Wieslaw Mical</name>
        <resp>data entry and proof correction</resp>
  </respStmt>
  <respStmt><name>Jan Hajic</name>
        <resp>conversion to TEI-conformant markup</resp>
  </respStmt>
</titleStmt>
]]>
</eg>
<!>

<p>The formal definition of the <gi>titleStmt</gi> element and its
constituents is as follows:

<eg id=d2221>
<![ CDATA [
<!-- 5.2.1:  The title statement                              -->
<!ELEMENT titleStmt     - o  ((title+, (author | editor | 
                             sponsor | funder | principal | 
                             respStmt)*))                       >
<!ATTLIST titleStmt          %a.global;                         >
<!ELEMENT sponsor       - o  ( %phrase.seq; )                   >
<!ATTLIST sponsor            %a.global;                         >
<!ELEMENT funder        - o  ( %phrase.seq; )                   >
<!ATTLIST funder             %a.global;                         >
<!ELEMENT principal     - o  (%phrase.seq;)                     >
<!ATTLIST principal          %a.global;                         >
<!-- The TITLE, AUTHOR, NAME, RESPSTMT, and RESP elements     -->
<!-- are declared in file teicore2.dtd, not here.             -->

<!-- This fragment is used in sec. 5.2                        -->
]]>
</eg>


<!>

<div3 id=HD22><head>The Edition Statement</head>

<p>The <gi>editionStmt</gi> element is the second component of the
<gi>fileDesc</gi> element.  It is optional but recommended.
<list type=gloss>
<label><gi>editionStmt</gi></label>
<item>groups information relating to one edition of a text.</item>
</list>


It contains either phrases or more specialized elements identifying the
edition and those responsible for it:

<list type=gloss>
<label><gi>edition</gi></label>
<item>describes the particularities of one edition of a text.</item>
<label><gi>respStmt</gi></label>
<item>supplies a statement of responsibility for someone 
responsible for
the intellectual content of a text, 
edition, recording, or series, where
the specialized 
elements for authors, editors, etc. do
not suffice or do 
not apply.</item>
<label><gi>name</gi></label>
<item>contains a proper noun or noun phrase.</item>
<label><gi>resp</gi></label>
<item>contains a phrase describing the nature of a person's

intellectual responsibility.</item>
</list>


<p>For printed texts, the word <mentioned>edition</mentioned> applies to the set
of all the identical copies of an item produced from one master copy and
issued by a particular publishing agency or a group of such agencies.  A
change in the identity of the distributing body or bodies does not
normally constitute a change of edition, while a change in the master
copy does.

<p>For electronic texts, the notion of a <soCalled>master copy</soCalled> is not
entirely appropriate, since they are far more easily copied and modified
than printed ones; nonetheless the term <mentioned>edition</mentioned> may be used
for a particular state of a machine-readable text at which substantive
changes are made and fixed.  Synonymous terms used in these Guidelines
are <mentioned>version,</mentioned> <mentioned>level,</mentioned> and <mentioned>release</mentioned>.  The words
<mentioned>revision</mentioned> and <mentioned>update</mentioned>, by contrast, are used for minor
changes to a file which do not amount to a new edition.

<p>No simple rule can specify how <soCalled>substantive</soCalled>
changes have to be before they are regarded as producing a new edition,
rather than a simple update.  The general principle proposed here is
that the production of a new edition entails a significant change in the
intellectual content of the file, rather than its encoding or
appearance.  The addition of analytic coding to a text would thus
constitute a new edition, while automatic conversion from one coded
representation to another would not.  Changes relating to the character
code or physical storage details, corrections of misspellings, simple
changes in the arrangement of the contents and changes in the output
format do not normally constitute a new edition.  The addition of new
information (e.g. a linguistic analysis expressed in part-of-speech
tagging, sound or graphics, referential links to external datasets)
almost always does constitute a new edition.

<p>Clearly, there are always border line cases and the matter is
somewhat arbitrary.  The simplest rule is:  if you think that your file
is a new edition, then call it such.
An edition statement is optional for the first release of a
machine-readable file; it is mandatory for each later release,
though this requirement cannot be enforced by the SGML parser.

<p>Note that <emph>all</emph> changes in a file, whether or not they are
regarded as constituting a new edition or simply a new revision, should
be independently noted in the revision description section of the file
header (see section <ptr target=hd6>).
<!-- was target='p2.226' -->

<!-- drop this paragraph, move to a tutorial? -LB.            -->
<!-- Maybe. -MSM                                              -->
<!-- definitely! (LB)                                         -->
<!--                                                          -->
<!-- To avoid independent creation of multiple versions of    -->
<!-- a single source file, all called identically < q>second  -->
<!-- edition,< /q> it is recommended that < term>edition       -->
<!-- numbers< /term> be incremented only by the original      -->
<!-- creator of a computer file:  the person or body          -->
<!-- responsible for the first edition.  Others should        -->
<!-- either retain the base edition number and add a <        -->
<!-- q>revision< /q> or < q>update< /q> number only (as well  -->
<!-- as an appropriate statement of responsibility for the    -->
<!-- changes they have made), or else give their new          -->
<!-- edition a non-numeric name (< q>revised, corrected       -->
<!-- edition by N.N.< /q>) If someone other than the          -->
<!-- original creator makes substantial changes in the        -->
<!-- file, they may wish to regard the new version as a <     -->
<!-- q>derivative work< /q> (in a non-pejorative sense) and   -->
<!-- assign it a new title, beginning the edition numbering   -->
<!-- again from 1. In this case, the bibliographic            -->
<!-- description of the old edition may be embedded within    -->
<!-- the source description of the new file.  See section <   -->
<!-- xref target=hd4>.  was target='p2.224'                   -->

<p>The <gi>edition</gi> element should contain phrases describing the
edition or version, including the word <mentioned>edition</mentioned>,
<mentioned>version</mentioned>, or equivalent, together with a number or date,
or terms indicating difference from other editions such as <mentioned>new
edition</mentioned>, <mentioned>revised edition</mentioned> etc.  Any dates that
occur within the edition statement should be marked with the
<gi>date</gi> element.  The <att>n</att> attribute of the
<gi>edition</gi> element may be used as elsewhere to supply any formal
identification (such as a version number) for the edition.

<p>One or more <gi>respStmt</gi> elements may also be used to supply
statements of responsibility for the edition in question.  These may
refer to individuals or corporate bodies and can indicate functions such
as that of a reviser, or can name the person or body responsible for the
provision of supplementary matter, of appendices, etc., in a new
edition.  For further detail on the <gi>respStmt</gi> element, see section
<ptr target=CObi>.

<p>Some examples follow:

<eg><![ CDATA[
<editionStmt>
  <edition n='P2'>Second draft, substantially
       extended, revised, and corrected.</edition>
</editionStmt>
]]>
</eg>

<eg><![ CDATA[
<editionStmt>
<edition>Student's edition, <date>June 1987</date></edition>
<respStmt>
  <resp>New annotations by</resp> <name>George Brown</name>
</respStmt>
</editionStmt>
]]>
</eg>

The formal definition of the <gi>editionStmt</gi> element is as follows:

<eg id=d2222>
<![ CDATA [
<!-- 5.2.2:  The edition statement                            -->
<!ELEMENT editionStmt   - o  ( (edition, respStmt*) | p+ )      >
<!ATTLIST editionStmt        %a.global;                         >
<!ELEMENT edition       - o  (%phrase.seq;)                     >
<!ATTLIST edition            %a.global;                         >
<!-- This fragment is used in sec. 5.2                        -->
]]>
</eg>


<div3 id=HD23><head>Type and Extent of File</head>

<p>The <gi>extent</gi> element is the third component of the
<gi>fileDesc</gi> element.  It is optional.
<list type=gloss>
<label><gi>extent</gi></label>
<item>describes the approximate size of the electronic text as 
stored on
some carrier medium, specified in any convenient 
units.</item>
</list>


<p>For printed books, information about the carrier, such as the kind of
medium used and its size, are of great importance in cataloguing
procedures.  The print-oriented rules for bibliographic description of
an item's medium and extent need some re-interpretation when applied to
electronic media.  An electronic file exists as a distinct entity quite
independently of its carrier and remains the same intellectual object
<!-- same intell. object, but not nec. same bibliographic item -->
whether it is stored on a magnetic tape, a CD-ROM, a set of floppy disks
or as a file on a mainframe computer.  Since, moreover, these Guidelines
are specifically aimed at facilitating transparent document storage and
interchange, any purely machine-dependent information should be
irrelevant as far as the file header is concerned.

<p>This is particularly true of information about <term>file-type</term>
although library-oriented rules for cataloguing often distinguish two
types of computer file:  <q>data</q> and <q>programs</q>.  This
distinction is quite difficult to draw in some cases, for example,
hypermedia or texts with built in search and retrieval software.
However, since all files covered by these Guidelines are of the same
kind, SGML representations, it is unnecessary to specify the file type
separately.

<!-- commented this out:  SGML tries to make graphics         -->
<!-- linkage system-independent, so this sounds like          -->
<!-- confession of an Achilles heel.  -MSM  OK -LB            -->
<!>
<!-- When non-textual data (for example, encoded graphics or  -->
<!-- sounds) are included with a TEI text, this will          -->
<!-- necessarily be done in a highly system-dependent manner, -->
<!-- and is therefore not recommended for inclusion in the    -->
<!-- TEI-header.                                              -->

<p>Although it is equally system-dependent, some measure of the size of
the computer file may be of use for cataloguing and other practical
purposes.  Because the measurement and expression of file size is
fraught with difficulties, only very general recommendations are
possible; the element <gi>extent</gi> is provided for this purpose.  It
contains a phrase indicating the size or approximate size of the
computer file in one of the following ways:

<list type=bullets>
<item>in bytes of a specified length (e.g. <q>4000 16-bit bytes</q>)
<item>as falling within a range of categories, for example:
<list type=bullets>
<item>less than 1 Mb
<item>between 1 Mb and 5 Mb
<item>between 6 Mb and 10 Mb
<item>over 10 Mb
</list>
<item>in terms of any convenient logical units (for example,
words or sentences, citations, paragraphs)
<item>in terms of any convenient physical units (for example,
blocks, disks, tapes)
</list>

<p>Examples:

<eg><![ CDATA [
<extent>between 1 16-bit Mb and 2 16-bit Mb</extent>
<extent>4532 bytes</extent>
<extent>3200 sentences</extent>
<extent>5 3.5" High Density Diskettes</extent>
]]>
</eg>

The <gi>extent</gi> element has the following formal declaration:
<eg id=d2223>
<![ CDATA [
<!-- 5.2.3:  The extent statement                             -->
<!ELEMENT extent        - o  (%phrase.seq; )                    >
<!ATTLIST extent             %a.global;                         >
<!-- This fragment is used in sec. 5.2                        -->
]]>
</eg>

<!>

<div3 id=HD24><head>Publication, Distribution, etc.</head>

<!-- Tags defined:  publicationStmt, publisher, distributor,  -->
<!-- authority, city, address, idno, availability.            -->
<!-- Tags described:  date.                                   -->

<p>The <gi>publicationStmt</gi> element is the fourth component of the
<gi>fileDesc</gi> element and is mandatory.

<list type=gloss>
<label><gi>publicationStmt</gi></label>
<item>groups information concerning the publication or 
distribution
of an electronic or other text. </item>
</list>


It may contain either a simple prose description, or groups of the
elements described below:

<list type=gloss>
<label><gi>publisher</gi></label>
<item>provides the name of the organization responsible for
the 
publication or distribution of a bibliographic item.</item>
<label><gi>distributor</gi></label>
<item>supplies the name of a person or other agency responsible 
for the
distribution of a text.</item>
<label><gi>authority</gi></label>
<item>supplies the name of a person or other agency responsible 
for
making an electronic file available, other than a 
publisher or
distributor.</item>
</list>


<p>The <term>publisher</term> is the person or institution by whose
authority a given edition of the file is made public.  The
<term>distributor</term> is the person or institution from whom copies
of the text may be obtained.  Where a text is not considered formally
published, but is nevertheless made available for circulation by some
individual or organization, this person or institution is termed the
<term>release authority</term>.

<p>At least one of these three elements must be present, unless the
entire publication statement is given as prose.  Each may be followed by
one or more of the following elements, in the following order:

<list type=gloss>
<label><gi>pubPlace</gi></label>
<item>contains the name of the place where a bibliographic item 
was
published.</item>
<label><gi>address</gi></label>
<item>contains a postal or other address, for example of a

publisher, an organization, or an individual.</item>
<label><gi>idno</gi></label>
<item>supplies any standard or non-standard number used to 
identify a
bibliographic item.
Attributes include:
<list type=gloss>
<label><att>type</att></label>
<item>categorizes the number, for example as an ISBN or other 
standard series.</item>
</list>
</item>
<label><gi>availability</gi></label>
<item>supplies information about the availability of a text, for

example any restrictions on its use or distribution, its 
copyright
status, etc.
Attributes include:
<list type=gloss>
<label><att>status</att></label>
<item>supplies a code identifying the current availability of the 
text.
Sample values include:
<list type=gloss>
<label><term>restricted</term></label>
<item>the text is not freely available.</item>
<label><term>unknown</term></label>
<item>the status of the text is unknown.</item>
<label><term>free</term></label>
<item>the text is freely available.</item>
</list></item>
</list>
</item>
<label><gi>date</gi></label>
<item>contains a date in any format.</item>
</list>


<p>Note that the dates, places, etc., given in the publication statement
relate to the publisher, distributor, or release authority most recently
mentioned.  If the text was created at some date other than its date of
publication, its date of creation should be given within the
<gi>profileDesc</gi> element, not in the publication statement.  Give
any other useful dates (e.g., dates of collection of data) in a note.

<p>Additional detailed tagsets may be used for the encoding of names,
dates and addresses, as further described in section <ptr target=COna>
and chapter <ptr target=ND>.

<p>Examples:

<eg><![ CDATA[
<publicationStmt>
     <publisher>Oxford University Press</publisher>
     <pubPlace>Oxford</pubPlace> <date>1989</date>
     <idno type=ISBN>0-19-254705-4</idno>
     <availability><p>Copyright 1989, Oxford University Press
     </availability>
</publicationStmt>
]]>
</eg>

<eg><![ CDATA [
<publicationStmt>
    <authority>James D. Benson</authority>
    <pubPlace>London</pubPlace> <date>1984</date>
</publicationStmt>
]]>
</eg>
<eg><![ CDATA[
<publicationStmt>
     <publisher>Sigma Press</publisher>
     <date>1991</date>
     <address>
        <addrLine>21 High Street,</addrLine>
        <addrLine>Wilmslow,</addrLine>
        <addrLine>Cheshire M24 3DF</addrLine>
     </address>
     <distributor>Oxford Text Archive</distributor>
     <idno type='ota'>1256
     <availability><p>Available with prior consent of depositor for
        purposes of academic research and teaching only.
</publicationStmt>
]]>
</eg>

<p>The publication statement and its components are formally defined as
follows:

<eg id=d2224>
<![ CDATA [
<!-- 5.2.4:  The publication statement                        -->
<!ELEMENT publicationStmt 
                        - o  (p+ | (publisher | distributor | 
                             authority | pubPlace | address | 
                             idno | availability | date)+ )     >
<!ATTLIST publicationStmt    %a.global;                         >
<!ELEMENT distributor   - o  (%phrase.seq;)                     >
<!ATTLIST distributor        %a.global;                         >
<!ELEMENT authority     - o  (%phrase.seq;)                     >
<!ATTLIST authority          %a.global;                         >
<!ELEMENT idno          - o  (#PCDATA)                          >
<!ATTLIST idno               %a.global;
          type               CDATA               #IMPLIED       >
<!ELEMENT availability  - o  (p*)                               >
<!ATTLIST availability       %a.global;
          status             (free | unknown | restricted) 
                                                 #IMPLIED       >
<!-- The PUBLISHER, PUBPLACE, and ADDRESS elements are        -->
<!-- defined in file teicore2.dtd.                            -->

<!-- This fragment is used in sec. 5.2                        -->
]]>
</eg>


<!>

<div3 id=HD26><head>The Series Statement</head>

<p>The <gi>seriesStmt</gi> element is the fifth component of the
<gi>fileDesc</gi> element and is optional.

<list type=gloss>
<label><gi>seriesStmt</gi></label>
<item>groups information about the <term>series</term>, if any, 
to which
a publication belongs.</item>
</list>


<p>In bibliographic parlance, a <term>series</term> may be defined in
one of the following ways:

<list type=bullets>
<item>A group of separate items related to one another by the fact
that each item bears, in addition to its own title proper, a
collective title applying to the group as a whole.  The
individual items may or may not be numbered.
<item>Each of two or more volumes of essays, lectures, articles,
or other items, similar in character and issued in sequence.
<item>A separately numbered sequence of volumes within a series or
serial.
</list>

The <gi>seriesStmt</gi> element may contain a prose description or one
or more of the following more specific elements:

<list type=gloss>
<label><gi>title</gi></label>
<item>contains the title of a work, whether article, book, 
journal, or
series, including any alternative titles or 
subtitles.</item>
<label><gi>idno</gi></label>
<item>supplies any standard or non-standard number used to 
identify a
bibliographic item.</item>
<label><gi>respStmt</gi></label>
<item>supplies a statement of responsibility for someone 
responsible for
the intellectual content of a text, 
edition, recording, or series, where
the specialized 
elements for authors, editors, etc. do
not suffice or do 
not apply.</item>
<label><gi>resp</gi></label>
<item>contains a phrase describing the nature of a person's

intellectual responsibility.</item>
<label><gi>name</gi></label>
<item>contains a proper noun or noun phrase.</item>
</list>


<p>The <gi>idno</gi> may be used to supply any identifying number
associated with the item, including both standard numbers such as an
ISSN and particular issue numbers.<note>Arabic numerals separated by
punctuation are recommended for this purpose (e.g., 6.19.33, not
VI/xix:33).</note> Its <att>type</att> attribute is used to categorize
the number further, taking the value <code type=value>ISSN</code> for an ISSN for
example.

<p>Examples:

<eg><![ CDATA[
<seriesStmt>
    <title level="S">Machine-Readable Texts for the Study of
    Indian Literature</title>
    <respStmt>
         <resp>ed. by</resp> <name>Jan Gonda</name>
     </respStmt>
     <idno type="vol">1.2</idno>
     <idno type ='ISSN'>0 345 6789</idno>
</seriesStmt>
]]>
</eg>

The series statement has the following formal definition:

<eg id=d2225>
<![ CDATA [
<!-- 5.2.5:  The series statement                             -->
<!ELEMENT seriesStmt    - O  ( (title, (idno | respStmt)*) | p+ 
                             )                                  >
<!ATTLIST seriesStmt         %a.global;                         >
<!-- This fragment is used in sec. 5.2                        -->
]]>
</eg>


Its components are all defined elsewhere.
<!>

<div3 id=HD27><head>The Notes Statement</head>

<p>The <gi>notesStmt</gi> element is the sixth component of the
<gi>fileDesc</gi> element and is optional.  If used, it contains one or
more <gi>note</gi> elements, each containing a single piece of
descriptive information of the kind treated as <soCalled>general
notes</soCalled> in traditional bibliographic descriptions.

<list type=gloss>
<label><gi>notesStmt</gi></label>
<item>collects together any notes providing information about a 
text
additional to that recorded in other parts of the 
bibliographic
description.</item>
<label><gi>note</gi></label>
<item>contains a note or annotation.</item>
</list>


<p>Some information found in the notes area in conventional bibliography
has been assigned specific elements in these Guidelines; in particular
the following items should be tagged as indicated, rather than as
general notes:

<list type=bullets>
<item>
the nature, scope, artistic form or purpose of the file; also
the genre or other intellectual category to which it may belong:
e.g. <q>Text types:  newspaper editorials and reportage, science
fiction, westerns, and detective stories</q>. These should be
formally described within the <gi>profileDesc</gi> element
(section <ptr target=hd4>).
<!-- was target='p2.224'>) -->
<item>summary description providing a factual, non-evaluative
account of the subject content of the file.  E.g. <q>Transcribes
interviews on general topics with native speakers of English in
17 cities during the spring and summer of 1963.</q> These should
also be formally described within the <gi>profileDesc</gi> element
(section <ptr target=hd4>).
<!-- was target='p2.224'>) -->
<item>bibliographic details relating to the source or sources of
an electronic text: e.g. <q>Transcribed from the Norton
facsimile of the 1623 Folio</q>. These should be formally
described in the <gi>sourceDesc</gi> element
(section <ptr target=hd3>).
<!-- was target='p2.223'>). -->
<item>further information relating to publication, distribution
or release of the text, including sources from which the text
may be obtained, any restrictions on its use or formal terms on
its availability.  These should be placed in the appropriate
division of the <gi>publicationStmt</gi> element
(section <ptr target=hd24>).
<!-- was target='p2.2224'>). -->
<item>publicly documented numbers associated with the file:  e.g.
<q>ICPSR study number 1803</q> or <q>Oxford Text Archive text
number 1243</q>.  These should be placed in an <gi>idno</gi>
element within the appropriate division of the
<gi>publicationStmt</gi> element.  International Standard
Serial Numbers (ISSN), International Standard Book Numbers
(ISBN), and other internationally agreed upon standard numbers
that uniquely identify an item, should be treated in the same
way, rather than as specialized bibliographic notes.
</list>

<p>Nevertheless, the <gi>notesStmt</gi> element may be used to record
potentially significant details about the file and its features, e.g.:

<list type=bullets>
<item>dates, when they are relevant to the content or condition of the
computer file:  e.g.  <q>manual dated 1983,</q> <q>Interview wave I:
Apr. 1989; wave II: Jan. 1990</q>
<item>names of persons or bodies connected with the technical production,
administration or consulting functions of the effort which produced
the file, if these are not named in statements of responsibility in
the title or edition statements of the file description:
e.g. <q>Historical commentary provided by Mark Cohen</q>
<item>availability of the file in an additional medium or information not
already recorded about the availability of documentation:
e.g. <q>User manual is loose-leaf in eleven paginated sections</q>
<item>language of work and abstract:  e.g. <q>Text in English with
summaries in French and German</q>
<item>The unique name assigned to a serial by the International Serials
Data System (ISDS)
<item>lists of related publications, either describing the source itself,
or concerned with the creation or use of the machine-readable file, e.g.
<q>Texts used in <bibl><title>Computation into Criticism</title>
(Oxford, 1987)</bibl></q>
</list>

<p>Each such item of information should be tagged using the
general-purpose <gi>note</gi> element, which is described in section
<ptr target=COno>.  Groups of notes are contained within the
<gi>notesStmt</gi> element, as in the following example:
<eg>
<![ CDATA[
<notesStmt>
  <note>Historical commentary provided by Mark Cohen.</note>
  <note>OCR scanning done at University of Toronto.</note>
</notesStmt>
]]>
</eg>
The notes statement has the following formal definition:

<eg id=d2226>
<![ CDATA [
<!-- 5.2.6:  The notes statement                              -->
<!ELEMENT notesStmt     - o  (note+)                            >
<!ATTLIST notesStmt          %a.global;                         >
<!-- The NOTE element is defined with the core tags.          -->

<!-- This fragment is used in sec. 5.2                        -->
]]>
</eg>



<!-- $Id: p2hd3.odd,v 1.7 1994/04/01 16:23:58 msmcq Exp $ -->
<!-- $Log: p2hd3.odd,v $
# Revision 1.7  1994/04/01  16:23:58  msmcq
# Misc. changes/fixes while validating DTDs
#
# Revision 1.6  1994/03/24  22:14:56  msmcq
# typo corrections from David Barnard, Peter Robinson, and others
#
# Revision 1.5  1994/01/04  13:02:03  lou
# fix examples
#
# Revision 1.3  1993/08/18  21:31:24  msmcq
# name shift (role/resp, resp/respStmt) on account of DR role
#
# Revision 1.2  1993/06/22  14:29:49  msmcq
# Changes post Eynsham and for DTD generation
# -->
<!-- Revisions:                                               -->
<!-- 94-03-29 : MSM : explicitly embed d2231                  -->
<!-- 94-03-29 : MSM : suppress supererogatory file att on dtdfrags -->
<!-- 94-03-24 : CMSMcQ : one more typo                        -->
<!-- 94-03-22 : CMSMcQ : typos, TEI - &tei, code, ident tags  -->
<!--                     notes from DB                        -->
<!-- 93-08-18 : MSM : new names for respStmt, role/resp       -->
<!-- 93-06-02 : MSM : rename listbibl from bibllist           -->
<!-- 93-06-01 : MSM : normalize citn, teihead, xrefs to ah    -->
<!-- 93-02-10 : MSM : update xref targets                     -->
<!-- 92-08-18 : MSM : some points of style and detail         -->
<!-- 92-08-14 : MSM : revisions, restore recording stmt       -->
<!-- 1 aug 92: LB: some juggling with ids and ordering        -->
<!--     also, gritted teeth and moved recording and script stmts -->
<!--     to aux header. You can explain to Stig!              -->
<!-- 26 Jul 92 : MSM : very light revision, almost nothing    -->
<!--                   except in 22.3.2 (reordering)          -->
<!-- 25 Jul 92 : MSM : names updated, ids updated             -->

<div3 id='hd3'><head>The Source Description</head>

<!-- was div2: demoted for consistency with structure of dtd (LB) -->
<!--   (maybe its id should change too ; left as is for now )     -->

<p>The <gi>sourceDesc</gi> element is the seventh and final component of
the <gi>fileDesc</gi> element.  It is a mandatory element, and is used to
record details of the source or sources from which a computer file is
derived.  This might be a printed text or manuscript, another computer
file, an audio or video recording of some kind, or a combination of
these.  An electronic file may also have no source, if what is being
catalogued is an original text created in electronic form.
<list type=gloss>
<label><gi>sourceDesc</gi></label>
<item>supplies a bibliographic description of the copy text(s) 
from
which an electronic text was derived or generated.</item>
</list>


<p>The <gi>sourceDesc</gi> element may contain a simple prose
description, or, more usefully, a bibliographic citation of some kind
specifying the provenance of the text.  For written or printed sources,
the source should be described in the same way as any other
bibliographic citation, using one of the following elements:

<list type=gloss>
<label><gi>bibl</gi></label>
<item>contains a loosely-structured bibliographic citation of 
which
the sub-components may or may not be explicitly 
tagged. </item>
<label><gi>biblStruct</gi></label>
<item>contains a structured bibliographic citation, in which only
bibliographic subelements appear and in a specified order. </item>
<label><gi>biblFull</gi></label>
<item>contains a fully-structured bibliographic citation, in 
which all
components of the TEI file description
are 
present.
<!-- except maybe the source.desc? --></item>
<label><gi>listBibl</gi></label>
<item>contains a list of bibliographic citations of any kind. </item>
</list>


These elements are described in more detail in section
<ptr target=CObi>.
<!-- or:  target=CObibl>. -->
<p>
When the header describes a transcription of spoken material, the
<gi>sourceDesc</gi> element may also include the following
special-purpose elements, intended for cases where an electronic text
is derived from a spoken text rather than a written one:
<list type=gloss>
<label><gi>scriptStmt</gi></label>
<item>contains a citation giving details of the script used for

a spoken text.</item>
<label><gi>recordingStmt</gi></label>
<item>describes a set of recordings used in transcription of a

spoken text.</item>
</list>

Full descriptions of these elements and their contents are given in
section <ptr target=HD32>.
<p>
The <gi>sourceDesc</gi> element may contain a mixture of one or more
of the above elements, as in the following examples:

<eg><![ CDATA[
<sourceDesc>
   <bibl>The first folio of Shakespeare, prepared by
   Charlton Hinman (The Norton Facsimile, 1968)</bibl>
</sourceDesc>
]]>
</eg>
<eg><![ CDATA[
<sourceDesc>
   <p>No source: created in machine-readable form.</p>
</sourceDesc>
]]>
</eg>
<eg><![ CDATA[
<sourceDesc>
   <biblStruct lang=FR>
   <monogr>
    <author>Eug&egrave;ne Sue</>
    <title>Martin, l'enfant trouv&eacute;</>
    <title type=sub>M&eacute;moires d'un valet de chambre</>
    <imprint>
         <pubPlace>Bruxelles et Leipzig</>
         <publisher>C. Muquardt</>
         <date>1846</>
    </imprint>
   </monogr></biblStruct>
</sourceDesc>
]]>
</eg>

<p>The source description itself has the following formal definition:
<eg id=d223>
<![ CDATA [
<!-- 5.2.7:  The source description                           -->
<!ELEMENT sourceDesc    - -  (p | bibl | biblFull | biblStruct 
                             | listBibl | scriptStmt | 
                             recordingStmt)+                    >
<!ATTLIST sourceDesc         %a.global;
                             %a.declarable;                     >
<!-- ... declarations from section 5.2.9                      -->
<!--     (Script statement and recording statement)           -->
<!--     go here ...                                          -->
<!-- This fragment is used in sec. 5.1.1                      -->
]]>
</eg>


<div3 id='hd31'><head>Computer Files Derived from Other Computer Files

<p>If a machine-readable text (call it B) is based not on a
printed source but upon another machine-readable text (call it
A) which includes a TEI file header, then the source text of
computer file B is another computer file, A.  The four sections
of A's file header will need to be incorporated into the new
header for B in slightly differing ways, as listed below:

<list type=gloss>

<label>fileDesc
<item>A's file description should be copied into the
<gi>sourceDesc</gi> section of B's file description, enclosed
within a <gi>biblFull</gi> element
(see section <ptr target=CObi>).
<!-- was:  target='p2.235'>). -->
<!-- was:  target='CObibl'>). -->

<label>profileDesc<item>A's <gi>profileDesc</gi> should be
copied into B's, in principle unchanged.

<label>encodingDesc
<item>A's coding practice may or (more likely) may not be the
same as B's. Since the object of the coding description is to
define the relationship between the current file and its source,
in principle only changes in encoding practice between A and B
need be documented in B. The relationship between A and its
source(s) is then only recoverable from the original header of
A. In practice it may be more convenient to create a new
complete <gi>encodingDesc</gi> for B based on A's.

<label>revisionDesc
<item>B is a new electronic file, and should therefore have a
new revision description. If, however, it is felt useful to
include some information from A's <gi>revisionDesc</gi>, for
example dates of major updates or versions, such information
must be clearly marked as relating to A rather than to B.

</list>

<div3 id='hd32'><head>Computer Files Composed of Transcribed Speech

<p>Where an electronic text is derived from a spoken text rather than a
written one, it will usually be desirable to record additional
information about the recording or broadcast which constitutes its
source.  Several additional elements are provided for this purpose
within the source description element:

<list type=gloss>
<label><gi>scriptStmt</gi></label>
<item>contains a citation giving details of the script used for

a spoken text.</item>
<label><gi>recordingStmt</gi></label>
<item>describes a set of recordings used in transcription of a

spoken text.</item>
<label><gi>recording</gi></label>
<item>details of an audio or video recording event
used as the 
source of a spoken text, either directly or from
a public 
broadcast. 
Attributes include:
<list type=gloss>
<label><att>type</att></label>
<item>the kind of recording.
Legal values are:
<list type=gloss>
<label><term>video</term></label>
<item>audio and video recording</item>
<label><term>audio</term></label>
<item>audio recording</item>
</list></item>
<label><att>dur</att></label>
<item>the original duration of the recording.</item>
</list>
</item>
<label><gi>equipment</gi></label>
<item>provides technical details of the equipment and media used 
for
an audio or video recording used as the source for a 
spoken text.</item>
<label><gi>broadcast</gi></label>
<item>describes a broadcast used as the source of a spoken text.</item>
</list>


<p>Note that detailed information about the participants or setting of
an interview or other transcript of spoken language should be recorded
in the appropriate division of the profile description, discussed in
chapter <ptr target='CC'>, rather than as part of the source
description.  The source description is used to hold information only
about the source from which the transcribed speech was taken, for
example, any script being read and any technical details of how the
recording was  produced.  If the source was a previously-created
transcript, it should be treated in the same way as any other source
text.

<p>The <gi>scriptStmt</gi> element should be used where it is known that
one or more of the participants in a spoken text is speaking from a
previously prepared script.  The script itself should be documented in
the same way as any other written text, using one of the three citation
tags mentioned above.  Utterances or groups of utterances may be linked
to the script concerned by means of the <att>decls</att> attribute,
described in section <ptr target=CCas>.
<!-- was:  target='p2.3431'>. -->
<!-- or :  target='sp31'>. -->

<eg><![ CDATA[
<sourceDesc>
  <scriptStmt id=CNN12>
  <bibl><author>CNN Network News</>
     <title>News headlines</>
     <date>12 Jun 1991</>
  </bibl>
  </scriptStmt>
  <!-- this script statement might be used to document
       the parts of a spoken transcript which included
       a news broadcast -->
  <!-- possibly other script statements or recording
       statements follow -->
</sourceDesc>
]]>
</eg>

<p>The <gi>recordingStmt</gi> is used to group together information
relating to the recordings from which the spoken text was transcribed.
The element may contain either a prose description or, more helpfully,
one or more <gi>recording</gi> elements, each corresponding with a
particular recording.  The linkage between utterances or groups of
utterances and the relevant recording statement is made by means of the
<att>decls</att> attribute, described in section <ptr target=CCas>.
<!-- was:  target=p2.3431>. -->
<!-- was:  target=sp31>. -->

<p>The <gi>recording</gi> element should be used to provide a
description of how and by whom a recording was made.  This information
may be a prose description, within which such items as statements of
responsibility, names, places and dates should be identified using the
appropriate phrase level tags.  The <gi>recording</gi> element takes two
additional attributes, as indicated above:  <att>type</att> is used to
specify the kind of recording concerned and <att>dur</att> to specify
its length.

<p>In addition, descriptive information relating to the kind of
recording equipment used should be specified using the
<gi>equipment</gi> element.  Where a recording is taken from a public
broadcast, details of the broadcast should be given using the
<gi>broadcast</gi> element described further below.  Specialized
collections may wish to add further sub-elements to these major
components.  Note however that this element should be used only for
information relating to the recording process itself; information about
the setting or participants (for example) is recorded elsewhere:  see
sections <ptr target=CCahse> and <ptr target=CCahpa> below.
<!-- was:  xref target=hd44 and xref target=hd45 -->

<eg><![ CDATA[
  <recording type=video>
  <p>U-matic recording made by college audio-visual
    department staff,available as PAL-standard VHS
    transfer or sound-only casssette
  </recording>
]]>
</eg>

<eg><![ CDATA[
  <recording type=audio dur="30 mins">
  <respStmt>
     <resp>Location recording by</resp>
     <name>Sound Services Ltd.</name>
  </respStmt>
  <equipment>
     <p>Multiple close microphones mixed down to stereo Digital
     Audio Tape, standard play, 44.1 KHz sampling frequency
  </equipment>
  <date>12 Jan 1987</date>
  </recording>
]]>
</eg>

<p>When a recording has been made from a public broadcast, details of
the broadcast itself should be supplied within the <gi>recording</gi>
element, as a nested <gi>broadcast</gi> element.  A broadcast is closely
analogous to a publication and the <gi>broadcast</gi> element should
therefore contain one or the other of the bibliographic citation
elements <gi>bibl</gi>, <gi>biblStruct</gi> or <gi>biblFull</gi>.  The
broadcasting agency responsible for a broadcast is regarded as its
author, while other participants (for example interviewers,
interviewees, directors, producers, etc.) should be specified using the
<gi>respStmt</gi> or <gi>editor</gi> element with an appropriate
<gi>resp</gi> (see further section <ptr target=CObi>).
<!-- was:  target='p2.235'>). -->
<!-- was:  target=cobibl>). -->

<eg><![ CDATA[
<recording type=audio dur="10 mins">
  <equipment><p>Recorded from FM Radio to digital tape</>
  <broadcast>
     <bibl><title>Interview on foreign policy</>
              <author>BBC Radio 5</>
       <respStmt><resp>interviewer</><name>Robin Day</></>
       <respStmt><resp>interviewee</><name>Margaret Thatcher</></>
       <series><title>The World Tonight</></>
       <note>First broadcast on <date>27 Nov 1989</></note>
    </bibl>
  </broadcast>
</recording>
]]>
</eg>

<p>When a broadcast contains several distinct recordings (for example a
compilation), additional <gi>recording</gi> elements may be further
nested within the <gi>broadcast</gi> element.

<eg><![ CDATA[
    <recording dur=100>
       <broadcast>
         <!-- details of broadcast -->
         <recording>
            <!-- details of broadcast recording -->
         </recording>
      </broadcast>
   </recording>
]]>
</eg>
<!-- need a real example here -->
<!-- damn straight.  -msm     -->

<p>Formal definitions for the elements discussed in this section are as
follows:
<eg id=d2231>
<![ CDATA [
<!-- 5.2.9:  Script statement and recording statement         -->
<!ELEMENT scriptStmt    - -  (p+ | bibl | biblFull | 
                             biblStruct)                        >
<!ATTLIST scriptStmt         %a.global;
                             %a.declarable;                     >
<!ELEMENT recordingStmt - -  (p+ | recording+ )                 >
<!ATTLIST recordingStmt      %a.global;                         >
<!ELEMENT recording     - -  (p+ | (respStmt | equipment | 
                             broadcast | date)*)                >
<!ATTLIST recording          %a.global;
                             %a.declarable;
          dur                CDATA               #IMPLIED
          type               (audio | video)     audio          >
<!ELEMENT equipment     - o  (p+)                               >
<!ATTLIST equipment          %a.global;
                             %a.declarable;                     >
<!ELEMENT broadcast     - -  (p+ | bibl | biblStruct | biblFull 
                             | recording)                       >
<!ATTLIST broadcast          %a.global;
                             %a.declarable;                     >
<!-- This fragment is used in sec. 5.2.7                      -->
]]>
</eg>

<p>This concludes the discussion of the <gi>fileDesc</gi> element and
its contents.

<!-- &p2.hd4; &p2.hd5; -->
<!-- swopped these two around as per Chicago meeting  -->
<!-- (also needed extensive changes to text and dtd)  -->
<!-- but left ids unchanged for now  -->
<!-- $Id: p2hd5.odd,v 1.10 1998/01/31 19:50:52 tei Exp $ -->
<!--*
    * $Log: p2hd5.odd,v $
    * Revision 1.10  1998/01/31 19:50:52  tei
    * Change system 'tei2.dtd' to public identifier
    * fix log keyword (if not already fixed)
    * normalize the sgml
    *
    * Revision 1.9  98/01/28  11:09:58  cmsmcq
    * LB changes of January 1998
    *
    * Revision 1.8  1994/04/01  16:23:58  msmcq
    * Misc. changes/fixes while validating DTDs
    *
    * Revision 1.7  1994/03/24  22:14:56  msmcq
    * typo corrections from David Barnard, Peter Robinson, and others
    *
    * Revision 1.6  1994/01/28  18:04:57  lou
    * add fsdDecl and metDecl
    *
    * Revision 1.2  1993/06/22  14:29:49  msmcq
    * Changes post Eynsham and for DTD generation
    * -->
<!-- Revisions:                                               -->
<!-- 10 jan 98 : LB : fixing egs -->
<!-- 4 Jan 98 : LB : changed wsd to fsd in eg -->
<!-- 94-03-29 : MSM : suppress supererogatory file att on dtdfrags -->
<!-- 94-03-29 : MSM : add varencod                            -->
<!-- 94-03-24 : CMSMcQ : more typos, from Peter R             -->
<!-- 94-03-22 : CMSMcQ : typos, TEI - &tei, code, ident tags  -->
<!-- 22 jan 94 : LB : add metdecl and fsdDecl -->
<!-- 9 jan : LB: samplingDecl, not Desc -->
<!-- 28 dec 93: LB: INTERP changed to INTERPTN  -->
<!-- 93-06-21 : MSM : change file id on dtdfrags              -->
<!-- 93-06-01 : MSM : add dtdfrag for tagsdecl                -->
<!-- 93-06-01 : MSM : add tagsDecl section (from LB)          -->
<!--                  add example of samplingDecl to show     -->
<!--                  documentation of systematic omissions   -->
<!-- 93-06-01 : MSM : misc normalizations                     -->
<!-- 93-02-10 : MSM : update xref targets                     -->
<!-- 92-08-19 : MSM : Change straggling refs to ANALYSIS      -->
<!-- 92-08-18 : MSM : revisions as per LB talk                -->
<!-- 92-08-18 : MSM : change -isa- -ise- to -iza- -ize-       -->
<!-- 92-08-17 : MSM : Change ANALYSIS to INTERP               -->
<!-- 92-08-14 : MSM : revisions, clarifications               -->
<!-- 2 Aug 92: further revisions for consistency (LB) -->
<!-- 25 Jul 92 : MSM : names updated, ids updated             -->

<div2 id="hd5"><head>The Encoding Description</head>

<p>The <gi>encodingDesc</gi> element is the second major subdivision of
the TEI header.  It specifies the methods and editorial principles which
governed the transcription or encoding of the text in hand and may also
include sets of coded definitions used by other components of the
header.  Though not formally required, its use is highly recommended.
<list type=gloss>
<label><gi>encodingDesc</gi></label>
<item>documents the relationship between an electronic text and 
the
source or sources from which it was derived.</item>
</list>

The content of the encoding description may be a prose description, or
it may contain elements from the following list, in the order given:
<list type=gloss>
<label><gi>projectDesc</gi></label>
<item>describes in detail the aim or purpose for which an 
electronic
file was encoded, together with any other 
relevant information
concerning the process by which it 
was assembled or collected.</item>
<label><gi>samplingDecl</gi></label>
<item>contains a prose description of the rationale and methods 
used
in sampling texts in the creation of a corpus or 
collection.</item>
<label><gi>editorialDecl</gi></label>
<item>provides details of editorial principles and practices 
applied
during the encoding of a text.</item>
<label><gi>tagsDecl</gi></label>
<item>provides detailed information about the tagging applied to

an SGML document. </item>
<label><gi>refsDecl</gi></label>
<item>specifies how canonical references are constructed for this 
text.</item>
<label><gi>classDecl</gi></label>
<item>contains one or more taxonomies defining any classificatory
codes used elsewhere in the text.</item>
<label><gi>fsdDecl</gi></label>
<item>identifies the feature system declaration which contains

definitions for a particular type of feature structure.</item>
<label><gi>metDecl</gi></label>
<item>documents the notation employed to represent a metrical 
pattern
when this is specified as the value of a 
<att>met</att>,
<att>real</att>, or <att>rhyme</att> 
attribute on any structural element
of a metrical text 
(e.g.  <gi>lg</gi>, <gi>l</gi>, or
<gi>seg</gi>).</item>
<label><gi>variantEncoding</gi></label>
<item>declares the method used to encode text-critical variants.</item>
</list>


Each of these elements is further described and formally defined
in the appropriate section below. The encoding description itself
is defined as follows:

<eg id=d225>
<![ CDATA [
<!-- 5.3:  The encoding description                           -->
<!ELEMENT encodingDesc  - -  (projectDesc*, samplingDecl*, 
                             editorialDecl*, tagsDecl?, 
                             refsDecl*, classDecl*, metDecl*, 
                             fsdDecl*, variantEncoding*, p*)    >
<!ATTLIST encodingDesc       %a.global;                         >
<!-- ... declarations from section 5.3.1                      -->
<!--     (The project description)                            -->
<!--     go here ...                                          -->
<!-- ... declarations from section 5.3.2                      -->
<!--     (The sampling declaration)                           -->
<!--     go here ...                                          -->
<!-- ... declarations from section 5.3.3                      -->
<!--     (The editorial practices declaration)                -->
<!--     go here ...                                          -->
<!-- ... declarations from section 5.3.4                      -->
<!--     (Tag usage and rendition declarations)               -->
<!--     go here ...                                          -->
<!-- ... declarations from section 5.3.5.3                    -->
<!--     (The reference scheme declaration)                   -->
<!--     go here ...                                          -->
<!-- ... declarations from section 5.3.6                      -->
<!--     (The classification declaration)                     -->
<!--     go here ...                                          -->
<!-- ... declarations from section 5.3.7                      -->
<!--     (The FSD declaration)                                -->
<!--     go here ...                                          -->
<!-- ... declarations from section 5.3.8                      -->
<!--     (Metrical Notation Declaration)                      -->
<!--     go here ...                                          -->
<!-- ... declarations from section 5.3.9                      -->
<!--     (Variant-Encoding Declaration)                       -->
<!--     go here ...                                          -->
<!-- This fragment is used in sec. 5.1.1                      -->
]]>
</eg>
</p>

<div3 id="hd51"><head>The Project Description</head>

<p>The <gi>projectDesc</gi> element is the first of the nine optional
subdivisions of the <gi>encodingDesc</gi> element.  It may be used to
describe, in prose, the purpose for which the electronic file was
encoded, together with any other relevant information concerning the
process by which it was assembled or collected.  This is of particular
importance for corpora or miscellaneous collections, but may be of use
for any text, for example to explain why one kind of encoding practice
has been followed rather than another.
<list type=gloss>
<label><gi>projectDesc</gi></label>
<item>describes in detail the aim or purpose for which an 
electronic
file was encoded, together with any other 
relevant information
concerning the process by which it 
was assembled or collected.</item>
</list>
</p>
<p>For example:
<eg>
<![ CDATA[
 <encodingDesc>
 <projectDesc><p>Texts collected for use in the
    Claremont Shakespeare Clinic, June 1990.
 </encodingDesc>
]]>
</eg></p>

<p>This element has the following formal declaration:
<eg id=d2251>
<![ CDATA [
<!-- 5.3.1:  The project description                          -->
<!ELEMENT projectDesc   - o  (p+)                               >
<!ATTLIST projectDesc        %a.global;
                             %a.declarable;                     >
<!-- This fragment is used in sec. 5.3                        -->
]]>
</eg>
</p></div3>

<div3 id="hd52"><head>The Sampling Declaration</head>

<p>The <gi>samplingDecl</gi> element is the second of the nine optional
subdivisions of the <gi>encodingDesc</gi> element.  It contains a prose
description of the rationale and methods used in sampling texts, for
example to create a representative corpus.
<list type=gloss>
<label><gi>samplingDecl</gi></label>
<item>contains a prose description of the rationale and methods 
used
in sampling texts in the creation of a corpus or 
collection.</item>
</list>

It should include information about such matters as

<list type="bullets">
<item>the size of individual samples</item>
<item>the method or methods by which they were selected</item>
<item>the underlying population being sampled</item>
<item>the object of the sampling procedure used</item>
</list>

but is not restricted to these.
<!-- should attributes be used for sample size, etc? -LB -->
<!-- if it would help automatic processing yes.  but i   -->
<!-- doubt it.  so no.  -msm                             -->

<eg>
<![ CDATA [
<samplingDecl>
  <p>Samples of 2000 words taken from the beginning of the text.
</samplingDecl>
]]>
</eg></p>

<p>It may also include a simple
description of any parts of the source text included or excluded.

<eg>
<![ CDATA [
<samplingDecl>
  <p>Text of stories only has been transcribed.
     Pull quotes, captions, and advertisements have been
     silently omitted.  Any mathematical expressions
     requiring symbols not present in the ISOnum or
     ISOpub entity sets have been omitted, and their
     place marked with a GAP element.
</samplingDecl>
]]>
</eg></p>

<p>A sampling declaration which applies to more than one text or
division of a text need not be repeated in the header of each such text.
Instead, the <att>decls</att> attribute of each text (or subdivision of
the text) to which the sampling declaration applies may be used to
supply a cross reference to it, as further described in section <ptr
target="CCas">.
<!-- was:  target=p2.3431>. -->
<!-- was:  target=SP31>. -->
This element has the following formal declaration:

<eg id=d2252>
<![ CDATA [
<!-- 5.3.2:  The sampling declaration                         -->
<!ELEMENT samplingDecl  - o  (p+)                               >
<!ATTLIST samplingDecl       %a.global;
                             %a.declarable;                     >
<!-- This fragment is used in sec. 5.3                        -->
]]>
</eg>
</p></div3>

<div3 id="hd53"><head>The Editorial Practices Declaration</head>

<p>The <gi>editorialDecl</gi> element is the third of the nine optional
subdivisions of the <gi>encodingDesc</gi> element.  It is used to
provide details of the editorial practices applied during the encoding
of a text.
<list type=gloss>
<label><gi>editorialDecl</gi></label>
<item>provides details of editorial principles and practices 
applied
during the encoding of a text.</item>
</list>

It may contain a prose description only, or one or more of the following
specialized elements:

<list type=gloss>
<label><gi>correction</gi></label>
<item>states how and under what circumstances corrections have 
been
made in the text.
Attributes include:
<list type=gloss>
<label><att>status</att></label>
<item>indicates the degree of correction applied to the text.
Legal values are:
<list type=gloss>
<label><term>medium</term></label>
<item>the text has been checked at least once.</item>
<label><term>low</term></label>
<item>the text has not been checked.</item>
<label><term>unknown</term></label>
<item>the correction status of the text is unknown.</item>
<label><term>high</term></label>
<item>the text has been thoroughly checked and proofread.</item>
</list></item>
<label><att>method</att></label>
<item>indicates the method adopted to indicate corrections within 
the text.
Legal values are:
<list type=gloss>
<label><term>silent</term></label>
<item>corrections have been made silently</item>
<label><term>tags</term></label>
<item>corrections have been represented using editorial tags</item>
</list></item>
</list>
</item>
<label><gi>normalization</gi></label>
<item>indicates the extent of normalization or regularization of 
the
original source carried out in converting it to 
electronic form.
Attributes include:
<list type=gloss>
<label><att>source</att></label>
<item>indicates the authority for any normalization carried out.</item>
<label><att>method</att></label>
<item>indicates the method adopted to indicate normalizations 
within the text.
Sample values include:
<list type=gloss>
<label><term>silent</term></label>
<item>normalization made silently</item>
<label><term>tags</term></label>
<item>normalization represented using editorial tags</item>
</list></item>
</list>
</item>
<label><gi>quotation</gi></label>
<item>specifies editorial practice adopted with respect to 
quotation
marks in the original. 
Attributes include:
<list type=gloss>
<label><att>marks</att></label>
<item>indicates whether or not quotation marks have been retained 
as content within the text.
Sample values include:
<list type=gloss>
<label><term>none</term></label>
<item>no quotation marks have been retained</item>
<label><term>some</term></label>
<item>some quotation marks have been retained</item>
<label><term>all</term></label>
<item>all quotation marks have been retained</item>
</list></item>
<label><att>form</att></label>
<item>specifies how quotation marks are indicated within the 
text.
Sample values include:
<list type=gloss>
<label><term>std</term></label>
<item>use of quotation marks has been standardized.</item>
<label><term>data</term></label>
<item>quotation marks are retained as data.</item>
<label><term>nonstd</term></label>
<item>quotation marks are represented inconsistently.</item>
<label><term>rend</term></label>
<item>the <att>rendition</att> attribute is consistently used to 
indicate the form of quotation marks.</item>
<label><term>unknown</term></label>
<item>use of quotation marks is unknown.</item>
</list></item>
</list>
</item>
<label><gi>hyphenation</gi></label>
<item>summarizes the way in which hyphenation in a source text 
has been
treated in an encoded version of it.
Attributes include:
<list type=gloss>
<label><att>eol</att></label>
<item>indicates whether or not end-of-line hyphenation has been 
retained in a text.
Sample values include:
<list type=gloss>
<label><term>some</term></label>
<item>end-of-line hyphenation has been retained in some cases.</item>
<label><term>none</term></label>
<item>all end-of-line hyphenation has been removed: any remaining 
hyphenation occurred within the line.</item>
<label><term>hard</term></label>
<item>all `soft' end-of-line hyphenation has been removed: any 
remaining hyphenation represents `hard hyphens'.</item>
<label><term>all</term></label>
<item>all end-of-line hyphenation has been retained, even though 
the lineation of the original may not have been.</item>
</list></item>
</list>
</item>
<label><gi>segmentation</gi></label>
<item>describes the principles according to which the text has 
been
segmented, for example into sentences, tone-units, 
graphemic strata,
etc.</item>
<label><gi>stdVals</gi></label>
<item>specifies the format used when standardized date or number

values are supplied.</item>
<label><gi>interpretation</gi></label>
<item>describes the scope of any analytic or interpretive 
information
added to the text in addition to the 
transcription. </item>
</list>


<!-- PR urges for P4 a clearer distinction between            -->
<!-- proofreading and editorial correction.                   -->

Some of these elements carry attributes to support automated processing
of certain well-defined editorial decisions; all of them contain a prose
description of the editorial principles adopted with respect to the
particular feature concerned.  Examples of the kinds of questions which
these descriptions are intended to answer are listed below, in the same
order as the list above.

<list type="gloss">

<label><gi>correction</gi></label>
<item>Was the text corrected during or after data capture?  If
so, were corrections made silently or are they marked using the
tags described in section <ptr target="COed">?  What principles
<!-- was:  target='p2.47' -->
<!-- was:  target='COedit'-->
have been adopted with respect to omissions, truncations, dubious
corrections, alternate readings, false starts, repetitions, etc.?</item>

<label><gi>normalization</gi></label>
<item>Was the text normalized, for example by regularizing any
non-standard spellings, dialect forms, etc.?  If so, were normalizations
performed silently or are they marked using the tags described in
section <ptr target="COed">?
<!-- was:  target='p2.47' -->
<!-- was:  target='COedit' -->
What authority was used for the regularization?  Also, what principles
were used when normalizing dates or numbers to provide the standard
values for the <att>value</att> attribute described in sections <ptr
target="COnanu"> and <ptr target="COnada">
<!-- was:  target='p2.23a'  and target='p2.23b'  -->
<!-- was:  target='COnums'  and target='COdate'  -->
and what format used for them?</item>

<label><gi>quotation</gi></label>
<item>How were quotation marks processed?  Are apostrophes and quotation
marks distinguished?  How?  Are quotation marks retained as content in
the text or replaced by markup?  Was the <att>rendition</att> attribute
used to record the specific appearance of any quotation marks removed
from the text?  Are there any special conventions regarding for example
the use of single or double quotation marks when nested?  Is the file
consistent in its practice or has this not been checked?</item>

<label><gi>hyphenation</gi></label>
<item>Does the encoding distinguish <socalled>soft</socalled> and
<socalled>hard</socalled> hyphens?
What principle has been adopted with respect to end-of-line hyphenation
where source lineation has not been retained?  Have soft hyphens been
silently removed, and if so what is the effect on lineation and
pagination?</item>

<label><gi>segmentation</gi></label> <item>How is the text segmented?  If
<gi>s</gi> or <gi>seg</gi> segmentation units have been used to divide
up the text for analysis, how are they marked and how was the
segmentation arrived at?</item>

<label><gi>stdVals</gi></label>

<item>What standardization methods underly any standardized values
supplied for numeric values or dates?  If the <att>value</att> attribute
described in section <ptr target="COnada"> has been used,
<!-- was:  target='p2.23b' -->
<!-- was:  target='COdate' -->
in what format are its values presented?</item>

<label><gi>interpretation</gi></label>
<item>Has any analytic or <socalled>interpretive</socalled> information
been provided --- that is, information which is felt to be non-obvious,
contentious, or subject to disagreement? If so, how was it generated?
How was it encoded? If feature-structure analysis has been used, are
<gi>fsdDecl</gi> elements (section <ptr target="HDfsd">) present?</item>
</list></p>

<p>Any information about the editorial principles applied not falling
under one of the above headings should be recorded in a distinct list
of items.  Experience shows that a full record should be kept of
decisions relating to editorial principles and encoding practice,
both for future users of the text and for the project which produced
the text in the first instance.

<!-- Need at least one example!  But I don't have time to     -->
<!-- to add one.   in haste, -msm                             -->
A simple example follows:
<eg>
<![ CDATA [
<editorialDecl id=E2>
<interpretation>
  <p>The part of speech analysis applied throughout section 4 was
  added by hand and has not been checked.
<correction><p>Errors in transcription controlled by using the
    WordPerfect spelling checker.
<normalization source=W9>
  <p>All words converted to Modern American spelling using
    Websters 9th Collegiate dictionary.
<quotation marks=all form=std>
  <p>All opening quotation marks converted to &odq; all closing
    quotation marks converted to &cdq;.
</editorialDecl>
]]>
</eg>
<!-- an unresolved problem: where do I store the full citation -->
<!-- to which 'W9' is meant to be pointing at? -->
<!-- DB objects to '&amp;odq;' as "indecipherable" (msm)      --></p>

<p>These elements are formally defined as follows:
<eg id=d2253>
<![ CDATA [
<!-- 5.3.3:  The editorial practices declaration              -->
<!ELEMENT editorialDecl - o  ( p+ | ((correction | 
                             normalization | quotation | 
                             hyphenation | interpretation | 
                             segmentation | stdVals)+, p*))     >
<!ATTLIST editorialDecl      %a.global;
                             %a.declarable;                     >
<!ELEMENT correction    - o  (p+)                               >
<!ATTLIST correction         %a.global;
                             %a.declarable;
          method             (silent | tags)     silent
          status             (high | medium | low | unknown) 
                                                 unknown        >
<!ELEMENT normalization - o  (p+)                               >
<!ATTLIST normalization      %a.global;
                             %a.declarable;
          source             CDATA               #IMPLIED
          method             (silent | tags)     silent         >
<!ELEMENT quotation     - o  (p+)                               >
<!ATTLIST quotation          %a.global;
                             %a.declarable;
          form               (data | rend | std | nonstd | 
                             unknown)            unknown
          marks              (none | some | all) all            >
<!ELEMENT hyphenation   - o  (p+)                               >
<!ATTLIST hyphenation        %a.global;
                             %a.declarable;
          eol                (all | some | none) some           >
<!ELEMENT segmentation  - o  (p+)                               >
<!ATTLIST segmentation       %a.global;
                             %a.declarable;                     >
<!ELEMENT stdVals       - o  (p+)                               >
<!ATTLIST stdVals            %a.global;
                             %a.declarable;                     >
<!ELEMENT interpretation 
                        - o  (p+)                               >
<!ATTLIST interpretation     %a.global;
                             %a.declarable;                     >
<!-- This fragment is used in sec. 5.3                        -->
]]>
</eg>


An editorial practices declaration which applies to more than one text
or division of a text need not be repeated in the header of each such
text.  Instead, the <att>decls</att> attribute of each text (or
subdivision of the text) to which it applies may
be used to supply a cross reference to it, as further described in
section <ptr target="CCas">.
<!-- was:  target=p2.3431>. -->
<!-- was:  target=SP31>. --></p></div3>

<div3 id="HD57"><head>The Tagging Declaration</head>

<p>The <gi>tagsDecl</gi> element is the fourth of the nine optional
subdivisions of the <gi>encodingDesc</gi> element.  It is used to record
the following information about the tagging used within a particular
text:
<list>
<item>how often particular SGML elements appear within the text, so that
a recipient can validate the integrity of a text during interchange.</item>
<item>any comment relating to the usage of particular elements not
specified elsewhere in the header.</item>
<item>a definition for the default rendition applying to all instances
of an element, unless otherwise stated by the global <att>rend</att>
attribute.</item>
</list></p>

<p>This information is conveyed by the following elements:
<list type=gloss>
<label><gi>rendition</gi></label>
<item>supplies information about the intended rendition of one or 
more
elements.</item>
<label><gi>tagUsage</gi></label>
<item>supplies information about the usage of a specific element

within a <gi>text</gi>. 
Attributes include:
<list type=gloss>
<label><att>occurs</att></label>
<item>specifies the number of occurrences of this element within 
the text.</item>
<label><att>ident</att></label>
<item>specifies the number of occurrences of this element within 
the text which bear a distinct value for the global 
<att>id</att> attribute.</item>
<label><att>render</att></label>
<item>specifies the identifier of a <gi>rendition</gi> element 
which defines how this element is to be rendered.</item>
</list>
</item>
</list>
</p>

<p>The <gi>tagsDecl</gi> element consists of an optional sequence of
<gi>rendition</gi> elements, each of which must bear a unique
identifier, followed by a sequence of <gi>tagUsage</gi> elements, one
for each distinct element occurring within the outermost
<gi>text</gi> element of a TEI document.</p>

<p>The <gi>rendition</gi> element defined in this version of the TEI
Guidelines is a preliminary proposal only, intended to provide a hook
for more detailed specifications of default rendition in later versions.

<!-- Or think of it as the VAL attribute on MSM's -->
<!-- proposed SETREND element... --></p>

<p>The present proposal allows the encoder to enter an informal
description of a rendition, or style, as running prose only. This
rendition will be assumed to apply, by default, to all occurrences of
an element which names its identifier as the value of the
<att>render</att> attribute of the appropriate <gi>tagUsage</gi>
element. For element occurrences to which this default rendition does
not apply, the encoder should specify an explicit description using the
global <att>rend</att> attribute on the elements concerned.</p>

<p>For example, the following schematic shows how an encoder might
specify that <gi>p</gi> elements are by default to be rendered using one
set of specifications identified as <code type="value">style1</code>,
while <gi>hi</gi>
elements are to use a different set, identified as <code type="value">style2</code>:

<eg>
<![ CDATA [
<tagsDecl>
 <rendition id=style1>
   <!-- description of one default rendition here -->
 <rendition id=style2>
   <!-- description of another default rendition here -->
 <tagUsage gi=p render=style1>
 <tagUsage gi=hi render=style2>
</tagsDecl>
]]>
</eg></p>


<p>No detailed proposals for the content of the <gi>rendition</gi>
element have as yet been formulated.  It is probable that subsequent
work will incorporate specifications derived from, or compatible with,
the properties currently being standardized as part of the draft
Document Style and Semantics Specification Language (ISO DIS 10179).</p>

<p>A <gi>tagsDecl</gi> need not specify any <gi>rendition</gi> element.
If present, it must however contain exactly one occurrence of a
<gi>tagUsage</gi> element for each distinct element marked within the
outermost <gi>text</gi> element associated with the <gi>teiHeader</gi>
in which it appears.<note>This implies that the <gi>tagsDecl</gi> will
normally only appear in the header of individual texts in a
<gi>teiCorpus</gi>.</note> The <gi>tagUsage</gi> element is used to
supply a count of the number of occurrences of this element within the
text, which is given as the value of its <att>occurs</att> attribute.
It may also be used to hold any additional usage information, which is
supplied as running prose within the element itself.</p>

<p>For example:

<eg>
<![ CDATA [
  <tagUsage gi=hi occurs=28>
      Used only to mark English words italicised in the copy text.
  </tagUsage>
]]>
</eg>

This indicates that the <gi>hi</gi> element appears a total of 28 times
in the <gi>text</gi> element in question, and that the encoder has used
it to mark italicised English phrases only.</p>

<p>The <att>ident</att> attribute may optionally be used to specify how
many of the occurrences of the element in question bear a value for the
global <att>id</att> attribute, as in the following example:


<eg>
<![ CDATA [
  <tagUsage gi=pb occurs=321 ident=321>
      Marks page breaks in the York (1734) edition only
  </tagUsage>
]]>
</eg>

This indicates that the <gi>pb</gi> element occurs 321 times, on each
of which an identifier is provided.</p>

<p>The content of the <gi>tagUsage</gi> element is not susceptible of
automatic processing.  It should not therefore be used to hold
information for which provision is already made by other components of
the encoding description.  A TEI conformant document is not required
to contain a <gi>tagsDecl</gi> element, but if one is present, it must
contain <gi>tagUsage</gi> elements for each distinct element marked in
the associated text, and the counts specified by their <att>usage</att>
elements must correspond with the number of such elements present in the
document, as identified by some conforming SGML processor.

<!-- the document's Element Structure Information Set, that   -->
<!-- is, as identified by any conforming SGML processor.      -->

<!-- OK? YHBW! -->
<!-- I don't think we should refer to ESIS without defining it. -->
<!-- I don't think we should get into defining ESIS here.     -->
<!-- Therefore I don't think we should refer to it here.      -->
<!-- But how else do we say it?  -msm                         -->
<!-- without mentioning ESIS. -msm                            -->

<eg id=dhd57>
<![ CDATA [
<!-- 5.3.4:  Tag usage and rendition declarations             -->
<!ELEMENT tagsDecl      - O  (rendition*, tagUsage*)            >
<!ATTLIST tagsDecl           %a.global;                         >
<!ELEMENT tagUsage      - O  (%paraContent)                     >
<!ATTLIST tagUsage           %a.global;
          gi                 NAME                #REQUIRED
          occurs             NUMBER              #IMPLIED
          ident              NUMBER              #IMPLIED
          render             IDREF               #IMPLIED       >
<!ELEMENT rendition     - O  (%paraContent)                     >
<!ATTLIST rendition          %a.global;                         >
<!-- This fragment is used in sec. 5.3                        -->
]]>
</eg>
</p></div3>

<div3 id="hd54"><head>The Reference System Declaration</head>

<p>The <gi>refsDecl</gi> element is the fifth of the nine optional
subdivisions of the <gi>encodingDesc</gi> element. It is used to
document the way in which any standard referencing scheme built into
the encoding works, either as a series of prose paragraphs or by
using the following specialized elements:

<list type=gloss>
<label><gi>refsDecl</gi></label>
<item>specifies how canonical references are constructed for this 
text.
Attributes include:
<list type=gloss>
<label><att>doctype</att></label>
<item>identifies the <term>document type</term> within which this 
reference declaration is used.</item>
</list>
</item>
<label><gi>step</gi></label>
<item>specifies one component of a canonical reference defined by
the <q>stepwise</q> method.</item>
<label><gi>state</gi></label>
<item>specifies one component of a canonical reference defined by
the <q>milestone</q> method.</item>
</list>


Note that not all possible referencing schemes are equally easily
supported by current software systems.  A choice must be made between
the convenience of the encoder and the likely efficiency of the
particular software applications envisaged, in this context as in many
others.  For a more detailed discussion of referencing
systems supported by these Guidelines, see section <ptr target="COrs"> below.
<!-- was:  target=COrsys> -->
<!-- was:  target=p2.232> --></p>

<p>A referencing scheme may be described in one of three ways using this
element:

<list type="bullets">
<item>as a prose description</item>
<item>as a series of <term>steps</term> expressed in the TEI
extended pointer notation (documented in section <ptr target="SAxr">)</item>
<item>as a concatenation of sequentially organized
<term>milestones</term></item>
</list>

Each method is described in more detail below.  Only one method can be
used within a single <gi>refsDecl</gi> element.</p>

<p>More than one <gi>refsDecl</gi> element can be included in the header
if more than one canonical reference scheme is to be used in the same
document, but the current proposals do not check for mutual
inconsistency.  A reference declaration can only describe the
referencing system applicable to a single document type; if therefore
concurrent document types are in use (as discussed in section <ptr
target="COrs">), a <gi>refsDecl</gi> element must be supplied for each;
the <att>doctype</att> attribute should be used to specify the document
type to which the declaration relates.</p>

<div4 id="hd54p"><head>Prose Method</head>

<p>The referencing scheme may be specified within the <gi>refsDecl</gi>
by a simple prose description.  Such a description should indicate which
elements carry identifying information, and whether this information is
represented as attribute values or as content.  Any special rules about
how the information is to be interpreted when reading or generating a
reference string should also be specified here.  Such a prose
description cannot be processed automatically, and this method of
specifying the structure of a canonical reference system is therefore
not recommended for automatic processing.</p>

<p>For example:

<eg><![ CDATA[
 <refsDecl>
 <p>The N attribute of each text in this corpus carries
 a unique identifying code for the whole text. The title
 of the text is held as the content of the first HEAD
 element within each text. The N attribute on each DIV1
 and DIV2 contains the canonical reference for
 each such division, in the form 'XX.yyy', where XX
 is the book number in Roman numerals, and yyy the section
 number in arabic. Line breaks are marked by empty LINEBREAK
 tags, each of which includes the through line number
 in Casaubon's edition as the value of its N attribute.
 <p>The through line number and the text identifier
 uniquely identify any line. A canonical reference
 may be made up by concatenating the the N values from the
 text, div1 or div2 and calculating the line number within
 each part.
 </refsDecl>
]]>
</eg></p></div4>

<div4 id="hd54s"><head>Stepwise Method</head>

<p>This method defines each reference as a series of <term>steps</term>,
each of which corresponds to a single pair of expressions in the TEI
extended pointer notation (for which see section <ptr target="SAxr">).
Often, but not always, each step will also correspond to one portion of
the canonical reference itself; in many common forms of canonical
reference, each step will narrow the scope within which the next step
can be taken.  The <gi>refsDecl</gi> element must specify the steps,
delimiters and lengths to be used by an application program, both when
constructing references for a given location and when interpreting
canonical references within a given document hierarchy.  It does so by
supplying one or more <gi>step</gi> elements, each of which identifies
the type of <socalled>reference unit</socalled> handled by the step and
uses a pair of extended-pointer expressions to indicate the starting and
ending pointers of the portion of the document which corresponds to a
given portion of the reference string.  The element may also give either
a delimiter or a length for use in breaking the corresponding reference
string up into units.

<list type=gloss>
<label><gi>step</gi></label>
<item>specifies one component of a canonical reference defined by
the <q>stepwise</q> method.
Attributes include:
<list type=gloss>
<label><att>refunit</att></label>
<item>names the unit (book, chapter, canto, verse, ...) 
identified by this step in a canonical reference.</item>
<label><att>from</att></label>
<item>specifies the starting point of the area referred to by 
this step in the canonical reference.</item>
<label><att>to</att></label>
<item>specifies the ending point of the area referred to by this 
step in the canonical reference.</item>
<label><att>delim</att></label>
<item>supplies a delimiting string following the reference 
component.</item>
<label><att>length</att></label>
<item>specifies the fixed length of the reference component.</item>
</list>
</item>
</list>
</p>

<p>For example, the reference <q>Matthew 5:29</q> might be constructed
by stepping down the tree to find an element labelled as the
<q>Matthew</q> node, then within that to the <q>5</q> node, and finally,
within that, to the <q>29</q> node.  The following declarations would be
required; the special values <code type="value">%1</code>, <code
type="value">%2</code>, and <code type="value">%3</code> refer here to the
strings <mentioned>Matthew</mentioned>, <mentioned>5</mentioned>, and <mentioned>29</mentioned>,
respectively.

<eg>
<![ CDATA [
<refsDecl>
    <step refunit='book' delim=' '
          from='DESCENDANT (1 DIV1 N %1)'>
    <step refunit='chapter' delim=':'
          from='DESCENDANT (1 DIV2 N %2)'>
    <step refunit='verse'
          from='DESCENDANT (1 DIV3 N %3)'>
</refsDecl>
]]>
</eg>

As this example also shows, the steps of such a reference are typically
separated by fixed character sequences, called <term>delimiters</term>.
In this example, the delimiters are a space (following <q>Matthew</q>)
and a colon (following the chapter number).  A processor for canonical
references would use the delimiters specified by the <att>delim</att>
attributes to break the reference string up into pieces; the pieces
would then be used to interpret the <code type="value">%1</code>, etc., in
the extended pointer expressions of the <att>from</att> and
<att>to</att> attributes.</p>

<p>An alternative to the use of delimiters is to specify a fixed length
for each step of the reference:  for example, the same reference might
be given as <q>MAT05029</q>, assuming a fixed length of 3 for the first
step, 2 for the second and 3 for the third.

<eg>
<![ CDATA [
<refsDecl>
    <step length=3
          from='DESCENDANT (1 DIV1 N %1)'>
    <step length=2
          from='DESCENDANT (1 DIV2 N %2)'>
    <step length=3
          from='DESCENDANT (1 DIV3 N %3)'>
</refsDecl>
]]>
</eg>

The order in which the <gi>step</gi> elements are supplied corresponds
here with the order of elements within the reference, with the largest
(that is, the one nearest the top of the document hierarchy) item first
and the smallest last.</p>

<p>For a description of the processing required when a canonical
reference defined by <gi>step</gi> elements is to be recognized,
and examples of its use, see chapter <ptr target="CR">.

<!-- following material deleted (regretfully) as too detailed: should -->
<!-- all go to section CREF --></p></div4>

<div4 id="hd54m"><head>Milestone Method</head>

<p>This method is appropriate when only <socalled>milestone</socalled>
tags (see section <ptr target="COrs5">) are available to provide the
required referencing information.  It does not provide any abilities
which cannot be mimicked by the stepwise referencing method discussed in
the previous section, but in the cases where it applies, it provides a
somewhat simpler notation.</p>

<p>A reference based on milestone tags concatenates the values specified
by one or more such tags.  Since each tag marks the point at which a
value changes, it may be regarded as specifying the <term>state</term>
of a variable.  A reference declaration using this method therefore
specifies the individual components of the canonical reference as a
sequence of <gi>state</gi> elements:

<list type=gloss>
<label><gi>state</gi></label>
<item>specifies one component of a canonical reference defined by
the <q>milestone</q> method.
Attributes include:
<list type=gloss>
<label><att>ed</att></label>
<item>indicates which edition or version the milestone applies 
to.</item>
<label><att>unit</att></label>
<item>indicates what kind of section is changing at this 
milestone.
Suggested values include:
<list type=gloss>
<label><term>line</term></label>
<item>line breaks.</item>
<label><term>poem</term></label>
<item>individual poems in a collection.</item>
<label><term>book</term></label>
<item>any units termed <q>book</q>,<q>liber</q>, etc.</item>
<label><term>scene</term></label>
<item>scenes within a play or act.</item>
<label><term>page</term></label>
<item>page breaks in the reference edition.</item>
<label><term>stanza</term></label>
<item>stanzas within a poem, book, or canto.</item>
<label><term>absent</term></label>
<item>passages not present in the reference edition.</item>
<label><term>column</term></label>
<item>column breaks.</item>
<label><term>canto</term></label>
<item>cantos or other major sections of a poem.</item>
<label><term>act</term></label>
<item>acts within a play.</item>
<label><term>section</term></label>
<item>sections of any kind.</item>
</list></item>
<label><att>delim</att></label>
<item>supplies a delimiting string following the reference 
component.</item>
<label><att>length</att></label>
<item>specifies the fixed length of the reference component.</item>
</list>
</item>
</list>
</p>

<p>For example, the reference <q>Matthew 12:34</q> might be thought of
as representing the state of three variables:  the <q>book</q> variable
is in state <q>Matthew</q>; the <ident type="var">chapter</ident> variable
is in state <q>12</q>, and the <ident type="var">verse</ident> variable is
in state <q>34</q>.  If milestone tagging has been used, there should be
a tag marking the point in the text at which each of the above
<socalled>variables</socalled> changes its state.<note place="foot">On the
milestone tag itself, what are here referred to as
<socalled>variables</socalled> are identified by the combination of the
<att>ed</att> and <att>unit</att> attributes.</note>
To find <q>Matthew 12:34</q> therefore an application must scan left to
right through the text, monitoring changes in the state of each of these
three variables as it does so.  When all three are simultaneously in the
required state, the desired point will have been reached.  There may of
course be several such points.</p>

<p>The <att>delim</att> and <att>length</att> attributes are used to
specify components of a canonical reference using this method in exactly
the same way as for the stepwise method described in the preceding
section.  The other attributes are used to determine which instances of
<gi>milestone</gi> tags in the text are to be checked for state-changes.
A state-change is signalled whenever a new <gi>milestone</gi> tag is
found with <att>unit</att> and, optionally, <att>ed</att> attributes
identical to those of the <gi>state</gi> element in question.  The value
for the new state may be given explicitly by the <att>n</att> attribute
on the <gi>milestone</gi> element, or it may be implied, if the
<att>n</att> attribute is not specified.</p>

<p>For example, for canonical references in the form <mentioned>xx.yyy</mentioned> where
the <mentioned>xx</mentioned> represents the page number in the first edition, and
<mentioned>yyy</mentioned> the line number within this page, a reference system
declaration such as the following would be appropriate:

<eg><![ CDATA[
 <refsDecl>
   <state ed='first' unit='page' delim='.' length=2>
   <state ed='first' unit='line' length=4>
 </refsDecl>
]]>
</eg>

This implies that milestone tags of the form

<eg><![ CDATA[
 <milestone ed='first' unit=page n='II'>
 <milestone ed='first' unit=line>
]]>
</eg>

will be found throughout the text, marking the positions at which page
and line numbers change. Note that no value has been specified for the
<att>n</att> attribute on the second milestone tag above; this implies
that its value at each state change is monotonically increased.
For more detail on the use of milestone tags, see section
<ptr target="COrs5">.
<!-- was:  target=p2.232ms> -->
<!-- was:  target=COrsys5 > -->
<!-- following algorithm should also be moved to CREF --></p>

<p>The milestone referencing scheme, though conceptually simple, is not
and cannot be supported by an SGML parser.  Its use places a
correspondingly greater burden of verification and accuracy on the
encoder.</p>

<p>The elements discussed in this section are formally defined as
follows:

<eg id=d2254>
<![ CDATA [
<!-- 5.3.5.3:  The reference scheme declaration               -->
<!ELEMENT refsDecl      - o  (p+ | step+ | state+)              >
<!ATTLIST refsDecl           %a.global;
          doctype            NAME                TEI.2          >
<!ELEMENT step          - o  EMPTY                              >
<!ATTLIST step               %a.global;
          refunit            CDATA               #IMPLIED
          to                 %extPtr             'DITTO'
          from               %extPtr             #REQUIRED
          length             NUMBER              #IMPLIED
          delim              CDATA               #IMPLIED       >
<!ELEMENT state         - o  EMPTY                              >
<!ATTLIST state              %a.global;
          ed                 CDATA               #IMPLIED
          length             NUMBER              #IMPLIED
          unit               CDATA               #REQUIRED
          delim              CDATA               #IMPLIED       >
<!-- This fragment is used in sec. 5.3                        -->
]]>
</eg>
</p>

<p>A reference system declaration which applies to more than one text or
division of a text need not be repeated in the header of each such text.
Instead, the <att>decls</att> attribute of each text (or subdivision of
the text) to which the declaration applies may be used to supply a cross
reference to it, as further described in section <ptr target="CCas">.
<!-- was:  target=SP31>. -->
<!-- was:  target=p2.3431>. -->

<!></p></div4></div3>
<div3 id="hd55"><head>The Classification Declaration</head>

<p>The <gi>classDecl</gi> element is the sixth of the nine optional
subdivisions of the <gi>encodingDesc</gi> element.  It is used to group
together definitions or sources for any descriptive classification
schemes used by other parts of the header.  Each such scheme is
represented by a <gi>taxonomy</gi> element, which may contain either a
simple bibliographic citation, or a definition of the
descriptive typology concerned; the following elements are used
in defining a descriptive classification scheme:

<list type=gloss>
<label><gi>classDecl</gi></label>
<item>contains one or more taxonomies defining any classificatory
codes used elsewhere in the text.</item>
<label><gi>taxonomy</gi></label>
<item>defines a typology used to classify texts either 
implicitly, by
means of a bibliographic citation, or 
explicitly by a structured
taxonomy.</item>
<label><gi>category</gi></label>
<item>contains an individual descriptive category, possibly 
nested
within a superordinate category, within a 
user-defined taxonomy.</item>
<label><gi>catDesc</gi></label>
<item>describes some category within a taxonomy
or text 
typology, either in the form of a brief prose description

or in terms of the situational parameters used by the TEI

formal <gi>textDesc</gi>.</item>
</list>


The <gi>taxonomy</gi> element has two slightly different, but related,
functions. For well-recognized and documented public classification
schemes, such as Dewey or other published descriptive thesauri, it
contains simply a bibliographic citation indicating where a full
description of a particular taxonomy may be found.
<eg><![ CDATA[
<taxonomy id=DDC12>
  <bibl><title>Dewey Decimal Classification</title>
    <edition>Abridged Edition 12</edition>
    <!-- etc. -->
  </bibl>
</taxonomy>
]]>
</eg>

For less easily accessible schemes, the <gi>taxonomy</gi> element
contains a description of the taxonomy itself as well as an optional
bibliographic citation.  The description consists of a number of
<gi>category</gi> elements, each defining a single category within the
given typology.  The category is defined by the contents of a nested
<gi>catDesc</gi> element, which may contain either a phrase describing
the category, or a <gi>textDesc</gi> element defining it in terms of the
situational parameters discussed in section <ptr target="CCahtd">.  If the
category is subdivided, each subdivision is represented by a nested
<gi>category</gi> element, having the same structure.  Categories may be
nested to an arbitrary depth in order to reflect the hierarchical
structure of the taxonomy.  Each <gi>category</gi> element bears a
unique <att>id</att> attribute, which is used as the target for
<gi>catRef</gi> elements referring to it.

<eg><![ CDATA[

<taxonomy id=B>
   <bibl>Brown Corpus</bibl>
   <category id=B.A><catDesc>Press Reportage
      <category id=B.A1><catDesc>Daily</category>
      <category id=B.A2><catDesc>Sunday</category>
      <category id=B.A3><catDesc>National</category>
      <category id=B.A4><catDesc>Provincial</category>
      <category id=B.A5><catDesc>Political</category>
      <category id=B.A6><catDesc>Sports</category>
    <!-- ... -->
   </category>
   <category id=B.D><catDesc>Religion
      <category id=B.D1><catDesc>Books</category>
      <category id=B.D2><catDesc>Periodicals and tracts</category>
   </category>
<!-- ... -->
</taxonomy>
]]>
</eg></p>

<p>Linkage between a particular text and a category within such a
taxonomy is made by means of the <gi>catRef</gi> element within the
<gi>textClass</gi> element, as described in section <ptr
target="hd43">.  Where the taxonomy permits of classification along more
than one dimension, more than one category will be referenced by a
particular <gi>catRef</gi>, as in the following example, which
identifies a text with the sub-categories <q>Daily</q>, <q>National</q>
and <q>Political</q>, within the category <q>Press Reportage</q> as
defined above.

<eg><![ CDATA[
 <catRef target="B.A1 B.A3 B.A5">
]]>
</eg></p>

<p>The elements discussed in this section are defined as follows:

<eg id=d2255>
<![ CDATA [
<!-- 5.3.6:  The classification declaration                   -->
<!ELEMENT classDecl     - -  (taxonomy+)                        >
<!ATTLIST classDecl          %a.global;                         >
<!ELEMENT taxonomy      - -  (category+ | ((bibl | biblStruct | 
                             biblFull), category*))             >
<!ATTLIST taxonomy           %a.global;                         >
<!ELEMENT category      - -  (catDesc, category*)               >
<!ATTLIST category           %a.global;                         >
<!ELEMENT catDesc       - o  (%phrase.seq; | textDesc)          >
<!ATTLIST catDesc            %a.global;                         >
<!-- This fragment is used in sec. 5.3                        -->
]]>
</eg>
</p></div3>

<div3 id="HDfsd"><head>The Feature System Declaration</head>

<p>The <gi>fsdDecl</gi> element is the seventh of the nine optional
subdivisions of the <gi>encodingDesc</gi> element.  It is used to
associate a <term>feature system declaration</term>  (as defined in
chapter <ptr target="FD">) with any analytic <term>feature
structures</term> (as defined in chapter <ptr target="FS">) present in
the text documented by this header.</p>

<p>It has the following description and attributes:

<list type=gloss>
<label><gi>fsdDecl</gi></label>
<item>identifies the feature system declaration which contains

definitions for a particular type of feature structure.
Attributes include:
<list type=gloss>
<label><att>type</att></label>
<item>identifies the type of feature structure documented in the 
FSD; this will be the value of the <att>type</att> 
attribute on at least one feature structure.</item>
<label><att>fsd</att></label>
<item>specifies the external entity containing the feature system 
declaration; an entity declaration in the document's DTD 
subset must associate the entity name with a file on the 
system.</item>
</list>
</item>
</list>


Note that one <gi>fsdDecl</gi> element must be specified for each
distinct type of feature structure used in the markup.  The
<att>fsd</att> element supplies the name of an external entity
containing the actual declaration for that type of feature structure.
This entity will typically be defined in the document type subset for
the document, as in the following example:

<eg rend="skel">
<![ CDATA [
<!DOCTYPE TEI.2 PUBLIC "-//TEI P3//DTD Main Document Type//EN"
                       "tei2.dtd" [
   <!-- declare an external entity for the FSD -->
   <!ENTITY myFeatures  SYSTEM 'myfeat.fsd' SUBDOC >
]>
<tei.2>
<!-- ... -->
</tei.2>
]]>
</eg>

This associates the name <ident rend="noindex" type="ge">myFeatures</ident>
with an external <code type="kw">SUBDOC</code> entity<note>The <code
type="kw">SUBDOC</code> keyword indicates to an SGML parser that this
entity contains SGML data which must be parsed using some other DTD than
the current one:  in this case, the DTD defined in chapter <ptr
target="FD"> rather than the view of the TEI DTD defined for the
document itself.</note> held in this example within a system file called
<ident rend="noindex" type="file">myfeat.wsd</ident>.  This entity name may
then be specified within a <gi>fsdDecl</gi> element in the header to
inform a processor of the location of the feature system declaration
corresponding to a given type of feature structure used within the text,
as follows:

<eg rend="skel">
<![ CDATA [
   <teiHeader>
      <fileDesc> ... </fileDesc>
      <encodingDesc>
           <!-- ... -->
           <fsdDecl type=myA1 fsd=myFeatures>
           <fsdDecl type=myA2 fsd=myFeatures>
           <!-- ... -->
      </encodingDesc>
]]>
</eg>

This header would be attached to a text in which feature structures of
types <code type="value">myA1</code> and <code type="value">myA2</code> are
used.</p>

<p>Further details and examples of the use of feature structure analyses
and feature system declarations are provided in chapters <ptr
target="FS"> and <ptr target="FD"> respectively.</p>

<p>The <gi>fsdDecl</gi> element is declared as follows:

<eg id=d2256>
<![ CDATA [
<!-- 5.3.7:  The FSD declaration                              -->
<!ELEMENT fsdDecl       - O  EMPTY                              >
<!ATTLIST fsdDecl            %a.global;
          type               CDATA               #REQUIRED
          fsd                ENTITY              #REQUIRED      >
<!-- This fragment is used in sec. 5.3                        -->
]]>
</eg>
</p></div3>

<div3 id="HDmn"><head>The Metrical Declaration Element</head>

<p>The <gi>metDecl</gi> element is the eighth of the nine optional
subdivisions of the <gi>encodingDesc</gi> element.  It is used to
document any metrical notation scheme used in the text, as further
discussed in section <ptr target="VEme">. It consists either of
a prose description or a series of <gi>symbol</gi> elements.

<list type=gloss>
<label><gi>metDecl</gi></label>
<item>documents the notation employed to represent a metrical 
pattern
when this is specified as the value of a 
<att>met</att>,
<att>real</att>, or <att>rhyme</att> 
attribute on any structural element
of a metrical text 
(e.g.  <gi>lg</gi>, <gi>l</gi>, or
<gi>seg</gi>).
Attributes include:
<list type=gloss>
<label><att>pattern</att></label>
<item>specifies a regular expression defining any value that is 
legal for this notation.</item>
</list>
</item>
<label><gi>symbol</gi></label>
<item>documents the intended significance of a particular 
character or
character sequence within a metrical 
notation, either explicitly or in
terms of other 
<gi>symbol</gi> elements in the same <gi>metNotation</gi>.
Attributes include:
<list type=gloss>
<label><att>value</att></label>
<item>specifies the character or character sequence being 
documented.</item>
<label><att>terminal</att></label>
<item>specifies whether the symbol is defined in terms of other 
symbols (<att>terminal=N</att>) or in prose 
(<att>terminal=Y</att>).
Sample values include:
<list type=gloss>
<label><term>Y</term></label>
<item>the element contains a prose definition of its meaning.</item>
<label><term>N</term></label>
<item>the element contains a definition of its meaning given 
using symbols defined elsewhere in the same 
<gi>metNotation</gi> element.</item>
</list></item>
</list>
</item>
</list>
</p>

<p>As with other components of the header, metrical notation may be
specified either formally or informally. In a formal specification,
every symbol used in the metrical notation must be documented by a
corresponding <gi>symbol</gi> element; in an informal one, only a brief
prose description of the way in which the notation is used need be
given. In either case, the optional <att>pattern</att> attribute may be
used to supply a regular expression which a processor can use to
validate expressions in the intended notation. The following
constraints apply:

<list>

<item>if <att>pattern</att> is supplied, any notation used which does
not conform to it should be regarded as invalid</item>

<item>if any <gi>symbol</gi> is defined, then any notation using
undefined symbols should be regarded as invalid</item>

<item>if both pattern and symbol are defined, then every symbol
appearing explicitly within pattern must be defined</item>

<item>symbols may be defined within a <gi>metDecl</gi> element which are
not matched by <att>pattern</att></item>

</list></p>

<p>As a simple example, consider the case of the notation in which
metrical prominence, foot and line boundaries are all to be encoded.
Legal specifications in this notation may be written for any sequence of
metrically prominent or non-prominent features, optionally separated by
foot or metrical line boundaries at arbitrary points.  Assuming that the
symbol <mentioned>1</mentioned> is used for metrical prominence,
<mentioned>0</mentioned> for non-prominence, <mentioned>|</mentioned> for foot boundary
and <mentioned>/</mentioned> for line boundary, then the following declaration
achieves this object:

<eg>
<![ CDATA [
<metDecl pattern= '((1|0)+\|?/?)*' >
   <symbol value='1'>metrical promimence
   <symbol value='0'>metrical non-prominence
   <symbol value='|'>foot boundary
   <symbol value='/'>metrical line boundary
</metDecl>
]]>
</eg></p>

<p>The same notation might also be specified less formally, as follows:

<eg>
<![ CDATA[
<metDecl>
 <p>Metrically prominent syllables are marked '1' and other
    syllables '0'. Foot divisions are marked by a vertical bar,
    and line divisions with a solidus.
 <p>This notation may be applied to any metrical unit, of any
    size (including, for example, individual feet as well as
    groups of lines).
</metDecl>
]]>
</eg>

Note that in this case, because the <att>pattern</att> attribute has not
been supplied, no processor can validate <att>met</att> attribute values
within the text which use this metrical notation.</p>

<p>For more complex cases, it will often be more convenient to define a
notation incrementally.  The <att>terminal</att> attribute should be
used to indicate for a given symbol whether or not it may be re-defined
in terms of other symbols used within the same notation.  For example,
here is a notation for encoding classical metres, in which symbols are
provided for the most common types of foot.  These symbols are
themselves documented within the same notation, in terms of more
primitive long and short syllables:

<eg>
<![ CDATA [
<metDecl pattern='[DTIS3A]+'>
 <symbol value='D' n='dactyl'   terminal=N>-oo
 <symbol value='T' n='trochee'  terminal=N>-o
 <symbol value='I' n='iamb'     terminal=N>o-
 <symbol value='S' n='spondee'  terminal=N>--
 <symbol value='3' n='tribrach' terminal=N>ooo
 <symbol value='A' n='anapaest' terminal=N>oo-
 <symbol value='o'>short syllable
 <symbol value='-'>long syllable
</metDecl>
]]>
</eg>

Note here the use of the global <att>n</att> attribute to supply an
additional name for the symbols being documented.</p>

<p>For further discussion of this metrical notation and its use in the
encoding of verse, see section <ptr target="VEme">.</p>

<p>The elements discussed in this section are defined as follows:

<eg id=d2258>
<![ CDATA [
<!-- 5.3.8:  Metrical Notation Declaration                    -->
<!ELEMENT metDecl       - O  ((%component.seq) | (symbol+))     >
<!ATTLIST metDecl            %a.global;
                             %a.declarable;
          pattern            CDATA               #IMPLIED
          type               NAMES               "MET REAL"     >
<!ELEMENT symbol        - O  (%phrase.seq;)                     >
<!ATTLIST symbol             %a.global;
          value              CDATA               #REQUIRED
          terminal           (Y | N)             Y              >
<!-- This fragment is used in sec. 5.3                        -->
]]>
</eg>
</p></div3>

<div3 id="HDvar"><head>The Variant-Encoding Method Element</head>

<p>The <gi>variantEncoding</gi> element is the last of the nine optional
subdivisions of the <gi>encodingDesc</gi> element.  It is used to
document the method used to encode textual variants in the text, as
discussed in section <ptr target="TCaplk">.

<list type=gloss>
<label><gi>variantEncoding</gi></label>
<item>declares the method used to encode text-critical variants.
Attributes include:
<list type=gloss>
<label><att>method</att></label>
<item>indicates which method is used to encode the apparatus of 
variants.
Legal values are:
<list type=gloss>
<label><term>double-end-point</term></label>
<item>apparatus indicates the precise locations of the beginning 
and ending of each lemma relative to a base text.</item>
<label><term>parallel-segmentation</term></label>
<item>alternate readings of a passage are given in parallel in 
the text; no notion of a base text is necessary.</item>
<label><term>location-referenced</term></label>
<item>apparatus uses line numbers or other canonical reference 
scheme referenced in a base text.</item>
</list></item>
<label><att>location</att></label>
<item>indicates whether the apparatus appears within the running 
text or external to it.
Legal values are:
<list type=gloss>
<label><term>external</term></label>
<item>apparatus appears outside the base text.</item>
<label><term>internal</term></label>
<item>apparatus appears within the running text.</item>
</list></item>
</list>
</item>
</list>
</p>


<p>Its formal declaration is as follows:

<eg id=dhdvar>
<![ CDATA [
<!-- 5.3.9:  Variant-Encoding Declaration                     -->
<!ELEMENT variantEncoding 
                        - O  EMPTY                              >
<!ATTLIST variantEncoding    %a.global;
          location           (internal | external) 
                                                 #REQUIRED
          method             (location-referenced | 
                             double-end-point | 
                             parallel-segmentation) 
                                                 #REQUIRED      >
<!-- This fragment is used in sec. 5.3                        -->
]]>
</eg>

</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:("/home/tei/P3/Master/Odds/p2.odd" "TEI.1" "TEXT" "BODY" "DIV1")
sgml-omittag:t
sgml-shorttag:t
End:
-->

<!-- $Id: p2hd4.odd,v 1.6 1998/01/31 19:50:52 tei Exp $ -->
<!--*
    * $Log: p2hd4.odd,v $
    * Revision 1.6  1998/01/31 19:50:52  tei
    * Change system 'tei2.dtd' to public identifier
    * fix log keyword (if not already fixed)
    * normalize the sgml
    *
    * Revision 1.5  98/01/28  11:09:58  cmsmcq
    * LB changes of January 1998
    *
    * Revision 1.4  1994/04/01  16:23:58  msmcq
    * Misc. changes/fixes while validating DTDs
    *
    * Revision 1.3  1994/03/24  22:14:56  msmcq
    * typo corrections from David Barnard, Peter Robinson, and others
    *
    * Revision 1.2  1993/06/22  14:29:49  msmcq
    * Changes post Eynsham and for DTD generation
    * -->
<!-- Revisions:                                               -->
<!-- 4 Jan 98 : LB : fix quebecois eg : no <p> allowed -->
<!-- 94-03-29 : MSM : suppress supererogatory file att on dtdfrags -->
<!-- 94-03-29 : MSM : change CITY to rs type=city             -->
<!-- 94-03-24 : CMSMcQ : more typos, from PR                  -->
<!-- 94-03-22 : CMSMcQ : typos, TEI - &tei, code, ident tags  -->
<!--                     typos noted by DB                    -->
<!-- 93-06-03 : MSM : replace PLACE tag by CITY               -->
<!-- 93-06-01 : MSM : misc normalizations                     -->
<!-- 93-02-10 : MSM : update xref targets                     -->
<!-- 92-08-18 : MSM : revisions, cosmetic changes             -->
<!-- 92-08-17 : MSM : further revisions as per LB discussion  -->
<!-- 2 Aug 92 : LB  : minor tweaks and tidying up             -->
<!-- 25 Jul 92 : MSM : names updated, ids updated             -->

<div2 id="hd4"><head>The Profile Description</head>

<p>The <gi>profileDesc</gi> element is the third major subdivision of
the TEI Header. It is an optional element, the purpose of which is to
enable information characterizing various descriptive aspects of a text
or a corpus to be recorded within a single unified framework.

<list type=gloss>
<label><gi>profileDesc</gi></label>
<item>provides a detailed description of non-bibliographic 
aspects of a
text, specifically the languages and 
sublanguages used, the situation in
which it was produced, 
the participants and their setting.</item>
</list>


In principle, almost any component of the header might be of
importance as a means of characterizing a text.  The author of a written
text, its title or its date of publication, may all be regarded as
characterizing it at least as strongly as any of the parameters
discussed in this section.  The rule of thumb applied has been to
exclude from discussion here most of the information which generally
forms part of a standard bibliographic style description,
if only because such information has already been included
elsewhere in the TEI header.

<!-- forms part of a standard bibliographic style             -->
<!-- description, < note>with the exception of topic          -->
<!-- classification< /note> if only because such criteria     -->
<!-- are rarely used as the organizing principle for          -->
<!-- linguistic corpora or collections.                       -->
<!>
<!-- say WHAT?  you have got to be kidding.  date and author  -->
<!-- are passably common as defining criteria for collectns.  -->
<!-- ... not for corpora they aint  -->
<!-- ... Brown, LOB, and BNC don't count, I gather?           -->
<!-- Also topic description is not 'bibliographic desc' but   -->
<!-- 'subject classification' and not at all the same.        -->
<!-- Say the professionals.                                   -->
<!-- well, I spose it depends which professionals you talk to -->
<!-- it hasn't so far; neither the cataloguers nor the subj   -->
<!-- classifiers want anything to do with each other.         --></p>
<p>The core <gi>profileDesc</gi> element has three optional components,
represented by the following elements:

<list type=gloss>
<label><gi>creation</gi></label>
<item>contains information about the creation of a text.</item>
<label><gi>langUsage</gi></label>
<item>describes the languages, sublanguages, registers, dialects 
etc.
represented within a text.</item>
<label><gi>textClass</gi></label>
<item>groups information which describes the nature or topic of a 
text
in terms of a standard classification scheme, 
thesaurus, etc.</item>
</list>

These elements are further described in the remainder of this section.</p>

<p>Three other elements may also appear within the <gi>profileDesc</gi>
element, when the
additional tag set for the TEI header is in use:

<list type=gloss>
<label><gi>textDesc</gi></label>
<item>provides a description of a text in terms of its

<term>situational parameters</term>.</item>
<label><gi>particDesc</gi></label>
<item>describes the identifiable speakers, voices or other 
participants
in a linguistic interaction. </item>
<label><gi>settingDesc</gi></label>
<item>describes the setting or settings within which a language

interaction takes place, either as a prose description or 
as a
series of <gi>setting</gi> elements.</item>
</list>


For descriptions of these elements, see section
<ptr target="CCah" type="div1">.</p>

<p>Finally, the following element can appear in the <gi>profileDesc</gi>
element, when the additional tag set for transcription of primary
sources is selected:

<list type=gloss>
<label><gi>handList</gi></label>
<item>contains a series of <gi>hand</gi> elements listing the

different hands of the source.</item>
</list>


For a description of this element, see section <ptr target="PHdh">.</p>

<p>The profile description itself has the following formal definition:

<eg id=d224>
<![ CDATA [
<!-- 5.4:  The profile description                            -->
<!ELEMENT profileDesc   - -  (creation?, langUsage*, textDesc*, 
                             particDesc*, settingDesc*, 
                             handList*, textClass*)             >
<!ATTLIST profileDesc        %a.global;                         >
<!-- ... declarations from section 5.4.1                      -->
<!--     (Creation)                                           -->
<!--     go here ...                                          -->
<!-- ... declarations from section 5.4.2                      -->
<!--     (Language usage)                                     -->
<!--     go here ...                                          -->
<!-- ... declarations from section 5.4.3                      -->
<!--     (Text Classification)                                -->
<!--     go here ...                                          -->
<!-- This fragment is used in sec. 5.1.1                      -->
]]>
</eg>

<!></p>

<div3 id="hd4c"><head>Creation</head>
<p>The <gi>creation</gi> element contains phrases describing the
origin of the text, e.g. the date and place of its composition.

<list type=gloss>
<label><gi>creation</gi></label>
<item>contains information about the creation of a text.</item>
</list>


The date and place of composition are often of particular importance for
studies of linguistic variation; since such information cannot be
inferred with confidence from the bibliographic description of the copy
text, the <gi>creation</gi> element may be used to provide a consistent
location for this information:

<eg>
<![ CDATA [
 <creation>
    <date value='1992-08'>August 1992</date>
    <rs type=city>Taos, New Mexico</rs>
 </creation>
]]>
</eg></p>

<p>The formal declaration of <gi>creation</gi> is as follows:
<eg id=d224c>
<![ CDATA [
<!-- 5.4.1:  Creation                                         -->
<!ELEMENT creation      - o  (%phrase.seq;)                     >
<!ATTLIST creation           %a.global;                         >
<!-- This fragment is used in sec. 5.4                        -->
]]>
</eg>
</p></div3>

<div3 id="hd41"><head>Language Usage</head>

<p>The <gi>langUsage</gi> element is used within the
<gi>profileDesc</gi> element to describe the languages, sublanguages,
registers, dialects, etc. represented within a text.  It contains one or
more <gi>language</gi> elements, each of which takes attributes
specifying the <term>writing system</term> used (see section
<ptr target="CH">)
<!-- was:  target='p2.21'>) -->
<!-- or:   target='CH'>) -->
and the quantity of that language present in the text.  Following the
<gi>language</gi> elements, prose description may also be added to
specify further relevant information.

<list type=gloss>
<label><gi>langUsage</gi></label>
<item>describes the languages, sublanguages, registers, dialects 
etc.
represented within a text.</item>
<label><gi>language</gi></label>
<item>characterizes a single language or sublanguage used within 
a text.
Attributes include:
<list type=gloss>
<label><att>id</att></label>
<item>specifies the identifier for the <term>writing system 
declaration</term> for this language (e.g. 
<term>eng</term>, <term>fra</term>, <term>deu</term>)</item>
<label><att>wsd</att></label>
<item>specifies the entity containing the <term>writing system 
declaration</term> used for representing texts in this 
language.</item>
<label><att>usage</att></label>
<item>specifies the approximate percentage (by volume) of the 
text which uses this language.</item>
</list>
</item>
</list>
</p>

<p>Each <gi>language</gi> element links the document to the formal
writing system declaration defining that language and its script; for
that reason, its use is recommended.
The <att>wsd</att> attribute must give the name of an entity containing a
writing system declaration; typically, this will be an external file
declared in the document type declaration.  For example,
<eg>
<![ CDATA [
<!DOCTYPE TEI.2 PUBLIC "-//TEI P3//DTD Main Document Type//EN"
                       "tei2.dtd" [
  <!ENTITY mhd system 'mhd.wsd'>
  <!ENTITY nhd system 'nhd.wsd'>
]>
<tei.2>
<teiHeader> ...
    <profileDesc>
         <langUsage>
              <language id=GMH wsd=mhd>Middle High German
              <language id=DEU wsd=nhd>Modern standard German
         </langUsage>
     ...
</tei.2>
]]>
</eg></p>

<p>When two sublanguages share the same language code and writing
system declaration but are distinguished in the <gi>langUsage</gi>
element, only one of the <gi>language</gi> elements should bear the
<att>id</att> attribute:
<!-- I'm a bit hazy about the implications of that too: presumably -->
<!-- all will be made clear in the wsd chapter? -->
<!-- if not clear here, i doubt it will be clearer then. -msm -->
<!-- The only implications I see are 1 that nothing in the    -->
<!-- declarations can point at an individual sublanguage,     -->
<!-- only to something that has its own WSD, 2 that any       -->
<!-- processor which cares about identifying languages        -->
<!-- (wsds) in use must be aware that some LANGUAGE           -->
<!-- elements don't have IDs, and these must be ignored or    -->
<!-- 'merged' somehow with LANGUAGE elements which do have    -->
<!-- IDs and which use the same wsd.  -msm                    -->

<eg><![ CDATA[
<langUsage>
   <language id=FR wsd=wsd.fr usage=60>Qu&eacute;becois
   <language id=EN wsd=wsd.en usage=20>Canadian business English
   <language       wsd=wsd.en usage=20>British English
</langUsage>
]]>
</eg>

or, less formally,

<eg><![ CDATA[
   <langUsage>
   <language id=FR wsd=wsd.fr>
   <language id=EN wsd=wsd.en>
     Approximately two-thirds of the text is in
     Qu&eacute;becois, the remainder being equally
     divided between Canadian business English and
     British English.
   </langUsage>
]]>
</eg></p>

<p>The <gi>langUsage</gi> and <gi>language</gi> elements have the
following formal definitions:
<eg id=d2241>
<![ CDATA [
<!-- 5.4.2:  Language usage                                   -->
<!ELEMENT langUsage     - o  (p | language)+                    >
<!ATTLIST langUsage          %a.global;
                             %a.declarable;                     >
<!ELEMENT language      - o  (%phrase.seq)                      >
<!ATTLIST language           %a.analysis;
                             %a.linking;
                             %a.terminology;
          lang               IDREF               %INHERITED
          rend               CDATA               #IMPLIED
          n                  CDATA               #IMPLIED
          id                 ID                  #IMPLIED
          wsd                ENTITY              #IMPLIED
          usage              NUMBER              #IMPLIED       >
<!-- This fragment is used in sec. 5.4                        -->
]]>
</eg>
</p></div3>

<div3 id="hd43"><head>The Text Classification</head>

<p>The second component of the core <gi>profileDesc</gi> element is the
<gi>textClass</gi> element. This element is used to classify a text
according to one or more of the following methods:

<list type="bullets">
<item>by reference to a recognized international classification such as
the Dewey Decimal Classification, the Universal Decimal Classification,
the Colon Classification, the Library of Congress Classification, or any
other system widely used in library and documentation work</item>
<item>by providing a set of keywords, as provided for example by British
Library or Library of Congress Cataloguing in Publication data</item>
<item>by referencing any other taxonomy of text categories recognized in
the field concerned, or peculiar to the material in hand; this may
include one based on recurring sets of values for the situational
parameters defined in section <ptr target="ccahtd">, or the demographic
elements described in section <ptr target="CCahpa"></item>
</list>

The last of these may be particularly important for dealing with
existing corpora or collections, both as a means of avoiding the expense
or inconvenience of reclassification and as a means of documenting
the organizing principles of such materials.</p>

<p>The following tags are provided for this purpose:
<list type=gloss>
<label><gi>keywords</gi></label>
<item>contains a list of keywords or phrases identifying the 
topic or
nature of a text.
Attributes include:
<list type=gloss>
<label><att>scheme</att></label>
<item>identifies the controlled vocabulary within which the set 
of keywords concerned is defined.</item>
</list>
</item>
<label><gi>classCode</gi></label>
<item>contains the classification code used for this text in some
standard classification system.
Attributes include:
<list type=gloss>
<label><att>scheme</att></label>
<item>identifies the classification system or taxonomy in use.</item>
</list>
</item>
<label><gi>catRef</gi></label>
<item>specifies one or more defined categories
within some 
taxonomy or text typology.
Attributes include:
<list type=gloss>
<label><att>target</att></label>
<item>identifies the categories concerned</item>
</list>
</item>
</list>
</p>

<p>The <gi>keywords</gi> element simply categorizes an individual text
by supplying a list of keywords which may describe its topic or subject
matter, its form, date, etc.  In some schemes, the order of items in the
list is significant, for example, from major topic to minor; in others,
the list has an organized substructure of its own.  No recommendations
are made here as to which method is to be preferred.  Wherever possible,
such keywords should be taken from a recognized source, such as the
British Library/Library of Congress Cataloguing in Publication data in
the case of printed books, or a published thesaurus appropriate to the
field.</p>

<p>The <att>scheme</att> attribute should be used to indicate the source
of the keywords used.  This is done by supplying the value used for the
<att>id</att> attribute of a <gi>taxonomy</gi> element within which
further details of the source concerned may be found.  The
<gi>taxonomy</gi> element occurs in the <gi>classDecl</gi> part of the
encoding declarations within the TEI Header and is described in section
<ptr target="hd55">.  For example:

<eg><![ CDATA[
 <keywords scheme=LCSH>
   <list><item>Data base management</item>
         <item>SQL (Computer program language)</item>
   </list>
 </keywords>
]]>
<!-- LC subject tracings on C J Date, A Guide to the SQL      -->
<!-- Standard 2d ed. (Reading:  Addison-Wesley, 1989), from   -->
<!-- CIP data on overleaf.                                    -->
</eg>
<eg><![ CDATA[
 <keywords scheme=LCSH>
   <list>
   <item>English literature -- History and criticism --
         Data processing.</item>
   <item>English literature -- History and criticism --
         Theory, etc.</item>
   <item>English language -- Style -- Data processing.</item>
   <item>Style, Literary -- Data processing.</item>
   </list>
 </keywords>
]]>
</eg>
<!-- LC subject tracings on R Potter, ed., Literary           -->
<!-- Computing and Literary Criticism:  Theoretical and       -->
<!-- Practical Essays on Theme and Rhetoric (Philadelphia,    -->
<!-- U Penn, 1989), from CIP data on title overleaf.          --></p>

<p>The <gi>classCode</gi> element also categorizes an individual text,
by supplying a numerical or other code used in a recognized
classification scheme, such as the Dewey Decimal Classification.  The
<att>scheme</att> attribute is used to indicate the source of the
classification scheme, in the same way as for the <gi>keywords</gi>
element, as in the following example:

<eg><![ CDATA[
 <classCode scheme=DDC19>005.756</>
 <classCode scheme=LC>QA76.9</>
]]>
</eg>
<!-- subject classifications from Date, Guide to SQL Std      -->
<eg><![ CDATA[
 <classCode scheme=DDC19>820.285</>
 <classCode scheme=LC>PR21</>
]]>
</eg>
<!-- subject classifications from Potter, Lit Comp & Lit Crit --></p>

<p>The <gi>catRef</gi> element categorizes an individual text by
pointing to one or more <gi>category</gi> elements.  The
<gi>category</gi> element (which is fully described in section <ptr
target="hd55">) holds information about a particular classification or
category within a given taxonomy.  Each such category must have a unique
identifier, which may be supplied as the value of the <att>target</att>
attribute for <gi>catRef</gi> elements which are regarded as falling
within the category indicated.</p>

<p>A text may, of course, fall into more than one category, in which
case more than one identifier will be supplied as the value for
the <att>target</att> attribute on the <gi>catRef</gi> element, as
in the following example:

<eg><![ CDATA[
 <catRef target="B1 B2 B5">
]]>
</eg></p>

<p>Where more than one descriptive taxonomy is used to characterize the
texts in a corpus or collection, the <att>scheme</att> attribute
should be supplied to specify the taxonomy to which the categories
identified by the target attribute belong. For example,

<eg><![ CDATA[
 <catRef scheme='Brown' target='B12 B15'>
 <catRef scheme='SUC' target='A45'>
]]>
</eg>

Here the same text has been classified as of categories <q>B12</q> and
<q>B15</q> within the Brown classification scheme, and as of category
<q>A45</q> within the SUC classification scheme.</p>

<p>The distinction between the <gi>catRef</gi> and <gi>classCode</gi>
elements is that the values used as identifying codes <emph>must </emph>
be defined somewhere within the header for the former, but not the
latter.</p>

<p>The elements described in this section have the following formal
definitions:
<eg id=d2243>
<![ CDATA [
<!-- 5.4.3:  Text Classification                              -->
<!ELEMENT textClass     - -  ((classCode | catRef | keywords)* 
                             )                                  >
<!ATTLIST textClass          %a.global;
                             %a.declarable;                     >
<!ELEMENT keywords      - o  (term+ | list)                     >
<!ATTLIST keywords           %a.global;
          scheme             IDREF               #IMPLIED       >
<!ELEMENT classCode     - -  (%phrase.seq)                      >
<!ATTLIST classCode          %a.global;
          scheme             IDREF               #IMPLIED       >
<!ELEMENT catRef        - o  EMPTY                              >
<!ATTLIST catRef             %a.global;
          scheme             IDREF               #IMPLIED
          target             IDREFS              #REQUIRED      >
<!-- This fragment is used in sec. 5.4                        -->
]]>
</eg>

</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:("/home/tei/P3/Master/Odds/p2.odd" "TEI.1" "TEXT" "BODY" "DIV1")
sgml-omittag:t
sgml-shorttag:t
End:
-->

<!-- $Id: p2hd6.odd,v 1.5 1994/03/24 22:14:56 msmcq Exp $ -->
<!-- $Log: p2hd6.odd,v $
# Revision 1.5  1994/03/24  22:14:56  msmcq
# typo corrections from David Barnard, Peter Robinson, and others
#
# Revision 1.4  1994/01/04  13:02:04  lou
# change resp to respstmt
#
# Revision 1.3  1993/08/18  21:31:24  msmcq
# name shift (role/resp, resp/respStmt) on account of DR role
#
# Revision 1.2  1993/06/22  14:29:49  msmcq
# Changes post Eynsham and for DTD generation
# -->
<!-- Revisions:                                               -->
<!-- 94-03-22 : CMSMcQ : typos, TEI - &tei, code, ident tags  -->
<!-- 93-08-18 : MSM : new names for respStmt, role/resp       -->
<!-- 93-06-01 : MSM : change change log post Eynsham          -->
<!-- 93-02-10 : MSM : update xref targets                     -->
<!-- 92-08-17 : MSM : change BY to NAME                       -->
<!-- 25 Jul 92 : MSM : names updated, ids updated             -->
<div2 id='hd6'><head>The Revision Description</head>

<p>The final subelement of the TEI header, the <gi>revisionDesc</gi>
element, provides a detailed change log in which each change made to a
text may be recorded.  Its use is optional but highly recommended.
It provides essential information for the administration of large
numbers of files which are being updated, corrected, or otherwise
modified as well as extremely useful documentation for files being
passed from researcher to researcher or system to system. Without
change logs, it is easy to confuse different versions of a file, or to
remain unaware of small but important changes made in the file by some
earlier link in the chain of distribution.  No change should be made in
any TEI-conformant file without corresponding entries being made in the
change log.

<list type=gloss>
<label><gi>revisionDesc</gi></label>
<item>summarizes the revision history for a file.</item>
<label><gi>change</gi></label>
<item>summarizes a particular change or correction made
to a 
particular version of an electronic text which is
shared 
between several researchers.</item>
</list>


<p>The log consists of a list of entries, one for each change.  This
may be encoded using either the regular <gi>list</gi> element,
as described in section <ptr target='COli'> or as a series of
<!-- was:  target='p2.233'> -->
<!-- or :  target='COlist'> -->
special purpose <gi>change</gi> elements, each of which has
the following constituents:
<list type=gloss>
<label><gi>date</gi></label>
<item>contains a date in any format.</item>
<label><gi>respStmt</gi></label>
<item>supplies a statement of responsibility for someone 
responsible for
the intellectual content of a text, 
edition, recording, or series, where
the specialized 
elements for authors, editors, etc. do
not suffice or do 
not apply.</item>
<label><gi>item</gi></label>
<item>contains one component of a list.</item>
</list>

The <gi>date</gi> element indicates the date of the change.
The <gi>respStmt</gi> element indicates who made the change, and in what
role.
The <gi>item</gi> element indicates what change was made; it can
range from a simple phrase to a series of paragraphs.
If a number is to be associated with one or more changes (for
example, a revision number), use the global <att>n</att>
attribute on the <gi>change</gi> element to supply it.

<p>It is recommended to give changes in reverse chronological order,
most recent first.

<!-- if i had time i'd replace by, what, date with            -->
<!-- name, date, item.  perhaps in p3.  -msm                  -->
<!-- i agree that BY could usefully be replaced by NAME. Less clear -->
<!-- about ITEM, since this is already implied by use of LIST -lb -->
<p>For example:
<!-- is this example perhaps not a bit over long? -->
<!-- possibly, i just took a real one from a file -->
<eg>
<![ CDATA [
<revisionDesc>
<change><date>6/3/91:</date>
        <respStmt><name>EMB</name><resp>ed.</></respStmt>
        <item> < > changes completed.</item>
<change><date>5/25/91:</date>
        <respStmt><name>EMB</name><resp>ed.</></respStmt>
        <item>File format updated.</item>
<change><date>9/3/90:</date>
        <respStmt><name>EMB</name><resp>ed.</></respStmt>
        <item>Changes to make a prettier printed version.</item>
<change><date>5/25/90:</date>
        <respStmt><name>EMB</name><resp>ed.</></respStmt>
        <item>Stuart's corrections entered</item>
<change><date>2/90: </date>
        <respStmt><name>N.N.</name><resp>admin.</></respStmt>
        <item>Sent to Stuart Curran for proofreading.</item>
<change><date>1/22/90:</date>
        <respStmt><name>N.N.</name><resp>data entry</></respStmt>
        <item>Corrections made to file;</item>
<change><date>10/89:</date>
        <respStmt><name>John G. Fitzgerald, Julia M. Deisler
            and Deborah Hirsch.</name><resp>staff</></respStmt>
        <item>Proofread.</item>
<change><date>8/89:</date>
        <respStmt><name>Amy E. Frisch</><resp>data entry</></respStmt>
        <item>Input begun</item>
</revisionDesc>
]]>
</eg>

<p>The formal definition of the <gi>revisionDesc</gi> element is thus as
follows:

<eg id=d226>
<![ CDATA [
<!-- 5.5:  The Revision Description                           -->
<!ELEMENT revisionDesc  - -  (list | change+)                   >
<!ATTLIST revisionDesc       %a.global;                         >
<!ELEMENT change        - O  (date, respStmt+, item)            >
<!ATTLIST change             %a.global;                         >
<!-- respStmt, item, and date are declared in teicore2.       -->


<!-- This fragment is used in sec. 5.1.1                      -->
]]>
</eg>

<!>

<!-- $Id: p2hd7.odd,v 1.5 1998/01/28 11:09:58 cmsmcq Exp $ -->
<!-- $Log: p2hd7.odd,v $
# Revision 1.5  1998/01/28  11:09:58  cmsmcq
# LB changes of January 1998
#
# Revision 1.4  1994/04/08  18:54:36  msmcq
# Last-second fixes for P3
#
# Revision 1.3  1994/03/24  22:14:56  msmcq
# typo corrections from David Barnard, Peter Robinson, and others
# -->
<!-- Revisions:                                               -->
<!-- 10 jan 98 : LB : correcting egs -->
<!-- 94-04-08 : MSM : change id of ref sectino                -->
<!-- 94-03-29 : MSM : change CITY to pubPlace                 -->
<!-- 94-03-22 : CMSMcQ : typos, TEI - &tei, code, ident tags  -->
<!-- 93-08-18 : MSM : new names for respStmt, role/resp       -->
<!-- 93-06-01 : MSM : normalize teiHeader, citn               -->
<!-- 93-02-10 : MSM : update xref targets                     -->
<!-- 92-08-19 : MSM : correct error in long example           -->
<!-- 92-08-19 : MSM : modify full header example              -->
<!-- 92-08-18 : MSM : check ]]                                -->
<!-- 92-08-17 : MSM : major additions to recommended hdr      -->
<!-- 3 Aug 92 : LB : one or two trivial changes               -->
<!-- 25 Jul 92 : MSM : names updated, ids updated             -->
<div2 id='hd7'><head>Minimal and Recommended Headers

<p>The TEI header allows for the provision of a very large amount of
information concerning the text itself, its source, encodings
and revisions of it, as well as a wealth of descriptive information
such as the languages it uses and the situation within which it
was produced, the setting and identity of participants within it.
This diversity and richness reflects the diversity of uses to which
it is envisaged that electronic texts conforming to these Guidelines
will be put. It is emphatically <emph>not</emph> intended that all of the
elements described above should be present in every TEI Header.

<p>The amount of encoding in a header will depend both on the nature
and the intended use of the text. At one extreme, an encoder may
expect that the header will be needed only to provide a bibliographic
identification of the text adequate to local needs. At the other,
wishing to ensure that their texts can be used for the widest
range of applications, encoders will want to document as explicitly as
possible both bibliographic and descriptive information, in such a
way that no prior or ancillary knowledge about the text is needed
in order to process it. The header in such a case will be very
full, approximating to the kind of documentation often supplied
in the form of a manual. Most texts will lie somewhere between
these extremes; textual corpora in particular will tend more
to the latter extreme.

<p>For each element discussed above, an indication is given in the
general alphabetical index (section <ptr target=p2refs>) as to whether
its encoding is regarded in general as required, recommended or
optional.  Clearly, all elements relating to descriptive matters such as
text classification or description must be optional in the general case,
though for certain kinds of analysis their presence will be mandatory.
This section therefore confines itself to demonstrating the minimal and
recommended levels of encoding of the bibliographic information held by
the TEI header.

<p>Supplying only the minimal level of encoding required, the
TEI header of a single printed text might look like the following
example:

<eg><![ CDATA[
<teiHeader>
  <fileDesc>
    <titleStmt>
        <title>Thomas Paine: Common sense, a
            machine-readable transcript</title>
        <respStmt><resp>compiled by</resp>
             <name>Jon K Adams</name>
        </respStmt>
     </titleStmt>
     <publicationStmt>
        <distributor>Oxford Text Archive</distributor>
     </publicationStmt>
     <sourceDesc>
        <bibl>The complete writings of Thomas Paine,
           collected and edited by Phillip S. Foner
           (New York, Citadel Press, 1945)
        </bibl>
      </sourceDesc>
   </fileDesc>
</teiHeader>
]]>
</eg>

<p>The only mandatory component of the TEI Header is the
<gi>fileDesc</gi> element.  Within this, <gi>titleStmt</gi>,
<gi>publicationStmt</gi> and <gi>sourceDesc</gi> are all required
constituents.  Within the title statement, a title is required, and an
author should be specified, even if it is <code>unknown</code>, as
should some additional statement of responsibility, here given by the
<gi>respStmt</gi> element.  Within the <gi>publicationStmt</gi>, a
publisher, distributor or other agency responsible for the file must be
specified.  Finally, the source description should contain at the least
a loosely structured bibliographic citation identifying the source of
the electronic text if (as is usually the case) there is one.

<p>We now present the same example header, expanded to include
additionally recommended information, adequate to most bibliographic
purposes, in particular to allow for the creation of an AACR2-conformant
bibliographic record.  We have also added information about the
encoding principles used in this (imaginary) encoding, about the
text itself (in the form of Library of Congress subject headings),
and about the revision of the file.

<!-- Bibliographic reference to a real OTA text.              -->
<!-- EncodingDesc mostly from description of                  -->
<!-- that text, but improvised in part.                       -->
<!-- Revision desc is imaginary                               -->
<eg><![ CDATA[
<teiHeader>
<fileDesc>
    <titleStmt>
         <title>Common sense, a machine-readable transcript</title>
         <author>Paine, Thomas (1737-1809)</author>
         <respStmt><resp>compiled by</resp>
               <name>Jon K Adams</name>
         </respStmt>
    </titleStmt>
    <editionStmt>
         <edition><date>1986</date></edition>
    </editionStmt>
    <publicationStmt>
         <distributor>Oxford Text Archive.</distributor>
         <address><addrLine>Oxford University Computing Services,</addrLine>
             <addrLine>13 Banbury Road,</addrLine>
             <addrLine>Oxford OX2 6RB,</addrLine>
              <addrLine>UK</addrLine>
         </address>
    </publicationStmt>
    <notesStmt>
         <note>Brief notes on the text are in a
               supplementary file.</note>
    </notesStmt>
    <sourceDesc>
         <biblStruct>
         <monogr><editor>Foner, Philip S.</editor>
              <title>The collected writings of Thomas Paine</title>
              <imprint>
                   <pubPlace>New York</pubPlace>
                   <publisher>Citadel Press</publisher>
                   <date>1945</date>
              </imprint>
         </monogr></biblStruct>
    </sourceDesc>
</fileDesc>
<encodingDesc>
    <samplingDecl><p>Editorial notes in the Foner edition have not
         been reproduced.
         <p>Blank lines and multiple blank spaces, including paragraph
         indents, have not been preserved.
    <editorialDecl>
         <correction status=high method=silent><p>The following errors
              in the Foner edition have been corrected:
              <list>
              <item>p.  13 l.  7 cotemporaries   contemporaries
              <item>p.  28 l. 26 [comma]         [period]
              <item>p.  84 l.  4 kin             kind
              <item>p.  95 l.  1 stuggle         struggle
              <item>p. 101 l.  4 certainy        certainty
              <item>p. 167 l.  6 than            that
              <item>p. 209 l. 24 publshed        published
              </list>
         <normalization><p>No normalization beyond that performed
              by Foner, if any.
         <quotation marks=all form=std><p>All double quotation marks
              rendered with ", all single quotation marks with
              apostrophe.
         <hyphenation eol=none><p>Hyphenated words that appear at the
              end of the line in the Foner edition have been reformed.
         <stdVals><p>Standard date values are given in ISO form:
              yyyy-mm-dd.
         <interpretation><p>Compound proper names are marked.
              <p>Dates are marked.
              <p>Italics are recorded without interpretation.
    </editorialDecl>
    <classDecl>
         <taxonomy id='LCSH'>
              <bibl>Library of Congress Subject Headings</></>
         <taxonomy id='LC'>
              <bibl>Library of Congress Classification</></>
    </classDecl>
</encodingDesc>
<profileDesc>
    <creation><date>1774</date></creation>
    <langUsage>
         <language id=EN wsd='english' usage=100>English.</language>
    </langUsage>
    <textClass>
         <keywords scheme='LCSH'>
              <list>
                   <item>Political science</item>
                   <item>United States -- Politics and government --
                         Revolution, 1775-1783</item>
              </list>
         </keywords>
         <classCode scheme='LC'>JC 177</>
    </textClass>
</profileDesc>
<revisionDesc>
<change><date>1996-01-22</date>
    <respStmt><resp>ed</resp><name>CMSMcQ</name></respStmt>
    <item>finished proofreading</item>
</change>
<change><date>1995-10-30</date>
    <respStmt><resp>ed</resp><name>L.B. </name></respStmt>
    <item>finished proofreading</item>
</change>
<change><date>1995-07-20</date>
    <respStmt><resp>ed</resp><name>R.G. </name></respStmt>
    <item>finished proofreading</item>
</change>
<change><date>1995-07-04</date>
    <respStmt><resp>ed</resp><name>R.G. </name></respStmt>
    <item>finished data entry</item>
</change>
<change><date>1995-01-15</date>
     <respStmt><resp>ed</resp><name>R.G. </name></respStmt>
     <item>began data entry</item>
</change>
</revisionDesc>
</teiHeader>
]]>
</eg>

<!-- this is what Rich suggested: me, I think the  -->
<!-- contents of the supplementary file should be  -->
<!-- decanted into the encodingDesc  (LB)          -->
<!-- Do we agree that this really is an acceptable -->
<!-- minimal recommendation?                       -->
<!-- Not at all:  it ought to have encodingDesc,   -->
<!-- profileDesc, and revisionDesc too.            -->
<!-- Which I have now added.  -msm                 -->

<p>Many other examples of recommended usage for the elements discussed
in this chapter are provided here, in the reference index and in the
associated tutorials.


<!-- $Id: p2hd8.odd,v 1.2 1994/03/24 22:14:56 msmcq Exp $ -->
<!-- $Log: p2hd8.odd,v $
# Revision 1.2  1994/03/24  22:14:56  msmcq
# typo corrections from David Barnard, Peter Robinson, and others
# -->
<!-- P2HD8 : Note for cataloguers                             -->
<!-- Revisions:                                               -->
<!-- 94-03-22 : CMSMcQ : typos, TEI - &tei, code, ident tags  -->
<!-- 25 Jul 92 : CMSMcQ : separated from p2.226               -->
<!-- 25 Jul 92 : MSM : names updated, ids updated             -->

<div2 id=hd8><head>Note for Library Cataloguers</head>
<!-- was id='p2.228' -->

<p>A strong motivation in preparing the material in this chapter was to
provide in the TEI file header a viable chief source of information
for cataloguing the machine-readable data file.  The file header is not
a library catalogue record, and so will not make all of the distinctions
essential in standard library work.  It also includes much information
generally excluded from standard bibliographic descriptions.  It is the
intention of the developers, however, to ensure that the information
required for a catalogue record be retrievable from the TEI file
header, and moreover that the mapping from the one to the other be as
simple and straightforward as possible.  Where the correspondence is not
obvious, it may prove useful to consult one of the works which were
influential in developing the content of the TEI file header.  These
include:

<list type=gloss>

<label>ISBD(G) <item>The International Standard Book Description
(General) is an international standard setting out what information
should be recorded in a description of a bibliographical item.  There
are also separate ISBDs covering different types of material, e.g.
ISBD(M) for monographs, ISBD(CF) for computer files.  These separate
ISBDs follow the same general scheme as the main ISBD(G), but provide
appropriate interpretations for the specific materials under
consideration.

<label>AACR2 <item>The Anglo-American Cataloguing Rules (second edition)
were published in 1978, with a revision appearing in 1988.  The AACR2
provides guidelines for the construction of catalogues in general
libraries.  AACR2 is explicitly based on the general framework of the
ISBD(G), and the subsidiary ISBDs.  It gives a description of how to
catalogue items according to the ISBDs, and how to construct indexes and
catalogue cross references.

<label>ANSI Z.39.29 <item>ANSI Z.39.29 is an American national standard
governing bibliographic references for use in bibliographies,
end-of-work lists, references in abstracting and indexing publications,
and outputs from computerized bibliographic data bases.  This standard
has however now been withdrawn, pending substantial revision.  The
international standard which covers the same area is ISO 690:  1987.
Other relevant standards include BS 1629:  1989, BS 5605:  1978, and BS
6371:1983.

</list>

<!-- &p2.hdt1; &p2.hdt2; &p2.hdt3; &p2.hdt4;                  -->
<!-- &hdtags; -->
            <!-- 5 The TEI Header -->
