<!--* $Id: p2ch.odd,v 1.4 1998/01/28 11:44:14 cmsmcq Exp $ *-->
<!--*
    * $Log: p2ch.odd,v $
# Revision 1.4  1998/01/28  11:44:14  cmsmcq
# LB changes of Jan 1998 and RCS keywords added.
#
    *-->
<!-- apologies: I have been unable to track down correct      -->
<!-- bibliographic references for Unicode, ISO 10646 or       -->
<!-- for the AFII.        (LB)                                -->
<!>
<!-- P2 chapter 4:  Characters and Character Sets             -->
<!-- (id=CH, file=P2ch, LB)                                   -->
<!-- Revisions:                                               -->
<!-- 17 jan 98: LB : fix egs -->
<!-- 3 mar : typos from DTB -->
<!-- 93-05-31 : MSM : changes after Eynsham                   -->
<!-- 93-02-15 : MSM : suppress P at start of ITEM, NOTE       -->
<!-- 13 Jan 93:  WP     : changed P2.21 IDs to CH             -->
<!-- 17 Jul 92 : CMSMcQ : some changes from HG, but *not*:    -->
<!--          change title to Chars, Char Sets, and Entities  -->
<!--          mention double quotes (Mac users will insist    -->
<!--               double quotes are standard)                -->
<!--          'SGML entities' not changed to 'SGML or TEI     -->
<!--               public entities':  not all ents public     -->
<!--          21.2 does not xref to the discussion of LANG.   -->
<!--               This *is* the discussion of LANG.          -->
<!--          21.4 does not go into details of declaring ents -->
<!--               in WSDs, or not declaring them ...         -->
<!-- 15 Jul 92 : CMSMcQ : final revision for publication      -->
<!--  7 Jul 92 : LB : minor revisions in light of ST's comments  -->
<!-- 17 May 92 : CMSMcQ : add para about iso 2022 controls.   -->
<!--  6 May 92 : CMSMcQ, HG : revise                          -->
<!--  5 May 92 : CMSMcQ : draft for work with Harry Gaylord   -->

<div1 n=4 id=CH><head>Characters and Character Sets</head>

<p>Computer systems vary greatly in the sets of characters they make
available for use in electronic documents; this variety enables users
with widely different needs to find computer systems suitable to their
work, but it also complicates the interchange of documents among
systems; hence the need for a chapter on this topic in these Guidelines.

<p>Four character-set problems arise for the encoder of electronic
texts:
<!-- reordered as suggested by Syun -->
<list type=ordered>
<item>selecting a character set to use in creating, processing, or
storing the electronic text
<item>preparing documents for interchange so that the characters
within them are not corrupted in transit
<item>encoding characters which are not provided by the character
set available on the computer system in use
<item>signaling shifts from one character set to another, e.g. from
the Latin alphabet to Greek and back, or to a special symbol character
set and back
</list>

This chapter describes the recommended solutions to these problems, in
enough detail to satisfy the needs of most users.  More detail and more
technical information can be found in chapters
<ptr type=div1 target=CF>,
<ptr type=div1 target=IN>,
<ptr type=div1 target=WD>, and
<ptr type=div1 target=XW>.

<div2 id=CHlo><head>Local Character Sets</head>

<p>No single character set is prescribed for use in TEI-encoded
documents.  Users may use any character set available to them, subject
to the character set restrictions imposed by the SGML declaration.  It
is recommended that the character set used be documented by one or more
<term>writing system declarations</term> (WSD), on which see below.  In
most cases, a predefined writing system declaration should be suitable.
For writing system declarations provided as part of the TEI Guidelines,
see chapter <ptr type=div1 target=XW>.

<p>In general, it is most convenient to use a character set readily
available on one's computer system, though for special purposes it may
be preferable to customize the character set using software specialized
for the purpose.  Whether to use the usual character set or create a
custom set depends on the documents being encoded, the staff support and
tools available for customizing the character set, the user's technical
facility, etc.  A choice must be made between the perceived relative
convenience of living with an existing character set and the effort of
modifying it to suit one's documents more closely.  Care should be
taken, in particular where multi-byte character sets are used, that the
syntactic distinctions required by an SGML processor are preserved.
Where a suitable character set is defined by a national or international
standard, local customization should implement the standard rather
than inventing yet another non-standard character set.  The
choice must be made by each individual according to individual
circumstances; no general recommendations are made here as to whether
locally customized character sets should be used.  In principle, however,
for local processing, encoders should use whatever character set they
find convenient.

