<!-- $Id: p2wd.odd,v 1.9 1998/02/01 17:38:08 tei Exp $ -->
<!--*
    * $Log: p2wd.odd,v $
    * Revision 1.9  1998/02/01 17:38:08  tei
    * fix Log keyword,
    * normalize SGML
    * replace system identifiers with public identifiers.
    *
    * Revision 1.8  94/03/28  15:10:52  lou
    * fix asstd <term> elements
    *
    * Revision 1.7  1994/03/27  16:31:49  lou
    * *** empty log message ***
    *
    * Revision 1.4  1993/09/22  18:41:40  msmcq
    * Version as of publication of WD
    *
    * Revision 1.3  1993/09/17  16:23:41  lou
    * Minor stylistic revisions
    *
    * Revision 1.2  1993/07/28  21:03:50  msmcq
    * Mostly cosmetic changes
    * regularize formal names
    * -->
<!-- Revisions:                                               -->
<!-- 18 mar : applied corrections noted by eagle-eyed gary simons -->
<!-- 93-09-20 : MSM : last-minute revisions                   -->
<!-- 93-09-20 : MSM : make wsd names more consistent          -->
<!-- 93-09-20 : MSM : embed wsdgis.ent                        -->
<!-- 93-09-17 : MSM : go through checking up on Lou, minor mods -->
<!-- 3 aug 93 : LB : simplify prose here and there              -->
<!--                fix dud comment                           -->
<!-- 93-07-28 : MSM : minor improvements from late May        -->
<!-- 93-05-31 : MSM : add reference to inherited,  isodate    -->
<!-- 93-05-31 : MSM : add reference to wsdglob                -->
<div1 id="WD" n="25"><head>Writing System Declaration</head>

<p>The <term>writing system declaration</term> or WSD is an
auxiliary document which provides information on the methods used to
transcribe portions of text in a particular language and script.
<!-- <note place=foot>The primary responsibility for this chapter wasborne by work -->
<!-- group TR 1 (character set issues), chaired by Harry Gaylord.  The -->
<!-- original design of the writing system declaration and the firstdraft of -->
<!-- its documentation were created by Steven J. DeRose; revisionshave been -->
<!-- made by Harry Gaylord and Syun Tutiya, among others.</note> -->
We use the term <term>writing system</term> to mean a given method
of representing a particular language, in a particular script or
alphabet; the WSD specifies one method of representing a given writing
system in electronic form.  A single WSD thus links three distinct
objects:

<list type="bullets">
<item>the language in question</item>
<item>the writing system (script, alphabet, syllabary) used to write the
language</item>
<item>the coded character set, entity names, or transliteration scheme
used to represent the graphic characters of the writing system</item>
</list>

Different natural languages thus have different writing system
declarations, even if they use the same script.  Different methods used
to write the same language (e.g.  Cyrillic or Latin encoding of
Serbo-Croatian), and different methods of representing the same script
in electronic form (e.g. different coded character sets such as ASCII or
EBCDIC, or different transliteration schemes) similarly must use
different writing system declarations.</p>

<p>This chapter describes first the overall structure of the WSD
(section <ptr target="WDov">), and then the specific elements used to
document the natural language, writing system, coded character sets,
SGML entity names, and transliteration schemes united by the WSD.
Section <ptr target="WDlk"> describes how the WSD is associated with
different portions of a document. Predefined TEI writing system
declarations, which should suffice for many uses, are described in
section <ptr target="WDxw">.  There follows a brief description of how
to create a new WSD on the basis of an existing WSD.  Finally, in
section <ptr target="WDse"> we provide a formal discussion of the
semantics of the writing system declaration.</p>


<div2 id="WDov"><head>Overall Structure of Writing System Declaration</head>

<p>A writing system declaration is a distinct auxiliary document,
separate from any transcription for which it is used.
<!-- LB adds -->
A TEI document specifies the writing system declarations applicable to
it by means of declarations in its header, and by means of its use of
the global <att>lang</att> attribute, as further specified in section
<ptr target="WDlk">. Each writing system declaration is itself a
free-standing document, encoded as
a single <gi>writingSystemDeclaration</gi> element, and
containing the following elements:

<list type=gloss>
<label><gi>writingSystemDeclaration</gi></label>
<item>declares the coded character set, transliteration scheme, 
or
entity set used to transcribe a given writing system of 
a given
language.
Attributes include:
<list type=gloss>
<label><att>name</att></label>
<item>gives a formal name for the writing system declaration</item>
<label><att>date</att></label>
<item>gives the date on which the writing system declaration was 
last revised.</item>
</list>
</item>
<label><gi>language</gi></label>
<item>identifies the language being described in the writing 
system
declaration.</item>
<label><gi>script</gi></label>
<item>contains a prose description of the script declared by a 
writing
system declaration.</item>
<label><gi>direction</gi></label>
<item>specifies one or more conventional directions in which a 
language
is written using a given script.</item>
<label><gi>characters</gi></label>
<item>contains a specification of the characters used in a 
particular
writing system to write a particular language, 
and of how those
characters are represented in electronic 
form.</item>
<label><gi>note</gi></label>
<item>(in a writing system) contains a note of any type.</item>
</list>


All elements in the writing system declaration may bear either of the
following two attributes:

<list type=gloss>
<label><att>id</att></label>
<item>gives a unique identifier for the element.</item>
<label><att>lang</att></label>
<item>gives the language in which the content of the element is 
written.</item>
</list>
</p>

<p>These attributes function in the same way as the global
<att>id</att> and <att>lang</att> attributes of the main TEI DTD
(although for technical reasons the latter is declared differently):
the former provides a unique SGML identifier for the element, and the
latter identifies the language in which the contents of the element
are expressed, using a code from ISO 639.</p>

<p>The overall structure of a writing system declaration is thus as
follows:

<eg>
<![ CDATA [
<writingSystemDeclaration
          lang='eng'
          name=' ... '
          date='1993-05-29'>

<language iso639='...'>
    <!-- name of language here -->
    </language>
<script>
    <!-- description of script here ... -->
    </script>
<direction chars=LR lines=TB>
<characters>
    <!-- description of character inventory here ... -->
    </characters>
</writingSystemDeclaration>
]]>
</eg></p>

<p>The attributes <att>date</att> and <att>name</att> are required on
the <gi>writingSystemDeclaration</gi> element.  The <att>date</att>
attribute is used to specify the date on which the WSD was written or
last changed; this  must be given in the format
<q>yyyy-mm-dd</q>, as defined by ISO 8601: 1988, <title>Data
elements and interchange formats --- Information interchange ---
Representation of dates and times</title>.</p>
<p>The <att>name</att> attribute is used to assign a formal name to the
writing system declaration, for references to it from elsewhere.  It is
recommended, though not required, that the name be constructed as an
SGML formal public identifier; for purposes of writing system
declarations, this means it should follow the pattern of the following
examples:

<eg>
 -//TEI P2: 1993//NOTATION WSD for Modern English//EN
 -//WWP 1993//NOTATION WSD for 17th-century English//EN
 -//OTA 1991//NOTATION WSD for Old English//EN
 -//GLDV 1997//NOTATION WSD Mittelhochdeutsch//DE
</eg>

That is, the identifier should consist of:

<list type="ordered">
<item>either the string <code>-//</code> (indicating that the organization
issuing the WSD is not registered with ISO) or the string <code>+//</code>
(indicating that the organization is so registered);</item>
<item>a short string identifying the issuing organization and optionally
the document which defines the WSD (or at least the issuing organization
and the date);</item>
<item>the separator string <code>//</code>;</item>
<item>the keyword <code type="kw">NOTATION</code>, indicating that in SGML terms, the
writing system declaration functions as a non-SGML notation;</item>
<item>a descriptive phrase indicating the contents of the WSD (which
may, as here, begin <q>WSD for ...</q>);</item>
<item>the separator string <code>//</code>;</item>
<item>the ISO 639 code for the language in which the WSD is written,
for example <code>EN</code>.</item>
</list></p>

