<!-- $Id: p2ab.odd,v 1.12 1999/05/18 10:24:14 tei Exp $ -->
<!--*
    * $Log: p2ab.odd,v $
    * Revision 1.12  1999/05/18 10:24:14  tei
    * Turned qs into mentioned
    *
    * Revision 1.11  1998/01/29 17:48:49  tei
    * Normalize SGML, fix log keyword
    *
    * Revision 1.10  98/01/28  11:09:58  cmsmcq
    * LB changes of January 1998
    *
    * Revision 1.9  1994/04/08  18:54:36  msmcq
    * Last-second fixes for P3
    *
    * Revision 1.8  1994/03/28  17:30:26  msmcq
    * suppress stray end-tag for P
    *
    * Revision 1.7  1994/03/24  22:19:17  msmcq
    * Typographic errors found by David Barnard et al. corrected,
    * some stylistic changes, perhaps improvements.
    *
    * Revision 1.6  1994/03/21  14:12:07  lou
    * second mass typo clearup
    *
    * Revision 1.5  1994/01/21  18:06:47  lou
    * Revised and fixed up version
    *
    * Revision 1.3  1993/09/15  22:48:30  msmcq
    * new file, revised by NI and CH
    *
    * Revision 1.2  1993/07/29  21:04:15  msmcq
    * 1.2 is new version from CH, NI
    *-->
<!-- Subject: P2 chapter(s) AB                                -->
<!-- Revisions:                                               -->
<!-- 7 Jan 98 : LB : removed "draft" -->
<!-- 94-04-07 : MSM : minor stylistic fixes                   -->
<!-- 94-04-07 : MSM : cosmetic change to heading              -->
<!-- 94-03-27 : MSM : delete stray end-tag for P              -->
<!-- 93-03-21 : MSM: tidied up after the tidying up, fixed    -->
<!--                 typos and formatting glitches found by   -->
<!--                 DB, SJ, CH, EB                           -->
<!--                 and Paul, Susie, Carole, Elizabeth       -->
<!--                     and Caleb, at the WWP                -->
<!-- 4 jan 94: LB : tidied up, deleted unassimilated stuff -->
<!-- 19 dec 93: LB : fixd a cross ref -->
<!-- 93-09-13 : MSM : Some changes to avoid dup ids           -->
<!-- 93-09-13 : MSM : numerous SGML corrections               -->
<!-- 93-07-29 : MSM : minor cleanup of file as sent by CH     -->
<!--                  add RCS id, log                         -->
<!-- 02.06.93 : CH: Made file from P2 13.04.93 version,       -->
<!--            added comments from Eynsham, added changes    -->
<!--             made by NI and CH                            -->
<!-- 05.06.93 : NI: Further revisions                         -->
<!-- 11.06.93 : CH: Further revision, extensive rearrangement -->
<!-- 20.06.93 : CH: Further revision after talk with NI       -->
<!-- 21.07.93 : CH: Final revision, last changes from NI      -->


<div1 id="AB" n="1"><head>About These Guidelines</head>


<!-- <div3 id=ABwho><head>Who These Guidelines Are For</head> -->

<!-- <note place=inline ed=CH>New heading, not quite happy    -->
<!-- with it.  Other possibilities:  "Status of this          -->
<!-- Document", "Use of this Document", ... or perhaps we     -->
<!-- need no headline here?</note> CUT HEADING (lb)           -->

<p>These Guidelines have been developed by the Text Encoding Initiative
(TEI); see <ptr target="ABtei">.  They are addressed to anyone who
works with any text in electronic form.</p>

<p>They provide means of representing those features of a text which
need to be identified explicitly in order to facilitate processing of
the text by computer programs.  In particular, they specify a set of
markers (or <term>tag</term>s) which may be inserted in the electronic
representation of the text, in order to mark the text structure and
other textual features of interest.  Without such explicit markers, many
important features remain difficult to locate by mechanical means such
as computer programs, and thus difficult to process effectively.  The
process of inserting such explicit markers for implicit textual features
is often called <socalled>markup</socalled> or
<socalled>tagging</socalled>, and the term <term>encoding scheme</term>
or <term>markup language</term> denotes the rules which govern the use
of markup in a set of encodings.

<!-- <note ed=NI> I made Claus' change </note> <note          -->
<!-- ed=CH>On second thought:  Perhaps delete "otherwise      -->
<!-- implicit" in the first sentence?  </note> </p>           --></p>

<p>The Guidelines formulated in this document are intended for use in
interchange between individuals and research groups using different
programs and computer systems over a broad range of applications.  Since
they contain an inventory of the features most often found useful for
text processing, the Guidelines also provide help to those creating
texts in electronic form.

<!--      <note ed=CH>Was: "help to those creating electronic -->
<!--      texts."</note> Reverted (LB -->

They can also be used for the local storage of text which is to be
processed with multiple software packages requiring different input
formats.  </p>

<p>The Guidelines apply to texts in any natural language, of any date,
in any literary genre or text type, without restriction on form or
content.  They treat both continuous materials (<socalled>running
text</socalled>) and discontinuous materials such as dictionaries and
linguistic corpora.  Though principally directed to the needs of the
scholarly research community, the Guidelines are not restricted to
esoteric academic applications.  They should also be useful for
librarians who maintain and document electronic materials, as well as
for publishers and others creating or distributing electronic texts.
Although they focus on problems of representing in electronic form texts
which already exist in traditional media, these Guidelines should also
be useful for the creation of electronic texts.