<div3 id=CHloa><head>Characters Available Locally</head>

<p>When the characters in a text exist in the local character set, the
appropriate character codes should be used to represent them.  Virtually
all computer systems provide at least the 52 letters of the standard
Latin alphabet, the ten decimal digits, and some basic punctuation
marks.

<p>Other characters, such as Latin characters with diacritics (e.g.
&auml or &eacute) or non-Latin characters (e.g. Greek, Hebrew, Arabic,
Cyrillic) are less universally provided. Oriental scripts pose
particular problems because of the size of their character repertoires.
If the
local character set provides an <mentioned>&auml</mentioned> however, there is
normally no reason not to use it where that character appears in the
text, unless the electronic text is to be moved frequently among
machines, in which case one may wish to restrict the electronic text to
characters known to translate well among machines.  (For more
information on moving characters among machines, see section <ptr
type=div2 target=CHin> below.)

<p>As noted above, full use of a local character set may require that
the SGML declaration be modified to define all the characters used as
legal SGML characters.
<!-- For further information see chapter <ptr type=div1 target=LO>. -->

<div3 id=CHlon><head>Characters Not Available Locally</head>

<p>Characters not available in the local character set should usually be
encoded using SGML <term>entity references</term>.  In SGML terms, an
<term>entity</term> (described in more detail in section <ptr
target=SG17>) is any named string of characters, from a single
character to an entire system file.  Entities are included in SGML
documents by <term>entity references</term>. Lists of suggested names
for all the characters and printers' symbols used by most modern European
languages have been published by ISO and others. <note>The most
widely used such entity set is to be found in Annex D to ISO 8879; it
is also reproduced or summarized in most SGML textbooks, notably
<bibl>Charles F. Goldfarb, <title>The SGML Handbook</title>
(Oxford:  Clarendon Press, 1990)</bibl>.  A list of some frequently
used standard entity names may be found in chapter <ptr type=div1
target=XW>.  Extensive entity sets are being developed by the TEI
and others are being documented in the fascicles of ISO/TR 9573:
<bibl><title>Technical Report:  Information processing ---
SGML support facilities --- Techniques for using SGML</title>
([Geneva]:  ISO, 1988 et seq.).</bibl>
</note>

<p>For example, the standard entity name for the character
<mentioned>&auml</mentioned> is <mentioned>auml</mentioned>; a reference to the entity
gives the name of the entity, preceded by an ampersand and followed by a
semicolon.
<note place=foot>Strictly speaking the semicolon is not always required; for
        details see any full treatment of SGML.
</note>
For example, consider the following German sentence:
<q rend=display>Trotz dieser langen Tradition
 sekund&auml;ranalytischer
 Ans&auml;tze wird man die Bilanz tats&auml;chlich
 durchgef&uuml;hrter sekund&auml;ranalytischer Arbeiten
 aber in wesentlichen Punkten als unbefriedigend
 empfinden m&uuml;ssen.
</q>
Using the standard names for a-umlaut and u-umlaut, one
could transcribe this sentence thus:
<eg>
<![ CDATA [
 Trotz dieser langen Tradition sekund&auml;ranalytischer
 Ans&auml;tze wird man die Bilanz tats&auml;chlich
 durchgef&uuml;hrter sekund&auml;ranalytischer Arbeiten
 aber in wesentlichen Punkten als unbefriedigend
 empfinden m&uuml;ssen.
]]>
</eg>
<!-- Manfred Thaller, Vor&uuml;berlegungen ..., in           -->
<!-- Datenbanken und Datenverwaltungssysteme als Werkzeuge   -->
<!-- historischer Forschung, p. 9.                           -->

<p>As noted above, standard entity names have been defined for most
characters used by languages written in the Latin alphabet, and for some
other scripts, including Greek, Cyrillic, Coptic, and the International
Phonetic Alphabet.  A useful subset of these may be found in chapter
<ptr type=div1 target=XW>.

<p>Before an entity can be referred to, it must be declared.  Standard
public entity names can be declared en masse, by including within the
DTD subset of the SGML document a reference to the standard public
entity which declares them.  The German document quoted above, for
example, would have the following lines, or their equivalent, in its
DTD subset:
<eg>
<![ CDATA [
 <!ENTITY % ISOLat1
        PUBLIC "ISO 8879-1986//ENTITIES Added Latin 1//EN">
 %ISOLat1;
]]>
</eg>