<p>The other elements of the WSD are described in the following
sections.</p>

<p>The DTD for writing system declarations is included in file <ident
type="file">teiwsd2.dtd</ident>; a writing system declaration will thus
begin with a document type declaration invoking that file:

<eg>
<![ CDATA [
 <!DOCTYPE writingSystemDeclaration
           PUBLIC "-//TEI P3//DTD Auxiliary Document Type:
           Writing System Declaration//EN"
          "teiwsd2.dtd" [
   <!-- entity sets are declared and invoked here -->
  ]>
]]>
</eg>

<!-- I enter here my firm conviction that                     -->
<!-- 'writingSystemDeclaration' is a ridiculous name for      -->
<!-- this element. It doesn't matter how often one is         -->
<!-- likely to use it. It's just too unwieldy and long.  It   -->
<!-- should be  < wsd > : that's how one refers to the        -->
<!-- thing after all.                                         -->
<!-- LB 1 aug 93 --></p>

<p>The formal declaration of the writing system declaration is as
follows:

<eg id=dwd>
<![ CDATA [
<!-- 25.1:  Writing System Declaration                        -->
<!-- Text Encoding Initiative: Guidelines for Electronic      -->
<!-- Text Encoding and Interchange. Document TEI P3, 1994.    -->

<!-- Copyright (c) 1994 ACH, ACL, ALLC. Permission to copy    -->
<!-- in any form is granted, provided this notice is          -->
<!-- included in all copies.                                  -->

<!-- These materials may not be altered; modifications to     -->
<!-- these DTDs should be performed as specified in the       -->
<!-- Guidelines in chapter "Modifying the TEI DTD."           -->

<!-- These materials subject to revision. Current versions    -->
<!-- are available from the Text Encoding Initiative.         -->
<!ENTITY % INHERITED '#IMPLIED'                                 >
<!ENTITY % ISO-date 'CDATA'                                     >
<!-- Embed entities for TEI generic identifiers.              -->

<!ENTITY % TEI.wsdNames system 'wdgis2.ent'                     >
%TEI.wsdNames;
<!ENTITY % a.global '
          id                 ID                  #IMPLIED
          lang               CDATA               %INHERITED'    >
<!ELEMENT writingSystemDeclaration 
                        - -  (language, script, direction*, 
                             characters, note*)                 >
<!ATTLIST writingSystemDeclaration
                             %a.global;
          name               CDATA               #REQUIRED
          date               %ISO-date           #REQUIRED      >
<!-- ... declarations from section 25.2                       -->
<!--     (Language identification)                            -->
<!--     go here ...                                          -->
<!-- ... declarations from section 25.3                       -->
<!--     (Script and writing direction)                       -->
<!--     go here ...                                          -->
<!-- ... declarations from section 25.4.1                     -->
<!--     (Base components)                                    -->
<!--     go here ...                                          -->
<!-- ... declarations from section 25.4.2                     -->
<!--     (Exceptions to the base components)                  -->
<!--     go here ...                                          -->
<!-- ... declarations from section 25.5                       -->
<!--     (Notes)                                              -->
<!--     go here ...                                          -->
]]>
</eg>
</p></div2>

<div2 id="WDla"><head>Identifying the Language</head>

<p>The <gi>language</gi> element is used to name the language associated
with the WSD.  Its <att>iso639</att> attribute gives the ISO standard
code for the language as defined by <title>ISO 639: 1988. Code for the
representation of names of languages</title>.

<list type=gloss>
<label><gi>language</gi></label>
<item>identifies the language being described in the writing 
system
declaration.
Attributes include:
<list type=gloss>
<label><att>iso639</att></label>
<item>gives the standard language code from ISO 639.</item>
</list>
</item>
</list>

<!-- here --></p>
<p>If the language in question is not included in the list in ISO 639,
the value of the attribute <att>iso639</att> should be the
empty string, as in the following example:
<eg>
<![ CDATA [
<language iso639=''>Various</language>
]]>
</eg>
<!-- this looks completely mad! (LB)  --></p>

<p>The <gi>language</gi> element should not be confused with the global
<att>lang</att> attribute; the element identifies the language whose
writing system is being documented, while the attribute identifies the
language in which the description is being written.  A writing system
declaration for classical Greek, for example, which itself is written in
English, would have the value <code>eng</code> for the <att>lang</att>
attribute on the top-level element, and the value <code>grc</code> for the
<att>iso639</att> attribute on the <gi>language</gi> element:

<eg>
<![ CDATA [
<writingSystemDeclaration
          id='grc.beta'
          lang=eng
          name='-//TEI P2: 1993//NOTATION WSD for TLG Beta Code
               transliteration of ancient greek//EN'
          date='1993-05-29'>

<language iso639='grc'>Classical Greek.  This WSD documents the Beta
transcription code for classical Greek developed by the Thesaurus
Linguae Graecae of the University of California, Irvine.</language>
<!-- ... -->
</writingSystemDeclaration>
]]>
</eg></p>

<p>Normally, the language described is a natural language; in some
cases, however, artificial languages, dialects, or other sublanguages
may be usefully regarded as a language and documented in a writing
system declaration.  When a sublanguage is documented, a description of
the sublanguage should be included in the <gi>language</gi> element:

<eg>
<![ CDATA [
 <language iso639='jpn'>
    Japanese (specialized writing system for waka)
 </language>
]]>
</eg>

<!-- Syun:  you mentioned 'a particular school' of writers    -->
<!-- of waka.  Can you refine the wording of this example?    -->
<!-- Thanks.  -msm                                            --></p>

<p>When a writing system declaration is prepared solely in order to
document a coded character set or entity set suitable for use with many
natural languages, the content of the <gi>language</gi> element should
be <q>Various</q> (or the equivalent in the language of the WSD):

<eg>
<![ CDATA [
<writingSystemDeclaration
          lang=eng
          name='-//TEI P2: 1993//NOTATION WSD for ISO 646 IRV//FR'
          date='1993-05-29'>
  <language iso639=''>Plusieurs</language>
  <!-- ... -->
</writingSystemDeclaration>
]]>
</eg></p>

<p>The <gi>language</gi> element is formally defined thus:

<eg id=dwdla>
<![ CDATA [
<!-- 25.2:  Language identification                           -->
<!ELEMENT language      - O  (#PCDATA)                          >
<!ATTLIST language           %a.global;
          iso639             CDATA               #REQUIRED      >
<!-- This fragment is used in sec. 25.1                       -->
]]>
</eg>
</p></div2>

<div2 id="WDws"><head>Describing the Writing System</head>

<p>The writing system itself is described in general terms using the
following elements:

<list type=gloss>
<label><gi>script</gi></label>
<item>contains a prose description of the script declared by a 
writing
system declaration.</item>
<label><gi>direction</gi></label>
<item>specifies one or more conventional directions in which a 
language
is written using a given script.
Attributes include:
<list type=gloss>
<label><att>chars</att></label>
<item>indicates the order in which characters within a line are 
conventionally presented in this writing system
Suggested values include:
<list type=gloss>
<label><term>BT</term></label>
<item>bottom to top</item>
<label><term>LR</term></label>
<item>left to right</item>
<label><term>RL</term></label>
<item>right to left</item>
<label><term>TB</term></label>
<item>top to bottom</item>
</list></item>
<label><att>lines</att></label>
<item>indicates the order in which lines conventionally follow 
each other in this writing system.
Suggested values include:
<list type=gloss>
<label><term>BT</term></label>
<item>bottom to top</item>
<label><term>LR</term></label>
<item>left to right</item>
<label><term>RL</term></label>
<item>right to left</item>
<label><term>TB</term></label>
<item>top to bottom</item>
</list></item>
</list>
</item>
</list>
</p>

<p>The <gi>script</gi> element contains a prose description of the
script, alphabet, syllabary, or other system of writing used to write
the language in question.  The <gi>direction</gi> element indicates the
direction(s) in which the script is conventionally written.  Both these
elements are provided for the sake of human readers; neither is likely
to be suited to machine processing without human intervention.</p>

<p>The Latin alphabet conventionally used to write English, for example,
might be described thus:

<eg>
<![ CDATA [
<script>Latin alphabet (with diacritics for loan words)</script>
<direction chars=LR lines=TB>
]]>
</eg></p>

<p>The <att>chars</att> and <att>lines</att> attributes are used to
indicate the direction in which characters within a line, and lines on
the page, may legitimately be written using the script in question.  If
more than one direction is possible, the <gi>direction</gi> element may
repeat or its attributes may be given more complex values.  A script
written vertically top to bottom, with lines arranged either left to
right or right to left, for example, might be declared either thus:

<eg><![ CDATA [
<direction chars=TB lines=LR>
<direction chars=TB lines=RL>
]]>
</eg>

or thus:

<eg><![ CDATA [
<direction chars=TB lines='LR RL'>
]]>
</eg></p>

<p>In very complex cases, the attributes may be given prose values:

<eg><![ CDATA [
 <direction chars='boustrophedon:  LR, then RL, then LR, etc.'
            lines='TB'>
]]>
</eg>

or the element may be omitted entirely (in which case experts on the
script should be consulted for advice on proper processing):

<eg><![ CDATA [
 <script>Japanese (mixture of kanji, hiragana, katakana)</script>
 <!-- If you don't already know how Japanese is written,
      no DIRECTION element in the world will help you. -->
]]>
</eg></p>

<p>It should be noted that the <gi>direction</gi> element describes
conventional display only:  all scripts are subject to unusual treatment
for aesthetic or other reasons, and such unusual treatment need not be
foreseen here.  (The Latin alphabet, for example, although
conventionally written left-to-right, top-to-bottom, can be set
vertically in signs or in other special cases.)  Unusual methods of
arranging the text on a page are best documented within the document
instance by means of the global <att>rend</att> attribute.</p>

<p>The <gi>script</gi> and <gi>direction</gi> elements are declared
thus:

<eg id=dwdws>
<![ CDATA [
<!-- 25.3:  Script and writing direction                      -->
<!ELEMENT script        - O  (#PCDATA)                          >
<!ATTLIST script             %a.global;                         >
<!ELEMENT direction     - O  EMPTY                              >
<!ATTLIST direction          %a.global;
          lines              CDATA               #REQUIRED
          chars              CDATA               #REQUIRED      >
<!-- This fragment is used in sec. 25.1                       -->
]]>
</eg>
</p></div2>

<div2 id="WDcs"><head>Documenting the Character Set and Its Encoding</head>
<div3 id="WDcsba"><head>Base Components of the WSD</head>

<p>The characters or graphic symbols of the writing system are
documented in the <gi>characters</gi> element of the WSD.  This
documentation can take any of the following forms:

<list type="bullets">
<item>reference to an international standard, national standard, or
private coded character set</item>
<item>reference to a public set of SGML entities</item>
<item>reference to another WSD which documents the same script and
the same methods of representing it electronically</item>
<item>formal declaration of each graphic unit in the writing system</item>
<item>a combination of the above:  reference to one or more standard
coded character sets, entity sets, or writing system declarations,
followed by individual declaration of all exceptions</item>
</list></p>

<p>The coded character sets, entity sets, and external WSDs referred to
are called the <term>base components</term> of the writing system
declaration.  The base components of a WSD are declared within the
<gi>characters</gi> element using the following elements:

<list type=gloss>
<label><gi>characters</gi></label>
<item>contains a specification of the characters used in a 
particular
writing system to write a particular language, 
and of how those
characters are represented in electronic 
form.</item>
<label><gi>codedCharSet</gi></label>
<item>identifies a public or private coded character set which is 
used
as a basic component of a writing system declaration.</item>
<label><gi>baseWsd</gi></label>
<item>identifies a writing system declaration whose mappings 
among
characters, forms, entity names, and bit patterns 
are to be incorporated
(possibly with modifications) in 
this writing system declaration.</item>
<label><gi>entitySet</gi></label>
<item>identifies a public or private entity set whose mappings 
between
entity names and characters are to be incorporated 
(perhaps with
modifications) into this writing system 
declaration.</item>
</list>
</p>

<p>The elements <gi>codedCharSet</gi>, <gi>baseWsd</gi>, and
<gi>entitySet</gi> are all members of the class
<term>baseStandard</term> and inherit from it the following attributes:

<list type=gloss>
<label><att>name</att></label>
<item>gives the normal citation form for the standard being 
referred to.</item>
<label><att>authority</att></label>
<item>indicates the authority responsible for issuing the 
standard being referred to: the TEI, the International 
Organization for Standardization (ISO), a national body, or 
a private body.
Legal values are:
<list type=gloss>
<label><term>national</term></label>
<item>the character set or entity set was issued by a national 
standards body</item>
<label><term>none</term></label>
<item>the writing system declaration, character set, or entity 
set has not been publicly issued by any organization; it is 
specific to an individual text or project</item>
<label><term>iso</term></label>
<item>the character set or entity set was issued by ISO</item>
<label><term>tei</term></label>
<item>the base writing system declaration is a standard WSD 
issued by the Text Encoding Initiative</item>
<label><term>private</term></label>
<item>the writing system declaration, character set, or entity 
set was issued publicly by a private organization or 
project</item>
</list></item>
</list>
</p>

<p>Some simple examples of the use of these elements follow:

<eg><![ CDATA [
 <codedCharSet name='ANSI X3.4' authority='national'>
 <codedCharSet name='ISO 646: 1991' authority='ISO'>
 <baseWsd      name='-//TEI P3: 1994//WSD ISO 8859-1//EN'
               authority='TEI'>
 <entitySet    name='ISO 8879:1986//ENTITIES Added Latin 1//EN'
               authority='ISO'>
]]>
</eg></p>

<p>The base components identify the set of characters used in the
writing system, and further specify, for each character, the string(s)
of bytes and entity names used to encode it in the text.  This
information may be modified by further information given within the
<gi>exceptions</gi> element, as described below in section <ptr
target="WDcsex">.</p>

<p>The elements for identifying the base components of the writing
system declaration are declared thus:

<eg id=dwdcsba>
<![ CDATA [
<!-- 25.4.1:  Base components                                 -->
<!ELEMENT characters    - O  (codedCharSet*, baseWsd*, 
                             entitySet*, exceptions?)           >
<!ATTLIST characters         %a.global;                         >
<!ENTITY % a.baseStandard '
          name               CDATA               #REQUIRED
          authority          (tei | iso | national | private | 
                             none)               #REQUIRED'     >
<!ELEMENT codedCharSet  - O  EMPTY                              >
<!ATTLIST codedCharSet       %a.global;
                             %a.baseStandard;                   >
<!ELEMENT baseWsd       - O  EMPTY                              >
<!ATTLIST baseWsd            %a.global;
                             %a.baseStandard;                   >
<!ELEMENT entitySet     - O  EMPTY                              >
<!ATTLIST entitySet          %a.global;
                             %a.baseStandard;                   >
<!-- This fragment is used in sec. 25.1                       -->
]]>
</eg>
</p></div3>

<div3 id="WDcsex"><head>Exceptions in the WSD</head>

<p>The <gi>exceptions</gi> element contains definitions for any
character which differs in any respect from the specifications contained
in the base components of the WSD.  If no base components are named,
then every character in the writing system must be defined explicitly.</p>

<p>The documentation for each character in the writing system indicates
at least the following:

<list type="bullets">
<item>the string of bytes used to represent the character</item>
<item>whether the character is a letter, a punctuation mark, a
diacritical mark, or falls into some other class</item>
<item>a brief conventional name or description of the character</item>
<item>any standard or local entity names used for the character</item>
<item>the position of the character in the Universal Character Set (UCS)
defined by ISO 10646, if known</item>
<item>the position of the character's form in the tables prepared by the
Association for Font Information Interchange</item>
</list>

In addition, images of the character encoded in a graphics format or
other notation may be associated with the character as internal
or external figures.

This information is encoded using the following elements:

<list type=gloss>
<label><gi>exceptions</gi></label>
<item>documents ways in which a writing system declaration 
differs from
the coded character sets, base writing system 
declarations, and entity
sets which form its bases.</item>
<label><gi>character</gi></label>
<item>defines one unit in a writing system, supplementing or 
overriding
information provided in the base coded 
character sets, writing system
declarations, and entity 
sets.
Attributes include:
<list type=gloss>
<label><att>class</att></label>
<item>describes the function of the character using a prescribed 
classification.
Legal values are:
<list type=gloss>
<label><term>joiner</term></label>
<item>character is used to join a diacritic to the lexical 
character to which it applies (in some encoding schemes, 
the backspace control character may be used as a joiner; in 
others, a graphic character is used for the same function)</item>
<label><term>lexical</term></label>
<item>character is used in writing words (lexical items) of the 
language (includes members of syllabaries and ideographic 
systems, as well as composite letter-plus-diacritic 
combinations)</item>
<label><term>lexpunc</term></label>
<item>character can appear as a normal punctuation mark, but can 
also appear within a lexical item (and should usually, when 
occurring between two lexical characters, be treated as 
lexical---in English, hyphen and apostrophe are typically 
treated as members of this class)</item>
<label><term>space</term></label>
<item>character represents some form of white space (space 
character, horizontal or vertical tab, newline, etc.)</item>
<label><term>other</term></label>
<item>character does not fall into any of the other classes 
(dingbats and other unusual characters fall here)</item>
<label><term>digit</term></label>
<item>character is an Arabic decimal numeral (0, 1, ... 9) (does 
not include superscript numbers, circled numbers, numeric 
dingbats, etc.)</item>
<label><term>ld</term></label>
<item>character is a diacritic applying to the preceding lexical 
character</item>
<label><term>dia</term></label>
<item>character is a diacritic which is explicitly joined to a 
lexical character by a joiner character</item>
<label><term>punc</term></label>
<item>character is a punctuation mark which does not appear 
within lexical items</item>
<label><term>dl</term></label>
<item>character is a diacritic applying to the following lexical 
character</item>
</list></item>
</list>
</item>
<label><gi>desc</gi></label>
<item>(in a writing system declaration) contains a description of 
a
character or character form.</item>
<label><gi>form</gi></label>
<item>identifies one letter form taken by a particular character 
in a
writing system declaration.
Attributes include:
<list type=gloss>
<label><att>string</att></label>
<item>gives the byte string used to encode the letter form in the 
text.</item>
<label><att>codedCharSet</att></label>
<item>specifies which base coded character set the 
<att>string</att> value occurs in.</item>
<label><att>entityStd</att></label>
<item>gives the name of one or more entities defined for this 
character form in some standard entity set(s).</item>
<label><att>entityLoc</att></label>
<item>gives one or more entity names used locally for this 
character form.</item>
<label><att>ucs-4</att></label>
<item>gives the position of the character form in the thirty-two 
bit <socalled>universal character set</socalled> defined by 
ISO 10646.</item>
<label><att>afiicode</att></label>
<item>gives one or more codes associated with this letter form by 
the Association for Font Information Interchange.</item>
</list>
</item>
<label><gi>figure</gi></label>
<item>(in a writing system declaration) contains an image of a 
character
form, stored in-line in some declared notation.
Attributes include:
<list type=gloss>
<label><att>notation</att></label>
<item>identifies the notation in which the figure is encoded.</item>
</list>
</item>
<label><gi>extFigure</gi></label>
<item>(in a writing system declaration) refers to a figure or

illustration depicting the character form, which is stored 
in
some declared notation external to the text.
Attributes include:
<list type=gloss>
<label><att>notation</att></label>
<item>identifies the notation in which the figure is stored.</item>
<label><att>entity</att></label>
<item>gives the SGML name of the external entity which contains 
the figure.</item>
</list>
</item>
</list>
</p>

<p>The <gi>exceptions</gi> element contains a series of
<gi>character</gi> elements only, each of which may contain descriptions
of the character (including its name), notes, and a series of
<gi>form</gi> elements documenting the different forms the character can
take.  Attributes on the <gi>character</gi> and <gi>form</gi> elements
are used to convey the information mentioned above:  byte string, entity
names, UCS-4 code, etc.</p>

<p>A simple example:

<eg>
<![ CDATA [
<character class=lexical>
  <form string='A' ucs-4='0041' afiicode='0041'>
    <desc>Latin capital letter A</desc>
  </form>
</character>
]]>
</eg></p>

<p>When transliteration schemes are used, the <att>string</att> used to
encode the character will typically be in a different alphabet:

<eg>
<![ CDATA [
<character class=lexical>
  <form string='*G' entityStd="Ggr" ucs-4='0393' afiicode='260044'>
    <desc>Greek capital letter Gamma</desc>
  </form>
</character>
]]>
</eg></p>

<p>The UCS-4 code is given as eight hexadecimal digits, one for each
four bits of the thirty-two-bit value. For legibility a hyphen may be
inserted as a separator after the fourth hexadecimal digit:
<code>00000308</code> has the same meaning as <code>0000-0308</code>.  Since in
almost all cases at present the leading sixteen bits are zero, however,
by convention the leading four hexadecimal zeros may be dropped
entirely:  the value <code>0308</code> is identical in meaning to the value
<code>0000-0308</code>.</p>

<p>In some cases, the character is represented not as a single UCS
character but as a sequence of such characters; in this case, each
thirty-two-bit value except the last must be followed by a plus sign:

<eg>
<![ CDATA [
<character class='lexical'>
  <form string='*=+U'
        entityStd="Ucdgr"
        ucs-4='03A5+0302+0308'
        afiicode='F300EC'>
            <desc>Greek capital letter Upsilon with
                  circumflex and diaresis</desc>
  </form>
</character>
]]>
</eg>
<!-- is this optional? or required? could it be               -->
<!-- '0000030500000302' etc?  (lb)                            --></p>
<p>If a given <gi>character</gi> element has more than one encoding
using ISO 10646 (e.g. both as <q>a-umlaut</q> and as <q>a</q> plus
<q>umlaut</q>), then both encodings may be given, separated by blanks:

<eg>
<![ CDATA [
<character class='lexical'>
  <form string=''
        entityStd="Auml"
        afiicode='F127"
        ucs-4='0041+0308 00C4' >
            <desc>Latin capital letter A with umlaut</desc>
  </form>
</character>
]]>
</eg>


<!-- Drop example until we can get appropriate JIS codes to   -->
<!-- go in here (LB) Right. (MSM)                             --></p>

<p>In most cases, identifying the character or character form by means
of its UCS-4 and AFII codes will suffice to identify the character for
all later users of the WSD.  In some cases, however, further information
must be provided.
<!-- suppress this example when JIS example is used. (msm) -->
This may be provided in a <gi>note</gi> attached to the
<gi>character</gi> or <gi>form</gi> element:
<eg>
<![ CDATA [
<character class='lexical'>
  <form string='N'
        entityLoc="nn" >
        ucs-4="0274"   >
            <desc>Standard ms symbol for double n.</desc>
  </form>
  <note>This character has the form of a capital-letter N,
        but is written the same height as a lower-case N.
        Its appearance is thus that of UCS-4 0274, but it
        does not have the same semantics.
  </note>
</character>

]]>
</eg>

<!-- Use this example when we have real values. (msm) -->

<!-- < p > The mapping between Han characters in ISO 10646    -->
<!-- and those in the national character sets of China,       -->
<!-- Japan, and Korea, for example, is at present not fully   -->
<!-- documented in ISO 10646; accompanying commentary in      -->
<!-- prose, identifying the character by its position in      -->
<!-- one of the national character sets, may therefore be     -->
<!-- found useful.  This may be done in a < gi > note < /gi   -->
<!-- >  attached to the  < gi > character < /gi >  or  < gi   -->
<!-- > form < /gi > element:                                  -->

<!--  < eg >                                                  -->
<!--  < ![ CDATA [                                            -->
<!--  < character class='lexical' >                           -->
<!--    < form string='ssss'                                  -->
<!--         entityLoc="JISnnn.nnn"                           -->
<!--         ucs-4='xxxx'  >                                  -->
<!--              < desc > Chinese character ccccc < /desc >  -->
<!--    < /form >                                             -->
<!--    < note > This character has position nnn/nnn in JIS 0208; -->
<!--         the UCS-4 code is not completely certain.        -->
<!--    < /note >                                             -->
<!--  < /character >                                          -->
<!--                                                          -->
<!--  ]] >                                                    -->
<!--  < /eg >                                                 --></p>

<p>In some cases, it will be necessary or useful to provide an image of
the character in question, or to refer to a standard reference work for
such an image.  The following <gi>character</gi> element might be used
to describe, for example, a common Old French abbreviation for
<q>est</q>, for which the local entity <ident type="ent">est</ident> has been
defined:

<eg>
<![ CDATA [
<character class='lexical'>
  <form string='' entityLoc="est">
     <desc>Old French abbreviation for 'est':  lowercase
           'e' with a tilde or macron above.</desc>
     <note>For an image of this character, see
           Cappelli, p. 113, column 1, line 4
           (leftmost and rightmost item).</note>
  </form>
</character>
]]>
</eg>

Here, <q>Cappelli</q> is the name of a standard reference work which may
be consulted to see what the character in question looks like.<note
place="foot"><title>Dizionario di Abbreviature latine ed italiane</title>
per cura di Adriano Cappelli, 6th ed. (Milan:  Ulrico Hoepli, 1979).
This work on Latin abbreviations might be less convenient for the
purpose than one concentrating on Old French, but it is more widely
used than any other.</note></p>

<p>Where recourse to reference works is impossible, a picture of the
character may be encoded using any standard graphics format, and
associated with the character by standard SGML techniques.  The SGML
document must then have:
<list type="bullets">
<item>an SGML notation declaration for the graphics format used</item>
<item>an external entity declaration for the file containing the image</item>
<item>an <gi>extFigure</gi> element to name the notation and the entity</item>
</list>

For a discussion of graphic images and of the declaration of non-SGML
notations, see chapter <ptr target="FT">.  If the Old French abbreviation
is encoded using CGM (Computer Graphics Metafile) format in a file
called <ident type="file">est.cgm</ident>, then it may be associated with the appropriate
character declaration as follows.  In the DTD subset of the WSD, the
following declarations are required:

<eg>
<![ CDATA [
 <!NOTATION cgm PUBLIC 'ISO 8632/2//NOTATION
                        Computer Graphics Metafile
                        Character encoding//EN'>
 <!ENTITY estFigure system 'est.cgm' NDATA cgm>
]]>
</eg>

In the body of the WSD itself:

<eg>
<![ CDATA [
<character class='lexical'>
  <form string=''
        entityLoc="est">
            <desc>Old French abbreviation for 'est':  lowercase
                  'e' with a tilde or macron above.
            </desc>
            <extFigure notation='cgm' entity='estFigure'>
            <note>For an image of this character, see
                  Cappelli, p. 110, column 1, line 4
                  (leftmost and rightmost item).
            </note>
  </form>
</character>
]]>
</eg>

Despite now having a picture of the character, we retain the prose
description and reference to Cappelli, for the sake of those without
ready access to the appropriate graphics processors.

<!-- < p > Figures and detailed descriptions of the           -->
<!-- character form are particularly important when the       -->
<!-- encoding is to distinguish different forms or shapes     -->
<!-- of the same character.  For example, consider the        -->
<!-- situation described in chapter  < xref target=CH > ,     -->
<!-- in which the encoder wishes to distinguish among three   -->
<!-- distinct forms of the letter < cited > r < /cited >      -->
<!-- because they may help trace the history of the           -->
<!-- manuscript.  The three forms may be documented thus in   -->
<!-- the WSD:                                                 -->

<!--  < eg >                                                  -->
<!--  < ![ CDATA [                                            -->
<!--                                                          -->
<!--   (three-R example here)                                 --></p>


<p>The <gi>exceptions</gi> element and its contents are declared thus:

<eg id=dwdcsex>
<![ CDATA [
<!-- 25.4.2:  Exceptions to the base components               -->
<!ELEMENT exceptions    - O  (character*)                       >
<!ATTLIST exceptions         %a.global;                         >
<!ELEMENT character     - O  (desc*, form+, note*)              >
<!ATTLIST character          %a.global;
          class              (lexical | punc | lexpunc | digit 
                             | space | DL | LD | dia | joiner | 
                             other)              lexical        >
<!ELEMENT desc          - O  (#PCDATA)                          >
<!ATTLIST desc               %a.global;                         >
<!ELEMENT form          - O  (desc+, (figure | extFigure)*, 
                             note*)                             >
<!ATTLIST form               %a.global;
          string             CDATA               #IMPLIED
          entityStd          ENTITIES            #IMPLIED
          entityLoc          ENTITIES            #IMPLIED
          ucs-4              CDATA               #IMPLIED
          afiicode           CDATA               #IMPLIED
          codedCharSet       IDREF               #IMPLIED       >
<!ELEMENT figure        - -  CDATA                              >
<!ATTLIST figure             %a.global;
          notation           NAME                #REQUIRED      >
<!ELEMENT extFigure     - O  EMPTY                              >
<!ATTLIST extFigure          %a.global;
          notation           NAME                #REQUIRED
          entity             ENTITY              #REQUIRED      >
<!-- This fragment is used in sec. 25.1                       -->
]]>
</eg>
</p></div3>

<div3 id="WDcscc"><head>Documenting Coded Character Sets and Entity Sets</head>

<p>Public or private coded character sets and entity sets may be
usefully documented using WSDs; the WSD will make explicit some
information (such as the UCS-4 and AFII codes) not normally given
explicitly in character set standards or public entity sets.  The coded
character set or entity set being documented should be included by means
of a <gi>codedCharSet</gi> or <gi>entitySet</gi> element; the
<gi>exceptions</gi> element should include one <gi>character</gi>
element for each character included in the character set or the entity
set.  Deciding whether to treat two entities or two bit patterns as
separate characters or as forms of the same character will require
knowledge of the script involved, and different encoders may reach
different decisions.  In cases of doubt, though, it is usually
acceptable practice to treat each bit pattern in a coded character set,
and each entity in an entity set, as a distinct character.</p>

<p>A non-standard local coded character set (e.g. an EBCDIC character
set) may be documented in a WSD by defining one <gi>character</gi>
element for each printable code point in the character set, adding the
names of standard (and local) entities, UCS-4 codes, and AFII codes as
appropriate.  Since this extra information is useful in packing
documents for interchange, and in processing pattern
arguments in the TEI extended-pointer syntax described in section
<ptr target="SAxr">, those responsible for a
local installation are strongly encouraged to document the local system
character set in a WSD, if it is not already so documented.</p></div3>

<div3 id="WDcstr"><head>Documenting Transliteration Schemes</head>

<p>When a script is encoded not in a character set designed for it,
but in one designed for another script, (e.g. Greek encoded using the
Latin alphabet), a transliteration scheme is necessary.  In
documenting such a transliteration scheme, the coded character set
actually in use should be named as a base component.  An
<gi>exceptions</gi> element can then be used to override the normal
meaning of the individual byte strings used in the transliteration.
For example, the following <gi>character</gi> element overrides the
usual association of the byte representing <code>A</code> with the Latin
letter <code>A</code> and substitutes instead an association with the Greek
letter alpha:

<eg>
<![ CDATA [
<character class=lexical>
  <form string='A' entityStd="agr" ucs-4='03B1' afiicode='260061'>
    <desc>Greek small letter alpha</desc>
  </form>
</character>
]]>
</eg>

Care should be taken in choosing or developing transliteration schemes
to ensure that they are unambiguously reversible.</p></div3></div2>

<div2 id="WDno"><head>Notes in the WSD</head>

<p>Notes on the WSD, individual characters, or individual character
forms may be included in the <gi>note</gi> element at the appropriate
level.

<list type=gloss>
<label><gi>note</gi></label>
<item>(in a writing system) contains a note of any type.</item>
</list>
</p>

<p>Unlike its counterpart in the main TEI DTD, the <gi>note</gi> element
within the writing system declaration may contain no paragraphs and no
phrase-level elements:  only character data.  It is formally declared
thus:

<eg id=dwdno>
<![ CDATA [
<!-- 25.5:  Notes                                             -->
<!ELEMENT note          - O  (#PCDATA)                          >
<!ATTLIST note               %a.global;                         >
<!-- This fragment is used in sec. 25.1                       -->
]]>
</eg>
</p></div2>

<div2 id="WDlk"><head>Linkage between WSD and Main Document</head>

<p>The writing system declaration is associated with different portions
of a main document by means of the global <att>lang</att> attribute.
This attribute is defined as an SGML IDREF and its value must be the
SGML identifier on a <gi>language</gi> element within the TEI header of
the main document.  The <gi>language</gi> element in turn provides, in
its <att>wsd</att> attribute, the SGML name of the entity (usually an
external file) containing the writing system declaration associated with
that <att>lang</att> value. For a more detailed account of this
process, compare the discussion in section <ptr target="FDlk">.</p>

<p>At least one writing system declaration must be associated with any
TEI document:  this follows from the requirement that a value be
specified for the <att>lang</att> attribute on the outermost element
(<gi>tei.2</gi> or <gi>teiCorpus.2</gi>) of any TEI document, since the
<att>lang</att> attribute is required to point at a <gi>language</gi>
element in the TEI header, which in turn is required to indicate an
entity containing the writing system declaration associated with that
language.</p></div2>


<div2 id="WDxw"><head>Predefined TEI WSDs</head>

<p>The Text Encoding Initiative has defined standard writing system
declarations for the following languages and scripts:

<list type="bullets">

<item>The nine official languages of the European Community ( Danish,
Dutch, English, French, Greek, German, Italian, Portuguese, and
Spanish), encoded using the character set ISO 8859-1</item>
<item>Hebrew (using ISO 8859-8)</item>
<item>Russian (using ISO 8859-5)</item>
<item>classical Greek (using the Thesaurus Linguae
Graecae's Beta Code transliteration scheme)</item>
</list></p>

<p>Work is underway on a standard writing system declarations for
Japanese; resources permitting, declarations for Korean and Chinese will
also be made.</p>

<p>In addition to the language-specific WSDs just mentioned, the TEI has
defined a number of WSDs to document specific public coded character
sets and entity sets.  These are used as components in the
language-specific WSDs, and may be similarly used for locally developed
WSDs.  WSDs for specific ISO standard character sets include:

<list type="bullets">
<item>ISO 646 (non-national subset)</item>
<item>ISO 646 (International Reference Version)</item>
<item>ISO 8859-1 (Latin 1, Western Europe)</item>
<item>ISO 8859-2 (Latin 2, Eastern Europe)</item>
<item>ISO 8859-5 (Latin and Cyrillic)</item>
<item>ISO 8859-7 (Latin and Greek)</item>
<item>ISO 8859-8 (Latin and Hebrew)</item>
<item>ISO 8859-9 (Western Europe and Turkey)</item>
</list></p>

<p>Writing system declarations are also under preparation for a number
of commercial character sets in wide use:

<list type="bullets">
<item>IBM Code Page 437 (IBM PC, early models)</item>
<item>IBM Code Page 850 (IBM PS/2 and later-model IBM PCs)</item>
<item>IBM Code Page 1014</item>
<item>Apple Macintosh default system character set</item>
<item>Adobe Postscript default character set</item>
</list></p>

<p>The Text Encoding Initiative has prepared entity sets for use in
transcribing some languages; these are distributed both as SGML entity
sets and as TEI writing system declarations documenting those entity
sets:

<list type="bullets">
<item>-//TEI P3: 1994//ENTITIES Arabic//EN</item>
<item>-//TEI P3: 1994//ENTITIES Coptic//EN</item>
<item>-//TEI P3: 1994//ENTITIES Classical Greek//EN</item>
<item>-//TEI P3: 1994//ENTITIES International Phonetic Alphabet//EN</item>
</list>

WSDs will also be prepared for other standard entity sets, including:

<list type="bullets">
<item>ISO 8879: 1986//ENTITIES Added Latin 1//EN</item>
<item>ISO 8879: 1986//ENTITIES Added Latin 2//EN</item>
<item>ISO 8879: 1986//ENTITIES Russian Cyrillic/EN</item>
<item>ISO 8879: 1986//ENTITIES Non-Russian Cyrillic//EN</item>
<item>ISO 8879: 1986//ENTITIES Greek Letters//EN</item>
<item>ISO 8879: 1986//ENTITIES Diacritical Marks//EN</item>
<item>ISO 8879: 1986//ENTITIES Box and Line Drawing//EN</item>
<item>ISO 8879: 1986//ENTITIES Numeric and Special Graphic//EN</item>
<item>ISO 8879: 1986//ENTITIES Publishing//EN</item>
<item>ISO 8879: 1986//ENTITIES General Technical//EN</item>
</list></p>

<p>All TEI writing system declarations are distributed with the TEI
document type definitions.

<!-- div2 id=WSus > < head > Creating New WSDs < / head --></p>

<p>The standard TEI writing system declarations are expected to meet the
needs of many encoders; some, however, will need to prepare new WSDs to
describe character-encoding schemes not included in the standard WSDs.
<!-- This paragraph needs expansion.  But I'm tired. -msm     -->
<!-- Me too. This sentence doesnt seem to say very much. LB --></p></div2>

<div2 id="WDse"><head>Details of WSD Semantics</head>

<p>This section describes the meaning of the WSD in more formal terms
than have been used elsewhere in this chapter; it can be skipped by most
readers, but should be read carefully by those who wish to write complex
writing system declarations or to implement software to process writing
system declarations or to interpret them in the processing of
TEI-conformant documents.</p>

<div3 id="WDsege"><head>WSD Semantics:  General Principles</head>

<p>A writing system declaration provides a complicated bundle of
mappings:

<list type="bullets">
<item>a 1:1 partial function from strings in given coded character sets
to character forms</item>
<item>a function from entity names to character forms, and therefore
derivatively a function from entity names to strings</item>
<item>a function from character forms to characters, and therefore
derivatively:
<list type="bullets">
<item>a function from strings to characters</item>
<item>a function from entity names to characters</item>
</list></item>
<item>a relation between UCS-4 codes and character forms</item>
<item>a relation between AFII codes and character forms</item>
<item>a function from UCS-4 codes to characters</item>
<item>a relation from AFII codes to characters</item>
</list>

To ensure that the relations described as functions are in fact
functional, the following constraints apply on the WSD:

<list type="bullets">

<item>No two <gi>form</gi> elements can have the same values for both
<att>codedCharSet</att> and <att>string</att>.  Since usually there is
only one <gi>codedCharSet</gi> used as a basic component, this usually
means each <att>string</att> attribute value must be unique in the WSD.</item>

<item>No two <gi>form</gi> elements can name the same entity in either
<att>entityStd</att> or <att>entityLoc</att>.  It is legal, though
pointless, for both <att>entityStd</att> and <att>entityLoc</att> on the
same <gi>form</gi> element to name the same entity.</item>

<item>More than one <gi>form</gi> element may have the same
<att>UCS-4</att> value, but if so
they must be within the same <gi>character</gi> element.

<!-- n.b. removed the restriction on AFII codes -msm --></item>

</list>

These constraints may be summarized thus:  one
<socalled>character</socalled> (however the creator of the WSD defines a
character) can be associated with more than one byte string, entity
name, UCS-4 code, or AFII code, but any single byte string (given a
specific coded character set), any single entity name, and any single
UCS-4 code must be associated with only one single
<gi>character</gi>.  One can, for example, associate both
<q>tilde</q> and
<q>logical not</q> with a <gi>character</gi> meaning <q>logical
negation</q>, but one cannot associate both a <gi>character</gi> called
<q>tilde</q> and one called <q>logical negation</q> with the ASCII
character 7/14:  given a 7/14 in the text, it must be unambiguously
clear whether the character is a <q>tilde</q> or a <q>logical
negation</q>.  If one wishes to retain the ambiguity, one must define a
<gi>character</gi> called (for example)
<q>logical-not or tilde or swung-dash</q>.
Similar restrictions apply to entity names and UCS-4 codes:  each must
be associated with a single <gi>character</gi> element.</p></div3>

<div3 id="WDsebc"><head>Semantics of WSD Base Components</head>

<p>The effects of naming coded character sets, entity sets, and other
WSDs as base components may now be defined thus:


<list type="bullets">

<item>reference to a coded character set makes available the set of
bit-pattern-to-character mappings defined in the coded character set.
That is, if a WSD refers to a coded character set, then whenever the WSD is
in use, any character in that coded character set may be used with its
standard meaning unless it has been redefined using the
<gi>exceptions</gi> element.  It is recommended that a WSD be provided
for each coded character set, to make the mappings fully explicit.</item>

<item>reference to an entity set makes available the set of
entity-name-to-character mappings defined in the entity set.  It is
assumed that standard public entity sets contain enough information to
count as a valid mapping; for private entity sets, the preferred method
of providing the necessary information is to define the entity set in a
WSD.  If for example a WSD refers to the ISO Latin 1 entity set, then
whenever that WSD is in use, any entity in that set may be used with
its public meaning, unless it has been redefined in the
<gi>exceptions</gi> element.</item>

<item>reference to a WSD makes available the set of mappings declared in
that WSD; the language and writing system direction information given
in the base WSD is ignored.</item>

</list></p>

<p>If reference is made only to standard character sets and entity
sets, there is no mechanical method of associating the
<socalled>characters</socalled> involved in one mapping with those
involved in another.  E.g. a reference to ISO 646 IRV provides a map
from code point 5/11 to a character one might call <q>left square
bracket</q>.  A reference to entity set <ident type="file">ISOpub1</ident>
provides a map from the entity name <ident type="ent">lbr</ident> to
what should probably be considered the same character.  There is
however no guarantee that any processing software will necessarily be
sufficiently intelligent to make this association of mappings
automatically; it requires hard-coded knowledge of the specifics of
certain character sets and entity sets.</p>

<p>When, however, base WSDs are used to document important entity sets
and character sets, it does become possible to define mechanical
methods of associating <gi>character</gi> elements in different base
components.</p></div3>

<div3 id="WDsemb"><head>Multiple Base Components</head>

<p>When multiple bases of the same type are referred to, the effects are
these:

<list type="bullets">
<item>if more than one coded character set is named, then it is
expected that character-set shifting as described in ISO 2022 or
some equivalent is in use, and proper shifting is the responsibility
of the user.  All strings in the WSD must specify the ID of
the proper coded-character-set base, using the
<att>codedCharSet</att> attribute.</item>

<item>if more than one entity set is named, then entity names from all
named sets may be used as values of the <att>entityStd</att> and
<att>entityLoc</att> attributes.  If the same name occurs in more than
one entity set, the assumption is made that it refers each time to the
same character.</item>

<item>if more than one base WSD is named, then all characters declared
in all the WSDs are available.  For this case, we can define what
happens to merge the different base components more precisely than for
the other types of base component:

<list type="bullets">

<item>any two <gi>form</gi> elements which name the same entity or the
same string in the same coded character set are considered the same
form, and are merged as described below in section <ptr
target="WDseme">.</item>

<item>any two <gi>form</gi> elements which give the same UCS-4 code are
considered forms of the same <gi>character</gi>, and their parent
<gi>character</gi> elements are merged.  The forms themselves may be
merged or may remain distinct:  if the forms have conflicting values for
any attribute, they must remain distinct; if they don't conflict, they
may be merged, at the option of the processing software.  In the general
case, there might be more than one way to perform mergers, so merger is
not required.</item>
</list></item>
</list></p>

<p>The result of invoking multiple base WSDs is thus a merged WSD in
which the <gi>form</gi> and <gi>character</gi> elements have been merged
as prescribed.  If the merger is impossible because the two WSDs are
incompatible, a semantic error occurs.  A set of WSDs is compatible and
may be invoked together if all of the following are true:

<list type="bullets">
       <item>any given entity name is associated with a single string
          (in a given coded character set) and a single character class</item>
       <item>any given string or UCS-4 code is
          associated with a single character class</item>
</list></p></div3>


<div3 id="WDseex"><head>Semantics of Exceptions</head>

<p>We can now define the semantics of the <gi>exceptions</gi> element.</p>

<p>The base components provide a preliminary set of mappings, as
described above.  For convenience let us call this the <term>default
map</term>.  The <gi>exceptions</gi> element allows the user to modify
the default map by defining further mappings and by overriding parts of
the default map.  There are three cases:  a new <gi>character</gi>
element replaces an old one, is merged with an old one, or is added to
the set without affecting any old ones.</p>

<div4 id="WDsex1"><head>Case 1: replacement</head>

<p>If a <gi>form</gi> element within <gi>exceptions</gi> (F-new)
<socalled>collides</socalled> with a <gi>form</gi> element in the
default map (F-old), then the parent <gi>character</gi> element of
F-new replaces the parent element of F-old.  Two <gi>form</gi>
elements collide if they have the same values for
<att>codedCharSet</att> and <att>string</att>.  (N.B. if this
condition occurs within the default map, the two <gi>form</gi>
elements are merged.)  </p>
<p>For example, to define the TLG Beta code transliteration of alpha
as <code>a</code> we first name ISO 646 IRV as a base component; this has
the effect of creating the following (possibly imaginary)
<gi>form</gi> element:


<eg>
<![ CDATA [
          <character id=a class=lexical>
            <form string='a'>
              <desc>lowercase latin letter A</desc>
            </form>
          </character>
]]>
</eg></p>

<p>We then include the following within the <gi>exception</gi> element:

<eg>
<![ CDATA [
          <character id=alpha class=lexical>
            <form string='a' entityStd='gkalpha'>
              <desc>lowercase Greek alpha</desc>
            </form>
          </character>
]]>
</eg></p>

<p>This overrides the <gi>character</gi> element for latin A, and
indicates that in the transliteration scheme documented by this WSD,
character 6/01 represents a Greek alpha, no matter what ISO 646 says.</p></div4>

<div4 id="WDsex2"><head>Case 2: merger</head>

<p>If a <gi>character</gi> element within <gi>exceptions</gi>
<socalled>overlaps</socalled> with one in the default map, then the
two <gi>character</gi> elements are merged.  Two <gi>character</gi>
elements overlap if any of their <gi>form</gi> elements name the same
entity or UCS-4 code.  (N.B. if these conditions occur within the
default map, they lead to merger either of the two <gi>form</gi>
elements --- for entity name overlap --- or of the two
<gi>character</gi> elements.)  </p>

<p>For example:  suppose we wish to document the three-Rs transcription
described in section <ptr target="CHlon">.  We name ISO 646 IRV as a base
character set (or WSD) and add the following exceptions:

<eg>
<![ CDATA [
  <exceptions>
    <character id=r class=lexical>
        <desc>lowercase latin letter r</desc>
        <form string='' entityLoc='r' ucs-4='0072'>
            <desc>'normal' form, similar to modern print r and to
                  Cappelli, p. 318, line 2, items 3, 6, 15.</desc>
        </form>
        <form string='' entityLoc='r2' ucs-4='0072'>
            <desc>'round' form, usually following 'o', similar
                  to a modern Arabic digit 2 (or to Cappelli, p. 318,
                  line 2, items 13 and 14)</desc>
        </form>
        <form string='' entityLoc='r3' ucs-4='0072'>
            <desc>'small-cap' form, like a capital R but
                  same height as lowercase (cf. Cappelli, p. 318,
                  line 1, items 2 and 3)</desc>
        </form>
    </character>
  </exceptions>
]]>
</eg></p>

<p>As a second example, imagine we wish to document a local entity set
for Old English in which we define local entities t (thorn), d (eth),
and a (aesc).  Assuming the TEI has provided a WSD for the Latin 1
entities, the whole WSD is this:

<eg>
<![ CDATA [
  <writingSystemDeclaration
         name='-//OTA 1990//NOTATION WSD Old English entities//EN'
         date='1993-05-25'
         lang=eng>
    <language iso639=''>Various</language>
    <script>Latin alphabet, extended</script>
    <direction lines=TB chars=LR>
    <characters>
          <baseWsd name='-//TEI P3: 1994//NOTATION
                         WSD ISO Added Latin 1//EN'
                   authority=TEI>
          <exceptions>
              <character class=lexical>
                  <form entityStd='thorn' entityLoc='t'>
                      <desc>lowercase latin letter thorn</desc>
                      </form></character>
              <character class=lexical>
                  <form entityStd='Thorn' entityLoc='T'>
                      <desc>uppercase latin letter thorn</desc>
                      </form></character>
              <character class=lexical>
                  <form entityStd='eth' entityLoc='d'>
                      <desc>lowercase latin letter eth</desc>
                      </form></character>
              <character class=lexical>
                  <form entityStd='Eth' entityLoc='D'>
                      <desc>uppercase latin letter eth</desc>
                      </form></character>
              <character class=lexical>
                  <form entityStd='aelig' entityLoc='a'>
                      <desc>lowercase latin aesc (= digraph aelig)</desc>
                      </form></character>
              <character class=lexical>
                  <form entityStd='AElig' entityLoc='A'>
                      <desc>uppercase latin aesc (= digraph aelig)</desc>
                      </form></character>
          </exceptions>
    </characters>
    <note>This WSD is just to document the local entities; it should be
          named as a base WSD by the actual writing system declaration.
    </note>
  </writingSystemDeclaration>
]]>
</eg></p>

<p>This has the effect of merging the <gi>character</gi> elements for
<code>thorn</code>, <code>eth</code>, and <code>aesc</code> (or a-e
ligature) defined in the ISO Latin 1 WSD with those given here, which
specify the local entity name.  The <gi>form</gi> elements may or may
not be merged, so the software may or may not actually realize that
the local entity <ident type="ent">t</ident> corresponds with the UCS-4
code given in the TEI WSD for ISO Latin 1.</p>

<p>The full local WSD can then be this:

<eg>
<![ CDATA [
  <writingSystemDeclaration
         name='-//OTA 1993//NOTATION Old English WSD//EN'
         date='1993-05-25'
         lang=eng>
    <language iso639=ang>Anglo-Saxon / Old English</language>
    <script>Latin alphabet, extended</script>
    <direction lines=TB chars=LR>
    <characters>
          <baseWsd name='-//TEI P3: 1994//NOTATION WSD ISO 646 IRV//EN'
                   authority='TEI'>
          <baseWsd name='-//OTA 1990//NOTATION
                         WSD Old English entities//EN'
                   authority='private'>
          <baseWsd name='-//TEI P3: 1994//NOTATION
                         WSD ISO Added Latin 1//EN'
                   authority='TEI'>
    </characters>
  </writingSystemDeclaration>
]]>
</eg></p>

<p>We refer explicitly to ISO Latin 1, for clarity, but in theory it
has already been included in <ident type="file">-//OTA 1990//WSD Old English
entities//EN</ident> and need not be repeated.  At this time, the
rules for merger would force our local <gi>form</gi> elements to be
merged with the standard <gi>form</gi> elements, so the local entity
<ident type="ent">t</ident> would map correctly into the UCS-4 character
set.</p></div4>


<div4 id="WDsex3"><head>Case 3: expansion</head>

<p>If a <gi>character</gi> element has no <gi>form</gi>
children which collide with anything in the default map, and does not
itself overlap with anything in the default map, then it is simply added
to the default map.
</p>

<p>For example, suppose we wish to document an abbreviation used for
Old French <q>est</q> in our manuscript, which resembles e with a
tilde or macron.  Since we expect we may have more abbreviations for
<q>est</q>, we use the local entity name <ident type="ent">est1</ident>
for this one.  Within <gi>exceptions</gi>, we declare the abbreviation
thus:

<eg>
<![ CDATA [
          <character id=est1 class=lexical>
            <form string='' entityLoc='est1'>
              <desc>abbreviation for 'est', lowercase latin e
                    with a tilde or macron above, similar to
                    Cappelli p. 113, col 1, items 4(a) and 8.</desc>
            </form>
          </character>
]]>
</eg></p></div4></div3>

<div3 id="WDseme"><head>Merger of Form and Character Elements</head>

<p>In some cases, the <gi>form</gi> and <gi>character</gi> elements
introduced notionally by reference to a coded character set or entity
set, or introduced explicitly by reference to a base WSD, may be
considered as referring to identical objects; this is called
<term>merger</term>.  Two <gi>form</gi> elements F1 and F2 can be merged
if they both have the same values for <att>codedCharSet</att> and
<att>string</att>, or if <att>codedCharSet</att> and <att>string</att>
are unspecified (implied) in at least one.  When F1 and F2 are merged,
the result is a (possibly imaginary) <gi>form</gi> element (F3) the
attributes of which are derived thus:

<list type="bullets">

<item>if F1 has no value for a <att>codedCharSet</att>, then F3 has the
same value for this attribute as does F2.  If both F1 and F2 have
explicit values, the values must be identical.</item>

<item>if F1 has an empty string for <att>string</att>, then F3 has the
same value as F2.  If both have values other than the empty string,
they must be identical.</item>

<item>for <att>entityStd</att>, <att>entityLoc</att>, <att>ucs-4</att>,
and <att>afiiCode</att>, F3 gets a value containing all the entity names
or codes which appear in the corresponding attribute values of either F1
or F2.  I.e. the attribute values are viewed as sets, and F3 gets the
union of F1 and F2.</item>

</list></p>

<p>The children of the new element are derived by taking all the
<gi>desc</gi> children of F1, then all the <gi>desc</gi> children of F2;
all the <gi>figure</gi> children of F1, then those of F2; all the
<gi>note</gi> children of F1, then all the <gi>note</gi> children of F2.
In other words, all the children of the source elements survive as
children of the result element.</p>

<p>Provided that their forms are compatible, two <gi>character</gi>
elements C1 and C2 may be merged unless their values for
<att>class</att> differ.  The resulting <gi>character</gi> element C3
has the same value for its <att>class</att> attribute as C1 and C2,
and all the children of C1 and C2 are made children of C3
(<gi>desc</gi> children first, then <gi>form</gi> children).</p>

<p>Note that merger is sometimes required by the semantic rules given
above, and sometimes optional.  If merger is required but not legal
(because the two elements to be merged are incompatible), then a
semantic error has occurred and the two base WSDs which give rise to it
should not be invoked together.
</p>
</div3></div2></div1>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-default-dtd-file:"~/lib/psgml/p2odd.ced"
sgml-parent-document:("/home/tei/P3/Master/Odds/p2.odd" "TEI.1" "TEXT" "BODY" "DIV1")
sgml-omittag:t
sgml-shorttag:t
End:
-->
             <!-- 25 Writing System Decl. -->