<!-- <note ed=NI> I tried to incorporate Claus' comment but   -->
<!-- have a problem, since it ends with exactly the same      -->
<!-- point as that at the end of the preceding paragraph.     -->
<!-- Cannot think of a solution at the moment.  Also tried    -->
<!-- to fix this paragraph generally.</note>                  -->

<!-- <note ed=CH>Think I solved the problem.  Divided the     -->
<!-- para into two different paras, and revised further.      -->
<!-- Recent postings on TEI-L (or was it TEI-TECH), e.g. by   -->
<!-- Craig Ogg, Origami Ltd, confirmes the importance of the  -->
<!-- last point about creation of "new" texts vs. capture or  -->
<!-- representation of texts in traditional media.  </note>   -->

<!-- <note ed=CH>Should we add a para here saying that there  -->
<!-- are some problems not addressed by these Guidelines      -->
<!-- which will be pursued in future developments, with       -->
<!-- reference to that section?</note> </p>                   -->

They are adequate to, but not limited by, existing practices.</p>

<p>The rules and recommendations made in the these Guidelines conform to
ISO 8879, which defines the Standard Generalized Markup Language (SGML),
and make reference to ISO 646, which defines a standard seven-bit
character set in terms of which the recommendations on character-level
interchange are formulated.  For more information on SGML see chapter
<ptr target="SG" type="div1">.  </p>

<p>This document provides the authoritative statement of the
requirements and usage of the TEI encoding scheme.  Although it
includes numerous small examples, it must be stressed that it is
intended as a reference manual and that readers unfamiliar with SGML or
text markup in general will find it difficult to learn the encoding
scheme by reading this document alone.</p>

<!-- <note ed=CH>Was:  "is intended to provide an"</note> -->