<p>Where no standard entity name exists, or where the standard name is
felt unsuitable for some reason, the encoder may declare non-standard
entities, using the normal SGML syntax.
<!-- LB added following to try to clarify example a bit -->
The replacement string for such entities may vary for different
purposes, as in the following extended example.

<p>In transcribing a manuscript, it might be desirable to distinguish
among three distinct forms of the letter <mentioned>r</mentioned>. In the
transcript, each of these forms will be encoded by an entity
reference, for example: <code lang=sgml>&amp;, &amp;r2;</code>, and
<code lang=sgml>&amp;r3;</code>.  Entity declarations must then be
provided, within the DTD subset of the SGML document, to define these
entities and specify a substitute string.

<p>One possible set of declarations would be as follows:

<eg>
<![ CDATA [
 <!ENTITY r  'r[1]'><!-- most common form of 'r'  -->
 <!ENTITY r2 'r[2]'><!-- secondary form of 'r'    -->
 <!ENTITY r3 'r[3]'><!-- third form of 'r'        -->
]]>
</eg>

The expansions shown above will simply flag each occurrence with a
number in brackets to indicate which form of <mentioned>r</mentioned> appears in
the manuscript.

<p>Another (imaginary) set of declarations might use some
printer-specific codes to produce visually distinct versions of the
three letters in output:

<eg>
<![ CDATA [
 <!ENTITY so '&#27;I&#12;'><!-- shift to alternate printer font -->
 <!ENTITY si '&#27;I&#8;'> <!-- shift to basic printer font -->
 <!ENTITY r  'r'>             <!-- most common form of 'r'  -->
 <!ENTITY r2 '&so;r&si;'>     <!-- secondary form of 'r'    -->
 <!ENTITY r3 '&so;&#113;&si;'><!-- third form of 'r'        -->
]]>
</eg>
<!-- for verisimilitude, changed &#0;&#04;r and &#0;&#6;r to  -->
<!-- specific codes of the IBM ProPrinter (for old time's     -->
<!-- sake; I used to work with them).  113 is 'q',            -->
<!-- assumption is that designer has placed variants of R     -->
<!-- adjacent in downloaded set, for no particular reason.    -->
<!-- -msm                                                     -->

Here the replacement strings for each entity contain <term>character
references</term>, for example <code lang=sgml>&amp;#27;</code>,
indicating the decimal value (or <term>code point</term>) of the
character to be generated by the SGML processor.  The assumption is
that the sequence of bytes generated will drive a printer to produce a
distinctive form of the letter.  Such printer instructions are of
their nature highly machine- and software-dependent; by allowing them
to be confined to a single place (the entity declarations), SGML makes
it easier to adapt such device-specific information to new
environments.

<p>Alternatively, the declarations can give all three forms the same
appearance in the output:

<eg>
<![ CDATA [
 <!ENTITY r  'r'><!-- most common form of 'r'  -->
 <!ENTITY r2 'r'><!-- secondary form of 'r'    -->
 <!ENTITY r3 'r'><!-- third form of 'r'        -->
]]>
</eg>

<p>And finally, to ensure that the SGML output uses the same entity
references for these characters as does the SGML input, one could use
the following declarations.

<!-- < eg >                                                  -->
<!-- < ![ CDATA [                                            -->
<!-- < !ENTITY amp '&' >                                     -->
<!-- < !ENTITY r  '&amp;r;'  >  < ! - most common form of 'r' - > -->
<!-- < !ENTITY r2 '&amp;r2;' >  < ! - secondary form of 'r'   - > -->
<!-- < !ENTITY r3 '&amp;r3;' >  < ! - third form of 'r'       - > -->
<!-- ]] >                                                     -->
<!--  < /eg >                                                 -->

<!-- Example above abandoned in favor of next one.  Not all   -->
<!-- processors handle the entity end the same one; the       -->

<eg>
<![ CDATA [
 <!ENTITY r  CDATA '&r;' ><!-- most common form of 'r'  -->
 <!ENTITY r2 CDATA '&r2;'><!-- secondary form of 'r'    -->
 <!ENTITY r3 CDATA '&r3;'><!-- third form of 'r'        -->
]]>
</eg>

<p>Wherever locally defined entities are used for the representation of
characters in the text, whether to record presentational variants as
in this example or to represent special symbols not present in standard
character sets or public entity sets, it is recommended that the
entities be documented in a writing system declaration; for details
see chapter <ptr target=WD>.

<p>For transcriptions in scripts not supported by the local character
set, entity references may prove unwieldy.  In such cases, it is also
possible to transliterate the material from its original script into
the script of the local character set; like a customized local
character set, a transliteration scheme should be documented with a
writing system declaration.  To avoid information loss, a
<term>reversible</term> transliteration scheme (i.e. one in which it
is possible to reconstruct the original writing from the
transliteration) should be preferred; wherever possible, standard
schemes should be preferred to ad hoc schemes.
<!-- deleted following sentence : too vague -->
<!-- Great care must be exercised, however, in developing -->
<!-- or selecting transliteration schemes, as many schemes, even standard -->
<!-- ones, developed for general use are  emph>not /emph> reversible. -->
<note place=foot>
Reversible transliteration schemes are defined by
national and international standards too numerous to list here; another
useful source is <bibl><title>ALA-LC Romanization Tables:
Transliteration Schemes for Non-Roman Scripts</title>, approved by the
Library of Congress and the American Library Association, tables
compiled and edited by Randall K. Barry (Washington:  Library of
Congress, 1991).</bibl>  Many of these schemes, however, use
diacritics which are themselves not always available in standard
electronic character sets and thus may require careful adaptation for
use in electronic work.
</note>

<p>For example, using the Beta code transcription developed for ancient
Greek by the Thesaurus Lingu&aelig; Gr&aelig;c&aelig;,<note place=foot>
<bibl>
Thesaurus Lingu&aelig; Gr&aelig;c&aelig;,
<title>Beta Manual</title>
(Irvine:  TLG, [1988]).
</bibl>
See also
<bibl>
<author>Luci Berkowitz and Karl A.
Squitier,</author>
<title>Thesaurus Lingu&aelig; Gr&aelig;c&aelig; Canon of Greek
Authors and Works</title>
2nd edition (Oxford:  Oxford University Press,
1986).</bibl>
</note>
one would transcribe the start of the <title>Iliad</title> of Homer thus:

<eg>
<![ CDATA [
 <l>*MH=NIN A)/EIDE QEA\ *PHLHI+A/DEW *)AXILH=OS
 OU)LOME/NHN, H(\ MURI/' *)AXAIOI=S A)/LGE' E)/QHKE,
]]>
</eg>
<!-- Homer, Iliad, I.1-2, from OCP file demo4.txt. -->
<!-- stripped line number. -->

<p>Some standard transliteration schemes for commonly encoded languages
are included in chapter <ptr type=div1 target=XW>.
<!-- viz. Beta code and PhonASCII -->
<!-- would be nice to have example with PhonASCII or some such. -->

<div2 id=CHsh><head>Shifting Among Character Sets</head>

<p>Many documents contain material from more than one language: loan
words, quotations from foreign languages, etc.  Since languages use a
variety of <term>writing systems</term>, which in turn use a variety
of <term>character repertoires</term>, shifts in language frequently
go hand in hand with shifts in character repertoire and writing
system.  Since language change is frequently of importance in
processing a document, even when no character set shift is needed, the
encoding scheme defined here provides a global attribute
<att>lang</att> to make it possible to mark language shifts
explicitly.  This attribute may also be used to trigger character-set
shifting by application programs.

<!-- it possible to mark language shifts explicitly.  This    -->
<!-- attribute is also used to trigger character-set          -->
<!-- shifting by application programs.                        -->

<p>Some languages use more than one writing system.  For example, some
Slavic languages may be written either in the Latin or in the Cyrillic
alphabet; some Turkic languages in Cyrillic, Latin, or Arabic script.
In such cases, each writing system must be treated separately, as a
separate <soCalled>language</soCalled>.  Each distinct value of the
<att>lang</att> attribute, therefore, represents a single natural
language, a single writing system, and a single coded character set.

<!-- < p > It is strongly recommended that each value used    -->
<!-- for the < att > lang < /att >  attribute correspond to   -->
<!-- a writing system declaration suitable for the            -->
<!-- character set and writing system being used.  The        -->