<p>This document will be complemented by a series of tutorials in text
encoding (document TEI U1 et seq.) and a case book of extended examples
with discussion of the rationale for various markup choices (TEI T1).
<note place="foot">TEI documents bear identifying numbers which indicate
the provenance of the document (here simply <mentioned>TEI</mentioned>, in other cases
the TEI work group number, e.g.  <mentioned>TEI AI5</mentioned>), the type of document
(here <mentioned>U</mentioned> and <mentioned>T</mentioned>, meaning <gloss>users' guide</gloss> or
<gloss>users' manual</gloss> and <gloss>sample text(s)</gloss>), and a
sequential number.  The TEI document number of the document in hand is
TEI P3 (for <gloss>TEI public proposal number 3</gloss>).</note>
Readers seeking an introduction to text markup and the use of the TEI
encoding scheme in a specific area should consult an appropriate
tutorial; those already familiar with the scheme and interested in
seeing examples of its application should consult the case book.</p>

<!-- following para is new (LB) -->

<p>The remainder of this chapter comprises three sections.  The first
gives an overview of the structure and notational conventions used
throughout the document.  The second enumerates the design principles
underlying the TEI scheme and the application environments in which it
may be found useful.  Finally, the third section gives a brief account
of the origins and development of the Text Encoding Initiative itself.</p>

<div2><head>Structure and Notational Conventions of this Document</head>

<div3 id="ABsum"><head>Structure</head>

<p>Part I provides some relevant background information about the
Guidelines themselves (in this chapter); a brief technical
review of SGML (chapter <ptr target="SG" type="div1">); and a description
of how the TEI document type definition (DTD) is organized (chapter
<ptr target="ST" type="div1">).

<!-- <note ed=CH> This is the first time the term 'document   -->
<!-- type declaration' occurs.  Next para mentions            -->
<!-- 'definition for default structure', two paras below the  -->
<!-- abbrev 'DTD' occurs for the first time.  In one of       -->
<!-- these places the clarificatory note about document type  -->
<!-- definitions, document type declarations, and DTDs        -->
<!-- (suggested by MSMQ) should be added.  </note> </p>       --></p>

<p>Part II provides a systematic treatment of issues common to all
text types: character representation (chapter
<ptr target="CH" type="div1">); in-file documentation of the text
(chapter <ptr target="HD" type="div1">); tags for text features found
in all sorts of text: lists, notes, emphasis, quotations,
cross-references, technical terms, names, dates, numbers, etc.
(chapter <ptr target="CO" type="div1">); and a definition for the
default structure of all TEI documents (chapter
<ptr target="DS">).</p>

<p>Part III documents various <term>base tag sets</term>: these
include specialized tags for prose, for verse, for drama and other
performance materials, for spoken materials, as well as for letters
and memoranda, printed dictionaries, and terminological data.
Additional sections discuss user-defined and mixed base tag sets. An
instance of the TEI DTD must use one and only one base tag set,
unless one of the <socalled>mixed</socalled> bases is used.</p>

<p>Part IV documents various <term>additional tag sets</term>, which
may be included or excluded, as appropriate. Topics covered include
a variety of approaches to the analysis and interpretation of texts,
and include representations for hypertextual links and other
non-hierarchic structures, as well as specialized tags for the
encoding of critical editions and language corpora.

<!-- <note ed=CH>Was:  "for the encoding of physical description, -->
<!-- critical editions, and language corpora."  </note> </p> --></p>

<p>Part V defines certain specialized <term>auxiliary document
types</term>, used to encode information about the way that texts have
been encoded, specifically:  the TEI header regarded as a distinct
document; the TEI Writing System Declaration; the Feature System
declaration; and the Tag Set Documentation.</p>

<p>Part VI contains a number of technical discussions of a more
specialist interest.  Topics covered include the notion of formal
<term>conformance</term> to the TEI Guidelines; the controlled
user-modification of the TEI DTD; practical aspects of the use of
TEI markup both in local processing and in interchange; and the
relationship of TEI markup to other markup standards.</p>

<p>Part VII consists of an alphabetical reference list of all elements
and element classes defined in the TEI encoding scheme.</p>

<p>Part VIII provides further reference material:  specifically, a
description of how to obtain current versions of the full TEI DTDs and
the set of standard Writing System Declarations, a sample Feature System
Declaration for basic grammatical annotation, sample tag documentation,
and a formal grammar for the subset of SGML used in the TEI
interchange format.</p>

<p>In the back matter, a bibliography lists works cited in the text of
the Guidelines.  A mechanically generated index is also provided, which
can serve, it is hoped, as a finding aid for the use of the Guidelines.</p></div3>

<div3 id="ABnot"><head>Notational Conventions</head>

<!-- <note place=inline ed=CH>Was:  "Notational Conventions   -->
<!-- Used in This Draft"</note>                               -->

<p>This section describes the typographic and stylistic conventions used
throughout this document.  The use of many terms and concepts which have
not yet been defined is unavoidable in this section.  All such terms and
concepts will be explained in later chapters of Part I.

<!--      <note ed=CH> Remark in parantheses suggested by JL -->
<!--      </note> </p> --></p>

<p>When SGML elements are mentioned in the text, the mentions take the
form <gi tei="no">name</gi>, where <mentioned>name</mentioned> is the <term>generic
identifier</term> of the element.  Sample tags mentioned in the text are
displayed in the form <tag tei="no">name att=value att2='value two'</tag>.
References to SGML attributes take the form <att tei="no">attname</att>,
where <mentioned>attname</mentioned> is the name of the attribute.
Where the elements and attributes
thus mentioned are part of the TEI encoding scheme,
they are included in the index.</p>

<p>These Guidelines distinguish encoding practices, and SGML elements,
which are required, recommended, or optional.  The phrases <mentioned>must</mentioned>,
<mentioned>is required to</mentioned>, etc., mark practices and tags which are required
for TEI conformance.  The phrases <mentioned>should</mentioned>, <mentioned>it is recommended
that</mentioned>, <mentioned>it is preferable to ...</mentioned>, etc., are used in describing
practices which are recommended but not required for TEI conformance.
Modal verbs like <mentioned>may</mentioned>, <mentioned>might</mentioned>, etc., mark practices which
are strictly optional.  Qualifying phrases like <mentioned>if desired</mentioned>,
<mentioned>where appropriate</mentioned>, or <mentioned>under some circumstances</mentioned> are used
when some tag or practice described may be desirable or acceptable under
some circumstances and not under others.</p>

<p>In the reference section in Part VII, elements and their
attributes are all classed as one of:

<list type="gloss">
<label>required</label>
<item>unconditionally required in a TEI-conformant document</item>
<label>mandatory when applicable</label>
<item>required under the appropriate conditions; may be
omitted if not applicable</item>
<label>recommended</label>
<item>recommended unless there are good reasons, in the given
circumstances, against it</item>
<label>recommended when applicable</label>
<item>recommended under some circumstances (which should be
clear from context)</item>
<label>optional</label>
<item>strictly optional </item>
</list>

<!-- <note ed=CH> I, for one, had such a hard time            -->
<!-- understanding what was meant by 'required', 'mandatory   -->
<!-- when applicable', ... etc., that I would strongly        -->
<!-- recommend the inclusion of a short paragraph explaining  -->
<!-- the terms by means of concrete examples.  </note> </p>   --></p>

<p>This reference section includes cross-references to the chapter or
section of the main text within which each element is discussed.  Most
sections of the main text in which elements are defined begin with a
descriptive list of the elements concerned in the following format:

<list type="gloss">
<label><gi tei="no">tag</gi></label> <item>short description of the
element marked by <tag tei="no">tag</tag>.  Where appropriate this is
followed by a list of significant non-global attributes for
the element as follows:
<list type="gloss">
<label><att>attribute</att></label>
<item>description of the attribute's meaning or usage,
optionally followed by a list of suggested or legal values:
<list type="gloss">
<label>value1</label> <item>meaning of value1</item>
<label>value2</label> <item>meaning of value2</item>
</list></item>
</list></item>
</list>
</p>

<p>Not all attributes are always included in these lists; those which
are shared with other elements in a class are usually listed separately,
and those of relatively specialized interest are usually listed only in
the reference section.  The values of the attribute are introduced with
one of the following formulaic phrases:

<list type="gloss">
<label><mentioned>Legal values include:</mentioned></label>
<item>The attribute cannot take values other than those given.  Other
values will cause SGML parsing errors.  (This is used relatively rarely
in these Guidelines.)</item>
<label><mentioned>Suggested values include:</mentioned></label>
<item>The values listed constitute a set which should suffice for most
purposes, and they should be used where appropriate.  Developers of
TEI-aware software should ensure that their software can process these
values appropriately.  In some cases, however, it is conceivable that
other values might be necessary, so the SGML declaration for the
attribute does not restrict legal values to those given.  TEI-aware
software should have reasonable fallback processing for values not in
the list.</item>
<label><mentioned>Sample values include:</mentioned></label>
<item>The attribute can take any value; those listed are provided simply
as examples of the kind of value possible.  </item>

</list>
</p>

<p>Each list of elements is followed by some discussion of its
semantics and usage, followed by one or more examples, taken
wherever possible from real texts, and presented in the following
format:

<eg><![ CDATA[
 <p>This paragraph contains an <hi rend=it>italicized phrase</hi>
]]>
</eg>

All the examples are (or should be) legal SGML, but, because they are
fragmentary, may not be parseable by SGML parsers without the required
context.  They also frequently make liberal use of white space to
exhibit the logical structure of the SGML coding more clearly.  Although
this does not affect the SGML conformance of the examples, some users
will prefer not to follow it in practice, since not all processors will
ignore the extra white space.  Examples may:

<list type="bullets">
<item>show full start- and end-tags for all elements </item>
<item>use empty end-tags (of the form
<tag tei="no">/</tag>) to close the most recently
opened element</item>
<item>omit end-tags (never start-tags) where they may legally be
omitted; where this is done, it is normally mentioned in the
accompanying text
</item>
</list>

<!-- <note ed=CH> Last list item (end-tag omission) removed   -->
<!-- </note>                                                  -->

Attribute values are given indifferently in single quotes or double
quotes; unquoted attribute values are sometimes used where SGML requires
no quotation marks.</p>

<p>It should be noted that the examples demonstrate a variety of tagging
styles, mostly aimed at making the tagging legible while also showing
fairly explicitly where all elements begin and end.  No claim is made or
implied as to the appropriateness of the style adopted here for other
purposes; in particular, those using SGML for local processing may often
prefer to use empty end-tags more frequently than is shown in the
examples, or to omit end-tags.

<!-- <note ed=CH>Was:  "may often prefer to use empty         -->
<!-- end-tags or to omit tags more frequently than is shown   -->
<!-- in the examples."  </note> </p>                          --></p>

<p>After the examples and usage notes, each section typically concludes
with a DTD fragment containing the formal declarations for the elements
described.  Each DTD fragment is given a heading, and may contain
element and attribute list declarations, entity declarations, parameter
entity references, comments, and references to DTD fragments in other
sections.  The DTD fragments of a single chapter almost invariably
belong to the same DTD file, the structure of which is typically
described (with references to the included fragments) in one of the
first or last sections of the chapter.</p>

<p>The DTD fragments are identical to the DTDs distributed with
these Guidelines, with the following exceptions:

<list type="bullets">

<item>In the text, the DTD fragments appear in an order dictated by
organization of this document; the actual DTD files may re-order the
material slightly.  This is indicated in the text by references from one
DTD fragment to another.</item>

<item>The DTD fragments in the text show the generic identifiers of all
elements using the standard English names assigned in this document; the
actual DTD files use parameter entities for all generic identifiers, so
that elements can be conveniently renamed, as described in chapter
<ptr target="MD">.  </item>

<item>The actual DTD files include conditional marked sections
surrounding the element and attribute list declaration for each element,
to ensure that elements can conveniently be suppressed or redefined, as
described in chapter <ptr target="MD">.  The fragments in the text
suppress the marked-section-open and marked-section-close markup.
</item>

</list>
</p>

<p>What appears in the text, therefore, as:
<eg>
<![ CDATA [
  <!ELEMENT blort - O (farble+)>
]]>
</eg>
will appear thus in the actual DTD file:
<eg>
<![ RCDATA [
  <![ %blort [
  <!ELEMENT %n.blort - O ((%n.farble)+)>
  ]&nil;]>
]]>
</eg> </p>

<p>For further discussion, see chapter <ptr target="ST">, or chapter
<ptr target="MD">.</p></div3></div2>


<div2 id="ABdpiu"><head>Underlying Principles and Intended Use</head>

<div3 id="ABtei2"><head>Design Principles of the TEI Scheme</head>

<p>The planning conference held at Vassar College in November, 1987 (see
section <ptr target="ABtei">) agreed on a number of principles concerning
the basic design goals of the Text Encoding Initiative.  These
principles are expounded in various documents of the TEI (notably TEI
ED P1 and TEI ED P2) and the interested reader is directed to those
documents for further discussion.

<!-- <note ed=CH>Nancy:  Perhaps a sentence here explaining   -->
<!-- the relationship between the Vassar principles and the   -->
<!-- text below, - if anyone feels the need for it.  I        -->
<!-- don't.</note></p>                                        --></p>

<p>Because of its roots in the humanistic research community, the TEI
scheme is driven by its original goal of serving the needs of research,
and is therefore committed to providing a maximum of comprehensibility,
flexibility, and extensibility.  More specific design goals of the TEI
have been that the Guidelines should:

<list>
<item>provide a standard format for data interchange</item>
<item>provide guidance for encoding of texts in this
format</item>
<item>support the encoding of all kinds of features of all
kinds of texts studied by researchers</item>

<!-- <note ed=CH>Nancy, need a shorter and better formulation for -->
<!-- this, - all kinds of (features of all kinds of) texts in all -->
<!-- languages, and all kinds of scholarly work with -->
<!-- those.</note>-->

<item>be application independent</item>
</list>

This has led to a number of important design decisions, such as:

<list>
<item>the choice of SGML and ISO 646</item>
<item>the provision of a large predefined tag set</item>
<item>a distinction between required, recommended, and optional encoding
practices</item>

<!-- , with relatively few encodings being required -->
<!--      <note ed=CH>Someone has to fix this -->
<!--      sentence</note></item> -->

<item>encodings for different views of text</item>
<item>alternative encodings for the same text features</item>
<item>mechanisms for user-defined extensions to the scheme</item>
</list>

These goals and principles are expounded in more detail below.</p>

<p>The goals of creating a common interchange format which is
application independent require the definition of a specific markup
syntax as well as the definition of a large predefined tag set.  The
syntax of the recommendations made in this document conforms to the
international standard ISO 8879, which defines the Standard Generalized
Markup Language; reference is also made to ISO 646, which defines a
standard seven-bit character set.  Full SGML document type declarations
are provided for the scheme described in these Guidelines.  </p>

<p>The goal of providing guidance for text encoding requires that
recommendations be made as to what textual features should be recorded
in various situations.  This mandate is fulfilled by the explicit
specification, in the reference section for each tag, that the tag is
<term>required</term>, <term>mandatory when applicable</term> but
otherwise omissible, <term>recommended</term> generally,
<term>recommended when applicable</term> but not always applicable, or
<term>optional</term>.</p>

<p>However, the TEI Guidelines make (with relatively rare exceptions)
no suggestions or restrictions as to the relative importance of textual
features.  The philosophy of the Guidelines is <q>if you want to encode
this feature, do it this way</q> --- but very few features are
mandatory.

<!-- <note ed=CH>This still appears a bit self-contradictory  -->
<!-- to me.  If one makes recommendations as to what          -->
<!-- features are 'required, recommended, and optional', it   -->
<!-- seems one does thereby make suggestions as to their      -->
<!-- relative importance.  Perhaps the para should go like    -->
<!-- this instead:  "Nevertheless, since very few parts of    -->
<!-- the &tei; scheme are required, the Guidelines do not     -->
<!-- impose restrictions against other views as to the        -->
<!-- relative importance of textual features.  The            -->
<!-- philosophy of the Guidelines is...."</note></p>          --></p>

<p>The Guidelines have been written largely with a focus on text capture
(i.e. the representation in electronic form of an already existing copy
text in another medium) rather than text creation (where no such copy
text exists).  Hence the frequent use of terms like
<socalled>transcription</socalled>, <socalled>original</socalled>,
<socalled>copy text</socalled>, etc.  However, the Guidelines should be
equally applicable to text creation, and the two terms <term>text
creation</term> and <term>text capture</term> are often used
interchangeably.</p>

<p>Concerning text capture the TEI Guidelines do not specify a
particular approach to the problem of fidelity to the source text and
recoverability of the original; such a choice is the responsibility of
the text encoder.  The current version of these Guidelines, however,
provides a more fully elaborated set of tags for markup of rhetorical,
linguistic, and simple typographic characteristics of the text than for
detailed markup of page layout or for fine distinctions among type fonts
or manuscript hands.

<!-- <note ed=CH>Nancy: Should we delete the last -->
<!-- sentence?</note></p> --></p>

<p>In these Guidelines, no hard and fast distinction is drawn between
<socalled>objective</socalled> and <socalled>subjective</socalled>
information or between <socalled>representation</socalled> and
<socalled>interpretation</socalled>.  These distinctions, though widely
made and often useful in narrow well defined contexts, are perhaps best
interpreted as distinctions between issues on which there is a scholarly
consensus and issues where no such consensus exists.  Such consensus
has been, and no doubt will be, subject to change.  The TEI
Guidelines do not make suggestions or restrictions as to which of these
features should be encoded.  The use of the terms
<term>descriptive</term> and <term>interpretive</term> about different
types of encoding in the Guidelines is not intended to support any
particular view on these theoretical issues, but reflects a purely
practical division of responsibility between the two committees called
Committee on Text Representation and Committee on Text Interpretation
and Analysis.  </p>

<!-- (see < xref target=???>.                                 -->

<p>In general, the accuracy and the reliability of the encoding and the
appropriateness of the interpretation is for the individual user of the
text to determine.  The Guidelines provide a means of documenting the
encoding in such a way that a user of the text can know the reasoning
behind that encoding, and the general interpretive decisions on which it
is based.  It is strongly recommended that the TEI header be used to
give an account of these aspects of the encoding.  The TEI header is
described in chapter <ptr target="HD">.</p>

<p>In many situations more than one view of a text is needed.  No
absolute recommendation to embody one specific view of text can apply to
all texts and all approaches to them.  The syntax of SGML ensures that
some encodings can be ignored for some purposes.  To enable encoding
multiple views, these Guidelines not only treat a variety of text
features, but they sometimes provide several alternative encodings for
what appear to be identical textual phenomena.  These Guidelines
therefore offer the possibility of encoding many different views of the
text, simultaneously if necessary.</p>

<p>However, the Guidelines are built on the assumption that there is a
common core of textual features shared by virtually all texts and
virtually all serious work on texts.  This core set of tags is defined
in Chapter <ptr target="CO" type="div1">.  Beyond this core, many different
elements can be encoded.</p>

<p>In brief, the TEI Guidelines define a general-purpose encoding
scheme which makes it possible to encode different views of text,
possibly intended for different applications, serving the majority of
scholarly purposes of text studies in the humanities.  However, no
predefined encoding scheme can serve all research purposes.  Therefore,
the TEI also provides means of modifying and extending the encoding
scheme defined by the Guidelines (see chapter <ptr target="MD">).</p></div3>


<div3 id="ABapp"><head>Intended Use</head>

<p>We envisage three primary functions for these Guidelines:

<list type="bullets">
<item>guidance for individual or local practice in text
creation and data capture;</item>
<item>support of data interchange;</item>
<item>support of application-independent local processing.
</item>
</list>

These three functions are so thoroughly interwoven in practice that it
is hardly possible to address any one without addressing the others.
However, the distinction provides a useful framework for discussing the
possible role of the Guidelines in work with electronic texts.</p>


<div4 id="ABapp1"><head>Use in Text Capture and Text Creation</head>

<p>The description of textual features found in the chapters which
follow should provide a useful checklist from which scholars planning to
create electronic texts should select the subset of features suitable
for their project.  </p>

<p>Problems specific to text creation or text
<socalled>capture</socalled> have not been considered explicitly in this
document.  For purposes of the TEI interchange format and for use of
SGML, it does not matter how a text is created or captured:  it can be
typed by hand, scanned from a printed book or typescript, read from a
typesetter's tape, or acquired from another researcher who may have used
another markup scheme (or no explicit markup at all).</p>

<p>We include here only some general points which are often raised about
SGML and the process of data capture.</p>

<p>SGML can appear distressingly verbose, particularly when (as in these
Guidelines) the names of tags and attributes are chosen for clarity and
not for brevity.  Editor macros and keyboard shorthands can allow a
typist to enter frequently used tags with single keystrokes.
Special-purpose software may be purchased which scans word-processor or
scanner data and inserts SGML tags.  SGML-aware software can help with
maintaining the hierarchical structure of the document, and display the
document with visual formatting rather than raw tags.</p>

<p>The techniques described in chapter <ptr target="MD" type="div1"> may be
used to give shorter names to the tags being used most often.  It should
also be noted that the examples in this text are chosen to exhibit the
markup as compactly as possible, and thus have denser markup than will
be typical in many texts.</p>

<p>The SGML standard provides ways of abbreviating, omitting, or
otherwise <term>minimizing</term> the amount of markup which need be
explicitly provided in a text.  They are all forbidden in the TEI
interchange format because their use complicates processing; this does
not however preclude their use in local processing, where this is felt
appropriate or desirable.</p></div4>


<div4 id="ABapp2"><head>Use for Interchange</head>

<p>When the TEI Guidelines are used for interchange, it is expected
that researchers using other encoding schemes in their work will
translate outgoing data from such schemes into the scheme described by
these Guidelines, and similarly translate incoming data from the scheme
described here into those used internally.  For such translations to be
carried out without loss of information, the scheme proposed here must
be as expressive (in a formal sense) as any encoding scheme now known to
be in wide use for textual research.  To ensure that this is the case, a
set of extension techniques is provided (see chapter <ptr target="MD"
type="div1">) which makes possible the addition of extra tags, the
renaming of existing tags and certain kinds of redefinition.  Although
the intention is to minimize the need for recourse to such extensions,
they may be used to accommodate the encoding of new or unanticipated
textual features.

<!-- It is important, however, to be sure that a textual      -->
<!-- feature that appears to be missing from the Guidelines   -->
<!-- is indeed not there, otherwise the extended DTDs will    -->
<!-- be needlessly redundant and the converted documents      -->
<!-- needlessly diverse, making comparative work difficult.   -->

<!-- <note ed=CH> Last two sentences suggested by AHR.  Was:  -->
<!-- "However the intention has been to minimize any need     -->
<!-- for recourse to such extensions."  </note>               -->

<!-- <note ed=NI> I do not like the last sentence, since my   -->
<!-- first reaction is to ask, how do I ensure that it is     -->
<!-- not there?  More generally it seems a bit insulting to   -->
<!-- the user's intelligence.</note>                          -->

<!-- I vote with NI. (msm)                                    -->

To translate between any pair of encoding schemes implies:

<list type="ordered">
<item>identifying the sets of textual features distinguished
by the two schemes;</item>
<item>determining where the two sets of features correspond;</item>
<item>creating a suitable set of mappings.</item>
</list> </p>

<p>For example, to translate from encoding scheme X into the TEI
scheme:

<list type="ordered">
<item>Make a list of all the textual features distinguished in
X. </item>
<item>Identify the corresponding feature in the TEI scheme.
There are three possibilities for each feature:
<list type="ordered">
<item>the feature exists in both X and the TEI scheme;</item>
<item>X has a feature which is absent from the TEI scheme;</item>
<item>X has a feature which corresponds with more than one
feature in the TEI scheme.</item>
</list>

The first case is unproblematic.  The second requires an extension to
the TEI scheme, as described in chapter <ptr target="MD">.  The third
requires that a consistent choice be made.  The algorithm used to make
that choice should be documented in the TEI header.  </item>

<item>Using the table of equivalences so generated, a simple
translation can be carried out between X and the TEI. </item>
</list>
</p>

<!-- following para added by LB to try to meet points raised below -->

<p>The ease with which this translation can be carried out will of
course depend on the clarity and explicitness with which scheme X
represents the features it encodes.</p>

<p>Translating from the TEI into scheme X follows the same pattern,
except that if a TEI feature has no equivalent in X, and X cannot be
extended, information must be lost in translation.</p>

<p>Similar procedures may be followed where the TEI scheme is to be
used as an interlanguage for interchange among several different sites
or applications, although the degree of TEI-conformance may vary.</p>

<!-- <note ed=CH> AHR: The translation section seems nice and -->
<!-- simple. Maybe too simple. Should it say anything about eg -->
<!-- overlapping elements or procedural code in the source -->
<!-- document? CH: I have no problem with what this section -->
<!-- explicitly says, but isn't it a gross oversimplification? It -->
<!-- seems to presuppose that all other encoding schemes have a -->
<!-- syntax which allows for a relatively straightforward (one- -->
<!-- to-one or many-to-one) mapping from tags in that scheme to -->
<!-- tags in SGML/TEI. This is simply not the whole truth. -->
<!-- Other encoding schemes may have syntactic structures so -->
<!-- different from SGML that translation into TEI requires not -->
<!-- only more or less complex remapping of tags and delimiters, -->
<!-- but also a complete restructuring of entire chunks of text. -->
<!-- Not that I think this should be discussed in any detail, but -->
<!-- we should not conceal the fact that translation to and from -->
<!-- TEI-SGML *may* occasionally require *very heavy programming*. -->
<!-- This is precisely one of the reasons why people should keep -->
<!-- their attention fixed on TEI/SGML also when designing -->
<!-- local formats. Sorry, I have no suggestion exactly how to put -->
<!-- this... </note> -->
<!-- <note ed=NI> Frankly I like the simplicity. This chapter -->
<!-- suffers from our trying to make every conceivable -->
<!-- qualification and cover every conceivable possibility. If the -->
<!-- point can be made in a sentence (or a footnote), then it could -->
<!-- be added, but otherwise I would vote for the straightforward -->
<!-- approach. </note> -->

<p>In the simplest case, where two sites or individuals exchanging texts
know each other and know or can inquire what equipment the other is
using, these Guidelines serve primarily as documentation for a file
format, which can be referred to without actually being transmitted
together with the file.  In the general case, where sender and recipient
cannot communicate such information, a stricter degree of <term>TEI
conformance</term> will be required for loss-free interchange.</p>

<p>The rules defining such strict conformance to the Guidelines are
given in some detail in chapter <ptr target="CF" type="div1">.  The
<term>interchange format</term> defined there requires that an
electronic text:

<list type="ordered">

<item>adhere to the SGML declaration and the SGML document type
declarations defined in these Guidelines, unless modified or extended as
described in chapter <ptr target="MD" type="div1">.  These SGML constructs
are further discussed in chapter <ptr target="SG">.</item>

<!-- The concepts of the SGML -->
<!-- declaration and the SGML document type declaration are -->
<!-- explained in section <ptr type=div1 target=SG>. The -->
<!-- provisions of the SGML declaration to be used for TEI files -->
<!-- are discussed in section <ptr type=div1 target=SG>.) </item> -->

<item>provide external documentation as described in chapter
<ptr target="TD" type="div1"> for all elements not defined in these
Guidelines, specifying a formal name (generic identifier) and a
corresponding full natural-language name, describing its meaning and
usage, specifying its legal content and also any attributes it may use.
</item>

<item>adhere to the requirements of the TEI header in providing
bibliographic identification of the text and description of the encoding
practices used (as described in chapter <ptr target="HD">).  </item>

</list> </p>

<p>Note that the interchange format makes no formal restriction on the
character set to be used in interchange, as this will depend on the
medium of interchange and the local character sets in use by sender and
receiver.  For further information, refer to chapter <ptr target="IN"
type="div1">.</p></div4>


<div4 id="ABapp3"><head>Use for Local Processing</head>

<p>Machine-readable text can be manipulated in many ways; some users:

<list type="bullets">
<item>edit texts (e.g. word processors, syntax-directed
editors) </item>
<item>edit, display, and link texts in hypertext systems</item>
<item>format and print texts using desktop publishing systems,
or batch-oriented formatting programs </item>
<item>load texts into free-text retrieval databases or
conventional databases </item>
<item>unload texts from databases as search results or for
export to other software </item>
<item>search texts for words or phrases </item>
<item>perform content analysis on texts </item>
<item>collate texts for critical editions </item>
<item>scan texts for automatic indexing or similar purposes</item>
<item>parse texts linguistically </item>
<item>analyze texts stylistically </item>
<item>scan verse texts metrically </item>
<item>link text and images </item>
</list> </p>

<p>These applications cover a wide range of likely uses but are by no
means exhaustive.  The aim has been to make the TEI Guidelines useful
for encoding the same texts for different purposes.  We have avoided
anything which would restrict the use of the text for other
applications.  We have also tried not to omit anything essential to any
single application.</p></div4></div3></div2>


<div2 id="ABtei"><head>Historical Background</head>

<!-- <p>These Guidelines are the result of several years'     -->
<!-- development by the an international co-operative         -->
<!-- research project known as the Text Encoding Initiative   -->
<!-- (&tei;).  This section outlines the progress of that     -->
<!-- project and its likely future development.</p>           -->

<!-- suppressed at CH's suggestion. this is almost identical  -->
<!-- to first para of preface, in any case (msm)              -->

<p>The Text Encoding Initiative grew out of a planning conference
sponsored by the Association for Computers and the Humanities (ACH) and
funded by the U.S.  National Endowment for the Humanities (NEH), which
was held at Vassar College in November 1987.  At this conference some
thirty representatives of text archives, scholarly societies, and
research projects met to discuss the feasibility of a standard encoding
scheme and to make recommendations for its scope, structure, content,
and drafting.  During the conference, the Association for Computational
Linguistics and the Association for Literary and Linguistic Computing
agreed to join ACH as sponsors of a project to develop the Guidelines.
The outcome of the conference was this set of principles, which
determined the further course of the project.</p>

<list type="ordered">
<item>The guidelines are intended to provide a standard format
for data interchange in humanities research. </item>
<item>The guidelines are also intended to suggest principles
for the encoding of texts in the same format. </item>
<item>The guidelines should
<list type="ordered">
<item>define a recommended syntax for the format, </item>
<item>define a metalanguage for the description of
text-encoding schemes, </item>
<item>describe the new format and representative existing
schemes both in that metalanguage and in prose. </item>
</list>
</item>
<item>The guidelines should propose sets of coding conventions
suited for various applications. </item>
<item>The guidelines should include a minimal set of
conventions for encoding new texts in the format. </item>
<item>The guidelines are to be drafted by committees on
<list type="ordered">
<item>text documentation </item>
<item>text representation </item>
<item>text interpretation and analysis </item>
<item>metalanguage definition and description of existing and
proposed schemes, </item>
</list>
coordinated by a steering committee of representatives of the principal
sponsoring organizations.  </item>
<item>Compatibility with existing standards will be maintained
as far as possible. </item>
<item>A number of large text archives have agreed in principle
to support the guidelines in their function as an interchange
format. We encourage funding agencies to support development
of tools to facilitate this interchange. </item>
<item>Conversion of existing machine-readable texts to the new
format involves the translation of their conventions into the
syntax of the new format. No requirements will be made for the
addition of information not already coded in the texts.
</item>
</list>

<p>In the course of the work, some of these goals assumed greater, some
lesser importance; some proved easier, some harder to achieve.  The
document in hand does define a standard form for the interchange of
textual material, and adumbrate principles for the creation of new
electronic texts.  The only metalanguage used, however, is that of SGML,
and no formal definitions are given of other common encoding schemes.
These Guidelines do define a minimal set of conventions for text
encoding (i.e. those SGML elements classed as recommended or required),
though few researchers will be satisfied to encode <emph>only</emph>
what is required or recommended here, since the set of required and
recommended SGML elements is rather small.  This document does not,
however, define --- at least not explicitly --- <q>sets of coding
conventions suited for various applications</q>, since consensus on
suitable conventions for different applications proved elusive; this
remains a goal for future work.</p>

<div3 id="ABtei1"><head>Origin and Development of the TEI</head>

<p>The Text Encoding Initiative proper began in June 1988 with funding
from the NEH, soon followed by further funding from the Commission of
the European Communities, the Andrew W. Mellon Foundation, and the
Social Science and Humanities Research Council of Canada.  Four working
committees, composed of distinguished scholars and researchers from both
Europe and North America, were named to deal with problems of text
documentation (resulting largely in chapter <ptr target="HD"
type="div1">),
text representation, text analysis and interpretation (together
responsible for most of what has become parts II, III, and IV), and
metalanguage and syntax issues (largely responsible for part VI).</p>

<p>A first draft version (1.0) of the Guidelines was distributed in July
1990 under the title <title>Guidelines for the Encoding and Interchange
of Machine-Readable Texts</title>, with the TEI document number TEI
P1.  With minor changes and corrections, this version was reprinted as
version 1.1 in November 1990.</p>

<p>Extensive public comment and further work on areas not covered in
version 1 resulted in the drafting of a revised version, TEI P2,
distribution of which began in April 1992.  This version includes
substantial amounts of new material, resulting from work carried out by
several specialist working groups, set up in 1990 and 1991 to propose
extensions and revisions to the text of P1.  The overall organization,
both of the draft itself and of the scheme it describes, was entirely
revised and reorganized in response to public comment on the first
draft.</p>

<p>In June, 1993, the Advisory Board of the Text Encoding Initiative met
to review the current state of the Guidelines, and recommended the
formal publication of the work done to that time.  The present version
of the TEI Guidelines, TEI P3,
represents a further revision of all chapters
published under the document number TEI P2, and the addition of further
chapters.  Although it will be subject to revision and amendment on the
basis of practical experience and public discussion, this version of the
Guidelines is published without the label <mentioned>draft</mentioned>, and
marks the conclusion of the initial development work.

<!-- statement on status of revised draft needed here --></p></div3>

<div3 id="ABtei4"><head>Future Developments</head>

<p>Work on areas still not satisfactorily covered in this manual will
continue, and resulting recommendations will be issued as supplements to
the published Guidelines.  Work is expected to continue in at least the
following areas:

<list>
<item>linguistic description and grammatical annotation</item>
<item>historical analysis and interpretation </item>
<item>base tag sets for further document types </item>
<item>manuscript analysis and physical description of text
</item>
</list>
</p>

<p>The encoding recommended by this document may be used without fear
that future versions of the TEI scheme will be inconsistent with it in
fundamental ways.  The TEI will be sensitive, in revising these
Guidelines, to the possible problems which revision might pose for those
who are already using this version of the Guidelines.
Wherever consistent with the
long-term goals of the project, consistency with this version will be
preserved in future revisions.  </p>


<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-default-dtd-file:"~/lib/psgml/p2odd.ced"
sgml-parent-document:(quote ("/home/tei/P3/Master/Odds/p2.odd" "tei.1" "text" "body" "div1" "div2"))
sgml-omittag:t
sgml-shorttag:t
End:
--></div3></div2></div1>
            <!-- 1 About These Guidelines  -->