<p>Each value used for the
<att>lang</att> attribute must correspond to a writing system declaration
suitable for the character set and writing system being used.  The
values should where possible be taken from the standard two- and
three-letter language codes defined by the international standard ISO
639.<note place=foot>
<bibl>ISO 639: 1988, <title>Code for the representation of names
of languages</title>  ([Geneva]:  International Organization for
Standardization, 1988).  The most recent version of this standard
supplies three-letter codes as well as the earlier system of
two-letter codes.  Either may be used in TEI documents.
</bibl>
</note>
<!-- In the rare event that -->
When more than one writing system is used for the same
language in the same document, suffixes should be added to the values
from ISO 639.  A selection of standard language codes, as well as a
number of standard writing system declarations, are provided in chapter
<ptr type=div1 target=XW>; other writing system declarations may be
provided locally.

<p>Like any global attribute, the <att>lang</att> attribute may be used
on any element in the SGML document.  To mark a technical term, for
example, as being in a particular language, one may simply specify the
appropriate language on the <tag>term</tag> tag (for which see
<ptr type=div2 target=TE>):

<eg>
<![ CDATA [
<p lang=EN> ...
But then only will there be good ground of hope for the
further advance of knowledge, when there shall be received
and gathered together into natural history a variety of
experiments, which are of no use in themselves, but simply
serve to discover causes and axioms, which I call
<term lang=LA>Experimenta lucifera</term>, experiments of
<term>light</term>, to distinguish them from those which I
call <term lang=LA>fructifera</term>, experiments of
<term>fruit</term>.
<p>Now experiments of this kind have one admirable
property and condition:  they never miss or fail. ...
]]>
</eg>
<!-- Bacon, New Organon, XCIX, p. 361 of pocket ed. -->
<!-- need snappier example. -->

<p>The form in which materials in different writing systems are
processed or displayed is not specified by these Guidelines; if
appropriate characters are not available locally, application software
may choose to display the material in an appropriate transliteration, as
a series of entity references, or in other forms.  If the local system
requires explicit escape sequences or locking-shift control functions to
signal shifts to alternate character sets, these escape sequences may be
embedded directly in the content of the appropriate element or may be
supplied by the application software upon recognition of the language
shift.  However, escape sequences are <!-- extremely -->
vulnerable to loss or
misinterpretation when documents are sent from site to site.  For this
reason, the method of embedding them directly in the document, while
allowed within TEI-conformant interchange, is not recommended for
general use.<note place=foot>
    Standard methods for character-set shifting are defined in
    ISO 2022: 1986, <title>Information processing --- ISO 7-bit and
    8-bit coded character sets --- Code extension techniques</title>,
    3d ed. ([Geneva]:  International Organization for Standardization,
    1986).
    A standard set of control functions, including methods of specifying
    script direction (left-right, right-left, top-down, etc.), is
    defined by ISO 6429: 1992, <title>Information processing --- Control
    functions for 7-bit and 8-bit coded character sets</title>,
    ([Geneva]:  ISO, 1992).  These and related standards are recommended
    to the notice of those designing systems to handle multiple
    character sets.
</note>

<div2 id=CHin><head>Character Set Problems in Interchange</head>

<p>Electronic texts may be exchanged over electronic networks, through
exchange of magnetic media (e.g. disk or tape), or by other means.  In
every case except the transmission of storage media from one machine to
another machine of the same hardware type running the same operating
system and using the same coded character set, the characters are
subject to translation and interpretation, and hence to
misinterpretation and corruption, by utility software working somewhere
on the interchange path.  Network gateways, tape-reading software, and
disk utilities routinely translate from one character set to another
before passing the data on.  If the utility errs in identifying the
character set, or if several utilities translate back and forth among
character sets using non-reversible translations, the chances are good
that characters will be garbled and information lost.

<p>At this time (1994), it is recommended that in texts subject to
<soCalled>blind</soCalled> interchange (that is, interchange between
parties who do not or cannot make explicit agreements over the character
set to be used in interchange) no characters should be used other than
those in the international reference version (IRV) of ISO
646.<note place=foot>
<bibl>ISO (International Organization for Standardization).
<title>ISO 646:  1991.  Information processing --- ISO 7-bit coded
character set for information interchange.</title>  ([Geneva]:
International Organization for Standardization, 1991.)
<!-- need to check date on this new version of 646. (MSM) -->
</bibl>
</note>
Other characters should be represented by SGML entity references.  For
scripts (such as those of East Asia) which require a character
repertoire larger than 255 characters, regional proposals for character
and entity sets to be used in non-negotiated interchange must be
developed and published internationally.

<p>In some cases, even the characters in ISO 646 IRV are corrupted in
transit; where interchange takes place over links not reliable for the
full IRV character set, the characters subject to misinterpretation and
corruption should be replaced by standard entities.  At present, the
characters least susceptible to loss or misinterpretation in transit
among systems are those shown below, which represent a subset of the
characters in IRV and may thus be called the <term>ISO 646
subset</term>.

<eg rend=literal>
a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
0 1 2 3 4 5 6 7 8 9
" % & ' ( ) * + , - . / : ; < = > ? _
</eg>

<p>In interchange over any transmission link, the transmitted document
should contain only those characters which safely survive transmission
over the link; others should be represented with entity references, or
with transliterations, as described above.

<p>In blind interchange by means of magnetic or optical media, it is
recommended that the document be encoded using some well documented and
widely used standard character set.

<p>In blind interchange over networks, it is recommended that the
transmitted document contain only characters known to travel safely over
the networks involved.  In the most general case, those characters are
the ISO 646 subset given above.

<p>The problem of character data loss in document interchange is in
principle a temporary one; eventually, it should disappear as
improvements are made in network handling of character data and as more
networks support larger character sets such as ISO
10646.<note place=foot>
<bibl>ISO (International Organization for Standardization), and IEC
(International Electrotechnical Commission), <title>ISO/IEC 10646-1:
1993.  Information technology --- Universal Multiple-Octet Coded
Character Set (UCS) --- Part 1:  Architecture and Basic Multilingual
Plane.</title>  ([Geneva]:  International Organization for
Standardization, 1993.)  </bibl> The Basic Multilingual Plane of ISO
10646 is identical to the sixteen-bit character set known as Unicode:
<bibl>The Unicode Consortium, <title>The Unicode Standard:
Worldwide Character Encoding</title> Version 1.0, Volume 1 (Reading,
Mass.:  Addison-Wesley, 1991).  </bibl> Version 1.0 of Unicode has
been superseded by later work incorporated into ISO/IEC 10646; these
changes are be reflected in the official published standard, and will be
documented in version 1.1 of Unicode.
</note>
The need for backward compatibility with older systems is likely,
however, to ensure that care must be taken in blind interchange for the
foreseeable future.

<p>For further discussion of negotiated and non-negotiated interchange,
see chapter <ptr target=IN>.

<div2 id=CHws><head>The Writing System Declaration</head>

<p>Each language and writing system used in a document should be
documented in a Writing System Declaration (WSD), which specifies:
<list>
<item>a formal name for the writing system and language, for use as a
<att>lang</att> attribute value on elements encoded in it
<item>a specification for the meaning of each character available
in the writing system
</list>
The characters available in a writing system may be specified in the
WSD for that writing system in one or more of the following ways:
<list>
<item>by reference to an international, national, or TEI-registered coded
character set or entity set
<item>by reference to such a standard followed by formal declaration of
all exceptions
<item>by providing a formal declaration for each character used
</list>
Individual characters within a WSD are formally declared, where
necessary, by providing the following information:
<list>
<item>the unique code used to represent the character
<item>special properties such as whether the character is a diacritic
mark or not
<item>brief textual description of the character
<item>standard or local entity name used for the character in
interchange
<item>other standard identifiers for the character, if available, such
as its code in the <soCalled>Universal Character Set</soCalled> of ISO
10646 or Unicode
and its standard number in the Association for Font Information
Interchange registry.
<!-- We need a bibliographic reference for AFII. -->
<item>optionally, some specification of a suitable graphic rendition for
the character in a suitable notation (e.g. graphic image, Metafont
program, etc.)
</list>

<p>The writing system declaration is one of a set of
<term>auxiliary</term> documents which provide documentation relevant to
the processing of TEI texts.  Auxiliary documents are themselves SGML
documents, for which document type declarations are provided.  The DTD
for the Writing System Declaration is discussed in detail in chapter
<ptr type=div1 target=WD>.  Standard Writing System Declarations are
provided in chapter <ptr type=div1 target=XW>.

            <!-- 4 Character Sets -->
