<!-- $Id: p2sa.odd,v 1.11 1998/02/01 16:52:05 tei Exp $ -->
<!--*
    * $Log: p2sa.odd,v $
    * Revision 1.11  1998/02/01 16:52:05  tei
    * change system identifiers to public identifiers
    * fix log keyword
    * normalize SGML
    *
    * Revision 1.10  98/01/28  11:09:58  cmsmcq
    * LB changes of January 1998
    *
    * Revision 1.9  1994/03/27  21:47:19  msmcq
    * Correction of typos found by SJ, DB et al.
    *
    * Revision 1.8  1994/03/21  14:12:10  lou
    * second mass typo clearup
    *
    * Revision 1.5  1994/02/12  10:22:43  lou
    * *** empty log message ***
    *
    * Revision 1.3  1993/09/16  19:01:31  msmcq
    * Minor SGML cleanup, add RCS log keyword
    * -->
<!-- Revisions:                                               -->
<!-- 7 jan 98 : LB : tag xref to sasymp properly -->
<!-- 1-7 feb: several not so minor changes in wording; add  -->
<!--         declaration for pointer and pointerGroup   classes -->
<!-- 19 dec 93 : LB change name of classdoc ANA -> cllink -->
<!-- 93-09-15 : MSM : merge TL changes of 23 July             -->
<!-- 93-09-15 : MSM : restore refs to subsections             -->
<!-- 93-09-15 : MSM : process TDL's changes                   -->
<!-- 93-07-23 : DTL : order of sections: SA, SApt, SAxr, SAse, -->
<!--                   SAcs, SAsy, SAie, SAag, SAat, SAan     -->
<!-- 93-07-15 : DTL : rearrange sections, putting correspondence -->
<!--                  and synchronization sections right after -->
<!--                  segment section                         -->
<!--                  restate definition of alignment         -->
<!--                  further editing                         -->
<!-- 93-07-12 : DTL : clarification of global attributes and  -->
<!--                  tags defined in this chapter            -->
<!-- 93-07-09 : DTL : yet another title possibility: "Links,  -->
<!--                  Segments, Correspondences and Alignments" -->
<!--                  editorial cleanup; put discussion of    -->
<!--                  correspondence and alignment in same    -->
<!--                  section                                 -->
<!-- 93-07-08 : DTL : another title possibility: "Links,      -->
<!--                  Segments, Alignments and Correspondences" -->
<!-- 93-07-07 : DTL : change title to "Linkage, Segmentation, -->
<!--                  Alignment and Correspondence"           -->
<!--                  elaborate contents of chapter           -->
<!-- 93-02-10 : MSM : new id for dtdfrag dSA                  -->
<!-- 93-01-26 : MSM : add resp note                           -->
<!-- 93-01-26 : MSM : rename dtd file TEIsa2                  -->
<!-- 93-01-26 : MSM : add entrefs to subsections              -->
<!--                  correct entity decls in sample invocatn -->
<!-- 93-01-12 : MSM : stylistic changes for publication       -->
<!-- 92-12-23 : MSM : strip header                            -->
<!-- Date: Wed, 23 Dec 1992 14:19:10 +0000                    -->
<!-- From: Lou Burnard <lou@vax.ox.ac.uk>                     -->
<!-- To: U35395@UICVM.UIC.EDU                                 -->
<!-- Subject: sa.odd (1 of 9)                                 -->
<!-- 14 dec 92: LB started draft: defined link, linkGrp tags  -->

<div1 id="SA" n="14"><head>Linking, Segmentation, and Alignment</head>

<p>This chapter discusses a number of ways in which encoders may
represent analyses of the structure of a text which are not necessarily
linear or hierarchic.  In this chapter, tag sets and global attributes
are provided for the following common requirements:

<!-- <note place=foot>The primary responsibility for this     -->
<!-- chapter was borne by TEI work groups TR3 (hypertext and  -->
<!-- hypermedia) and AI (analysis and interpretation).  The   -->
<!-- text was drafted in part by Steven J. DeRose and in      -->
<!-- part by D. Terence Langendoen.</note>                    -->

<list type="bullets">

<item>to <emph>link</emph> disparate elements in a single document using
the <att>id</att> attribute (section <ptr target="SApt">);</item>

<item>to link disparate elements in a single document without using the
<att>id</att> attribute or to link elements in different documents
(section <ptr target="SAxr">);</item>

<item>to <emph>segment</emph> text into elements convenient for the
encoder and to mark arbitrary points within documents (section <ptr
target="SAse">);</item>

<item>to represent <term>correspondence</term> or <term>alignment</term>
among groups of text elements, both those with content and those which
are empty (section <ptr target="SAcs">);<note>We use the term alignment
as a special case of the more general notion of correspondence.  Let A
stand for an element with the attribute <att>id=A</att>, and suppose
elements A1, A2 and A3 occur in that order and form one group, while
elements B1, B2 and B3 occur in that order and form another group.  Then
a relation in which A1 corresponds to B1, A2 corresponds to B2 and A3
corresponds to B3 is an alignment.  On the other hand, a relation in
which A1 corresponds to B2, B1 to C2, and C1 to A2 is not an
alignment.</note></item>

<item>to <term rend="noindex">synchronize</term> elements of a text, that
is to represent temporal correspondences and alignments among text
elements (section <ptr target="SAsy">) and also to align them with
specific points in time (section <ptr target="SAsymp">);</item>

<item>to specify that one text element is <emph>identical</emph> to or a
<emph>copy</emph> of another (section <ptr target="SAie">);</item>

<item>to <emph>aggregate</emph> possibly noncontinguous elements
(section <ptr target="SAag">);</item>

<item>to specify that different elements are <emph>alternatives</emph>
to one another and to express <emph>preferences</emph> among the
alternatives (section <ptr target="SAat">);</item>

<item>to associate segments of a text with interpretations or analyses
of their significance (section <ptr target="SAan">).</item>

</list></p>

<p>These facilities all use the same basic set of techniques, which
depend on the ability to point to an element which has some form of
identifier.  The most convenient such identifier, and that which is
recommended by these Guidelines wherever possible, is provided by the
global <att>id</att> attribute, as defined in section <ptr
target="STga">.  An extension to this mechanism is provided, for elements
which are located in different SGML documents, or to which identifiers
cannot be attached (perhaps because they are held on read-only media),
known as the <term>TEI extended pointer mechanism</term> in section
<ptr target="SAxr">.  For many of the topics discussed in this chapter, a
choice of methods of encoding is offered, ranging from simple but less
general ones, which use attribute values only, to more elaborate and
more general ones, which use specialized elements.</p>

<p>The following DTD fragments show the overall organization of the
additional tag set discussed in the remainder of this chapter.  The file
<ident type="file">teilink2.ent</ident> begins by declaring a set of
additional attributes available globally when this tag set is enabled.
This is followed by declarations for the attribute classes <ident
type="class">pointer</ident> and <ident type="class">pointerGroup</ident> to
which most of the elements discussed in this chapter belong; these
attributes are all further described in the remainder of the chapter.

<eg id=dsaents>
<![ CDATA [
<!-- 14:  Global attributes for the TEI.linking tag
set      -->
<!-- Text Encoding Initiative: Guidelines for Electronic      -->
<!-- Text Encoding and Interchange. Document TEI P3, 1994.    -->

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

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

<!-- These materials subject to revision. Current versions    -->
<!-- are available from the Text Encoding Initiative.         -->
<!-- When tag set TEI.linking is used, the following          -->
<!-- attributes may be attached to any element:               -->


<!ENTITY % a.linking '
          copyOf             IDREF               #IMPLIED
          corresp            IDREFS              #IMPLIED
          sameAs             IDREF               #IMPLIED
          select             IDREFS              #IMPLIED
          synch              IDREFS              #IMPLIED
          next               IDREF               #IMPLIED
          exclude            IDREFS              #IMPLIED
          prev               IDREF               #IMPLIED'      >

<!-- The following attributes apply to all pointer
elements: -->

<!ENTITY % a.pointer '
          crdate             CDATA               #IMPLIED
          evaluate           (all | one | none)  #IMPLIED
          resp               CDATA               #IMPLIED
          targOrder          (Y | N | U)         U
          type               CDATA               #IMPLIED
          targType           NAMES               #IMPLIED'      >

<!-- The following attributes apply to all pointer group      -->
<!-- elements:                                                -->

<!ENTITY % a.pointerGroup '  %a.pointer;
          targFunc           NMTOKENS            #IMPLIED
          domains            IDREFS              #IMPLIED'      >
]]>
</eg>


<!-- These are the following:                                 -->
<!-- corresp  (SAcs)                                          -->
<!-- synch    (SAsy)                                          -->
<!-- sameAs   (SAie)                                          -->
<!-- copyOf   (SAie)                                          -->
<!-- next     (SAag)                                          -->
<!-- prev     (SAag)                                          -->
<!-- exclude  (SAat)                                          -->
<!-- select   (SAat)                                          --></p>

<p>The element declarations for this tag set are contained in the file
<ident type="file">teilink2.dtd</ident>:

<eg id=dsa>
<![ CDATA [
<!-- 14:  Linking, Segmentation and Alignment                 -->
<!-- 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.         -->

<!-- ... declarations from section 14.1.3                     -->
<!--     (Links)                                              -->
<!--     go here ...                                          -->
<!-- ... declarations from section 14.2.1                     -->
<!--     (Extended pointers)                                  -->
<!--     go here ...                                          -->
<!-- ... declarations from section 14.3                       -->
<!--     (Blocks, Segments and Anchors)                       -->
<!--     go here ...                                          -->
<!-- ... declarations from section 14.5.2                     -->
<!--     (Temporal specification)                             -->
<!--     go here ...                                          -->
<!-- ... declarations from section 14.7                       -->
<!--     (Aggregation)                                        -->
<!--     go here ...                                          -->
<!-- ... declarations from section 14.8                       -->
<!--     (Alternation)                                        -->
<!--     go here ...                                          -->
]]>
</eg>
</p>

<p>This tag set is made available by the mechanisms described in section
<ptr target="STin">; this implies that the document type subset for a
document using any of the tags or attributes described in this chapter
must define a parameter entity <ident type="pe">TEI.linking</ident> with
the value <code type="kw">INCLUDE</code>.  For example, a document using
this additional tag set and the prose base would begin with a series of
declarations like the following:

<eg><![ CDATA [
 <!DOCTYPE TEI.2 PUBLIC "-//TEI P3//DTD Main Document Type//EN"
                        "tei2.dtd" [
    <!ENTITY % TEI.prose   'INCLUDE'>
    <!ENTITY % TEI.linking 'INCLUDE' >
 ]>
]]>
</eg>
</p>
<!-- $Id: p2sapt.odd,v 1.10 1998/02/05 17:14:35 tei Exp $ -->
<!--*
    * $Log: p2sapt.odd,v $
    * Revision 1.10  1998/02/05 17:14:35  tei
    * make examples parse
    *
    * Revision 1.9  98/01/28  11:09:58  cmsmcq
    * LB changes of January 1998
    *
    * Revision 1.8  1994/04/08  18:54:36  msmcq
    * Last-second fixes for P3
    *
    * Revision 1.7  1994/03/27  21:47:19  msmcq
    * Correction of typos found by SJ, DB et al.
    *
    * Revision 1.6  1994/03/16  03:29:41  msmcq
    * Changes as per JL, with some LB and TL.
    *
    * Revision 1.5  1994/02/12  10:22:43  lou
    * reviions for P3
    *
    * Revision 1.3  1993/09/16  19:01:31  msmcq
    * Minor SGML cleanup, add RCS log keyword
    * -->
<!-- Revisions:                                               -->
<!-- 94-04-08 : MSM : linkGrp has no TYPE att, but inherits it from POINTER -->
<!-- 94-04-08 : MSM : change tagdesc and add adlist to show this\ -->
<!-- 94-04-08 : MSM : .                                       -->
<!-- 94-03-26 : MSM : typos from HG, DB, SJ                   -->
<!-- 94-03-26 : MSM : disambiguate TERM, Q (code, ident ...)  -->
<!-- 4 feb 94 : LB tidied up structure; reverted some changes -->
<!-- 20 dec 93: LB: changed grouper to ptrgroup -->
<!-- 93-09-15 : MSM : minor SGML cleanup                      -->
<!-- 93-07-21 : DTL : add discussion of < ptr> within < linkGrp> -->
<!--                   in SAptip (per Eynsham suggestion)     -->
<!--                  change argTypes= to targFunc=           -->
<!-- 93-07-16 : DTL : use the term "connected" rather than    -->
<!--                   "linked" to describe the result of     -->
<!--                   pointing, to avoid confusion between   -->
<!--                   two senses of "link" noted by LB       -->
<!--                  make other small corrections and changes -->
<!-- 93-07-12 : DTL : create grouper class, query editors on  -->
<!--                   a vexing question                      -->
<!-- 93-07-08 : DTL : describe < linkGrp> attributes, correct -->
<!--                   typo in first < linkGrp> example       -->
<!--                  add targOrder= to first < link> example -->
<!-- 93-07-07 : DTL : elaborate < linkGrp> definition         -->
<!--                  clarify distinction between "pointing"  -->
<!--                   and "pointer"; similarly between       -->
<!--                   "linking" and "link".                  -->
<!--                  make numerous other revisions           -->
<!--                  "Multi-headed" renamed "Intermediate",  -->
<!--                  rename section and make into a div3     -->
<!--                  modify tagging of Pope examples         -->
<!-- 93-01-26 : MSM : last chance revisions                   -->
<!-- 93-01-22 : MSM : once more lightly                       -->
<!-- 93-01-18 : MSM : rev more thoroughly                     -->
<!-- 93-01-12 : MSM : revise for publication                  -->
<!-- 92-12-23 : MSM : strip header                            -->
<!-- Date: Wed, 23 Dec 1992 14:25:19 +0000                    -->
<!-- From: Lou Burnard <lou@vax.ox.ac.uk>                     -->
<!-- To: U35395@UICVM.UIC.EDU                                 -->
<!-- Subject: sapt.odd (4 of 9)                               -->

<!-- 21 Dec 92: some changes in wording following comments from SR & MSM -->

<div2 id=SApt><head>Pointers</head>

<p>We say that one element <term rend=noindex>points</term> to others if
the first has an attribute whose value is a reference to the others:
such an element is called a <term>pointer element</term>, or simply a
<term>pointer</term>.  Among the pointers that have been introduced up
to this point in these Guidelines are <gi>note</gi>, <gi>ref</gi> and
<gi>ptr</gi>.  These elements all indicate an association between one
place in the document (the location of the pointer itself) and one or
more others (the elements whose identifiers are specified by the
pointer's <att>target</att> attribute).  This element set defines a
variation on this basic kind of pointer, known as a <term>link</term>
which specifies both <soCalled>ends</socalled> of an association.  In
addition, we define a syntax for representing locations in a document by
a variety of means not dependent on the use of SGML identifiers.

<div3 id=SAptl><head>Pointers and Links</head>

<p>In section <ptr target=COxr> we introduced the simplest pointer
elements, <gi>ptr</gi> and <gi>ref</gi>.  Here we introduce additionally
the <gi>link</gi> element, which represents an association between two
(or more) locations by specifying each location explicitly.  Its own
location is irrelevant to the intended linkage.

<list type=gloss>
<label><gi>ptr</gi></label>
<item>defines a pointer to another location in the current 
document
in terms of one or more identifiable elements.
Attributes include:
<list type=gloss>
<label><att>target</att></label>
<item>specifies the destination of the pointer as one or more 
SGML identifiers</item>
</list>
</item>
<label><gi>ref</gi></label>
<item>defines a reference to another location in the current 
document,
in terms of one or more identifiable elements, 
possibly modified by
additional text or comment.
Attributes include:
<list type=gloss>
<label><att>target</att></label>
<item>specifies the destination of the reference as one or more 
SGML identifiers</item>
</list>
</item>
<label><gi>link</gi></label>
<item>defines an association or hypertextual link
among elements 
or passages, of some type
not more precisely specifiable 
by other elements.
Attributes include:
<list type=gloss>
<label><att>targets</att></label>
<item>specifies the SGML identifiers of the elements or passages 
to be linked or associated.</item>
</list>
</item>
</list>


The <gi>ptr</gi> element may be called a <soCalled>pure
pointer</soCalled>, because its primary function is simply to point.  A
pointer sets up a <term rend=noindex>connection</term> between an
element (which, in the case of a pure pointer, can be thought of simply
as a location in a document), and one or more others, known collectively
as its <term>target</term>.

<!--Following para deleted by DTL but restored -->

The <gi>ptr</gi> and <gi>ref</gi> elements bear a <att>target</att>
attribute (in the singular), because they point, conceptually, at a
single target, even if that target may be discontinuous in the document.
The <gi>link</gi> element bears a <att>targets</att> attribute, with a
plural name, because it specifies at least two targets, each of which is
a unitary object.  It may be thought of as a representing a <term>double
link</term> between the objects specified.

<p>As members of the class <ident type=class>pointer</ident>, these
elements share a common set of attributes:

<list type=gloss>
<label><att>type</att></label>
<item>categorizes the pointer in some respect, using any 
convenient set of categories.</item>
<label><att>resp</att></label>
<item>specifies the creator of the pointer.</item>
<label><att>crdate</att></label>
<item>specifies when the pointer was created.</item>
<label><att>targType</att></label>
<item>specifies the kinds of elements to which this pointer may 
point.</item>
<label><att>targOrder</att></label>
<item>where more than one identifier is supplied as the value of 
the <att>target</att> attribute, this attribute specifies 
whether the order in which they are supplied is 
significant.
Legal values are:
<list type=gloss>
<label><term>U</term></label>
<item>Unspecified: the order in which IDREFs are specified as the 
value of a <att>target</att> attribute may or may not be 
significant.</item>
<label><term>Y</term></label>
<item>Yes: the order in which IDREFs are specified as the value 
of a <att>target</att> attribute should be followed when 
combining the targeted elements.</item>
<label><term>N</term></label>
<item>No: the order in which IDREFs are specified as the value of 
a <att>target</att> attribute has no significance when 
combining the targeted elements.</item>
</list></item>
<label><att>evaluate</att></label>
<item>specifies the intended meaning when the target of a pointer 
is itself a pointer.
Sample values include:
<list type=gloss>
<label><term>none</term></label>
<item>no further evaluation of targets is carried out beyond that 
needed to find the element specified in the pointer's 
target.</item>
<label><term>one</term></label>
<item>if the element pointed to is itself a pointer, then its 
target (whether a pointer or not) is taken as the target of 
this pointer.</item>
<label><term>all</term></label>
<item>if the element pointed to is itself a pointer, then the 
target of that pointer will be taken, and so on, until an 
element is found which is not a pointer.</item>
</list></item>
</list>

<!--      Currently the pointer class is:                     -->
<!--      ptr       (SApt)                                    -->
<!--      ref       (SApt)                                    -->
<!--      link      (SApt)                                    -->
<!--      xptr      (SAxr)                                    -->
<!--      xref      (SAxr)                                    -->
<!--      join      (SAag)                                    -->
<!--      alt       (SAat)                                    -->

<!-- added following clarification (LB) -->

<p>The <att>targType</att> and <att>targOrder</att> attributes may be
used to constrain the scope of a link to certain element types.  For
example:

<eg>
<![ CDATA [
<link type='echo' targets='P1 P2'>
]]>
</eg>

This is a complete unconstrained link, of type <code
type=value>echo</code>.  It assumes only that there is an element with
identifier <code type=value>P1</code> and another with identifier <code
type=value>P2</code> somewhere in the current document.

<eg>
<![ CDATA [
<link type='echo' targType='p seg note' targets='P1 P2'>
]]>
</eg>

This is a slightly more constrained link of the same type.  P1 and P2
must now both identify a <gi>p</gi>, a <gi>seg</gi>, or a <gi>note</gi>,
but there is no requirement as to which is which.  (This may be useful
if, as is often the case, different elements may participate in the same
kind of link.)

<eg>
<![ CDATA [
<link type='echo' targType='p note' targOrder=Y targets='P1 P2'>
]]>
</eg>

In this variation, not only must the link targets be either <gi>p</gi>
or <gi>note</gi> elements, but the one with identifier <code
type=value>P1</code> must be a <gi>p</gi>, and that with identifier
<code type=value>P2</code> must be a <gi>note</gi>.  Note that the
present Guidelines provide no direct way of saying that <code
type=value>P1</code> may identify either a <gi>seg</gi> or a <gi>p</gi>
and <code type=value>P2</code> must identify a <gi>note</gi>.

<p>These attributes are most useful if applied to a group of links, when
additional constraints may also be specified, as further discussed in
section <ptr target=SAptlg> below.

<!-- note from Terry deleted here -->

<p>Double connection among elements could also be expressed by a
combination of pointer elements, for example, two <gi>ptr</gi> elements,
or one <gi>ptr</gi> element and one <gi>note</gi> element.  All that is
required is that the value of the <att>target</att> (or other pointing)
attribute of the one be the value of the <att>id</att> attribute of the
other.  What the <gi>link</gi> element accomplishes is the handling of
double connection by means of a single element.  Thus, in the following
encoding:

<eg>
<![ CDATA [
  <ptr id=P1 target=P2> .....  <ptr id=P2 target=P1>
]]>
</eg>

P1 points to P2, and P2 points to P1.  This is logically equivalent to
the more compact encoding:

<eg>
<![ CDATA [
  <link targets='P1 P2'>
]]>
</eg>

<p>As noted above, all elements pointed to or linked by these elements
must be identifiable using the global <att>id</att> attribute.  This
implies that they must be present in the same document, and that they
must bear unique <att>id</att> values.  Pointing or linking to external
documents and pointing or linking where SGML identifiers are not
available is implemented by the external pointing mechanisms discussed
in section <ptr target=SAxr>, where the <gi>xptr</gi> and <gi>xref</gi>
elements are discussed.  External links and links involving elements
without identifiers do not require a special element; they may be
represented using the standard <gi>link</gi> element, but an
intermediate <gi>xptr</gi> element must be provided within the current
document, to bear the <att>id</att> attribute used in the target of the
link.

<div3 id=SApteg><head>Using Pointers and Links</head>

<p>As an example of the use of these mechanisms which establish
connections among elements, consider the practice (common in 18th
century English verse and elsewhere) of providing footnotes citing
parallel passages from classical authors.
<figure id='pope' rend='float fullpage'>
<figDesc>The figure shows the original page of Pope's
<title>Dunciad</title> which is discussed in the text.</figDesc>
</figure>
Such footnotes can of course simply be encoded using the <gi>note</gi>
element (see section <ptr target=COno>) without a <att>target</att>
attribute, placed adjacent to the passage to which the note refers:<note
place=foot>The <att>type</att> attribute on the note is used to classify
the notes using the typology established in the Advertisement to the
work:  <q>The <term rend=noindex>Imitations</term> of the Ancients are
added, to gratify those who either never read, or may have forgotten
them; together with some of the Parodies, and Allusions to the most
excellent of the Moderns.</q> In the source text, the text of the poem
shares the page with two sets of notes, one headed <q>Remarks</q> and
the other <q>Imitations</q>.</note>

<eg>
<![ CDATA [
<l>(Diff'rent our parties, but with equal grace</l>
<l>The Goddess smiles on Whig and Tory race,</l>
<note type='imitation' place=foot anchored=no>
    <bibl>Virg. &AElig;n. 10.</bibl>
    <quote><l>Tros Rutulusve fuat; nullo discrimine habebo.
    </l><l>&mdash;&mdash; Rex Jupiter omnibus idem.</l></quote>
</note>
<l>'Tis the same rope at sev'ral ends they twist,</l>
<l>To Dulness, Ridpath is as dear as Mist)</l>
]]>
</eg><!-- Pope, Dunciad (1729) III.284 -->

<p>This use of the <gi>note</gi> element can be called <term>implicit
pointing</term> (or <term>implicit linking</term>).  It relies on the
juxtaposition of the note to the text being commented on for the
connection to be understood.  If it is felt that the mere juxtaposition
of the note to the text does not make it sufficiently clear exactly what
text segment is being commented on (for example, is it the immediately
preceding line, or the immediately preceding two lines, or what?), or if
it is decided to place the note at some distance from the text, then the
pointing or the linking must be made explicit.  We now consider various
methods for doing that.

<p>First, a <gi>ptr</gi> element might be placed at an appropriate point
within the text to link it with the annotation:

<eg>
<![ CDATA [
<l>(Diff'rent our parties, but with equal grace</l>
<l>The Goddess smiles on Whig and Tory race,
<ptr rend='unmarked' target=N3.284></l>
<l>'Tis the same rope at sev'ral ends they twist,</l>
<l>To Dulness, Ridpath is as dear as Mist)</l>
<!-- elsewhere in the document ... -->
<note id=N3.284 type='imitation' place=foot anchored=no>
    <bibl>Virg. &AElig;n. 10.</bibl>
    <quote><l>Tros Rutulusve fuat; nullo discrimine habebo.
    </l><l>&mdash;&mdash; Rex Jupiter omnibus idem.</l></quote>
</note>
]]>
</eg><!-- Pope, Dunciad (1729) III.284 -->

The <gi>note</gi> element has been given an arbitrary identifier (<code
type=value>N3.284</code>) to enable it to be specified as the target of
the pointer element.  Because there is nothing in the text to signal the
existence of the annotation, the <att>rend</att> attribute has been
given the value <code type=value>unmarked</code>.

<!-- I don't understand the need for rend= here.  If there    -->
<!-- were a marker in the text, such as a footnote number     -->
<!-- or special sign, surely you wouldn't say, for example    -->
<!-- <ptr rend=dagger target=N3.284>. (DTL)                   -->
<!-- why ever not? LB -->

<p>Second, the <att>target</att> attribute of the <gi>note</gi> element
can be used to point at its associated text, provided that an
<att>id</att> attribute has been supplied for the associated text.
Since, in this case, the note itself contains a pointer to the place in
the text which it is annotating, this has also been encoded, using a
<gi>ref</gi> element, which bears a <att>target</att> attribute of its
own and contains a (slightly misquoted) extract from the text marked as
a <gi>quote</gi> element:

<eg>
<![ CDATA [
<!--  ... -->
<note target=L3.284
    type='imitation' place=foot anchored=no>
    <ref target='L3.284' rend='sc'>
    Verse 283-84.
    <quote><l>&mdash;&mdash;. With equal grace
        </l><l>Our Goddess smiles on Whig and Tory race.
     </l></quote></ref>
    <bibl>Virg. &AElig;n. 10.</bibl>
    <quote>
    <l>Tros Rutulusve fuat; nullo discrimine habebo.
    </l><l>&mdash;&mdash; Rex Jupiter omnibus idem.
    </l></quote>
</note>
]]>
</eg><!-- Pope, Dunciad (1729) III.284 -->

<!-- SJ asks what rend='sc' means.  no action taken (msm)     -->
<!-- material deleted -->
<!-- An SGML identifier has been given to each line, for      -->
<!-- convenience in transcribing other commentaries, even     -->
<!-- though in this example the note points only at line      -->
<!-- L3.284.                                                  -->
<!-- End material deleted -->

<p>Combining these two solutions gives us the following associations:

<list>
<item>a pointer within one line indicates the note
<item>the note indicates the line
<item>a pointer within the note indicates the line
</list>

Note that we do not have any way of pointing from the line itself to the
note:  the association is implied by containment of the pointer.  We do
not as yet have a true double link between text and note.

<!-- deleted DTL's third example -->

<p>Thirdly, therefore, we supply identifiers for both verse line and
annotation, and use a <gi>link</gi> element to associate the two.  Note
that the <gi>ptr</gi> element and the <att>target</att> attribute on the
<gi>note</gi> may now be dispensed with:

<eg>
<![ CDATA [
<l id=L3.283>(Diff'rent our parties, but with equal grace</l>
<l id=L3.284>The Goddess smiles on Whig and Tory race,</l>
<l id=L3.285>'Tis the same rope at sev'ral ends they twist,</l>
<l id=L3.286>To Dulness, Ridpath is as dear as Mist)</l>
<!-- elsewhere in the document ... -->
<note id=N3.284
    type='imitation' place=foot anchored=no>
    <ref target='L3.284' rend='sc'>
    Verse 283-84.
    <quote><l>&mdash;&mdash;. With equal grace
           </l><l>Our Goddess smiles on Whig and Tory race.
    </l></quote>]</ref>
    <bibl>Virg. &AElig;n. 10.</bibl>
    <quote><l>Tros Rutulusve fuat; nullo discrimine habebo.
    </l><l>&mdash;&mdash; Rex Jupiter omnibus idem.
    </l></quote>
</note>
<!-- ... and yet elsewhere in the document ... -->
<link targType='note l' targOrder=Y targets='N3.284 L3.284'>
]]>
</eg><!-- Pope, Dunciad (1729) III.284 -->

<p>The <att>targets</att> attribute of the <gi>link</gi> element here
bears the identifiers of the note followed by that of the verse line.
The <att>targType</att> and <att>targOrder</att> attributes may be used
to enable application programs to check that the identifiers in fact
pick out a <gi>note</gi> element and an <gi>l</gi> element and in that
order.  If <att>targOrder</att> has the value <code type=value>N</code>,
then the elements indicated by the <att>targets</att> attribute have to
be either <gi>note</gi> or <gi>l</gi> elements, but are otherwise
unconstrained.  If neither attribute is present, then the only
constraint is that the identifiers given must apply to some element
within the current document.

<p>For completeness, we could also allocate an identifier to the
reference within the note and encode the association between it and the
verse line in the same way:

<eg>
<![ CDATA [
<!-- ... -->
<note id=N3.284 type='imitation' place=foot anchored=no>
    <ref id=R3.284 rend='sc'>
    <!-- ... -->
    </ref>
</note>
<!-- ... -->
<link targType='ref  l' targOrder=Y targets='R3.284 L3.284'>
]]>
</eg><!-- Pope, Dunciad (1729) III.284 -->

Indeed, the two <gi>link</gi>s could be combined into one, as follows:

<eg><![ CDATA [
<link targType='note ref l' targOrder=Y
      targets='N3.284 R3.284 L3.284'>
]]>
</eg>

<div3 id=SAptlg><head>Groups of Links</head>

<!-- Material on <linkGrp> moved up from following section (DTL) -->
<!-- moved back! (LB) -->

<p>Clearly, there are many reasons for which an encoder might wish to
represent a link or association between different elements.  For some of
them, specific elements are provided in these Guidelines; some of these
are discussed elsewhere in the present chapter.  The <gi>link</gi>
element is a general purpose element which may be used for any kind of
association.  The element <gi>linkGrp</gi> may be used to group links of
a particular type together in a single part of the document; such a
collection may be used to represent what is sometimes referred to in the
literature of Hypertext as a <term>web</term>, a term introduced by the
Brown University FRESS project in 1969.

<list type=gloss>
<label><gi>linkGrp</gi></label>
<item>defines a collection of associations or hypertextual links.</item>
</list>


As a member of the class <ident type=class>pointerGroup</ident>, this
element shares the following attributes with other members of that
class:

<list type=gloss>
<label><att>domains</att></label>
<item>optionally specifies the identifiers of the elements within 
which all elements indicated by the contents of this 
element lie. <!-- designates the elements from which the 
values of the --> <!-- <att>targets</att> attribute of --> 
<!-- the enclosed <gi>link</gi>, <gi>join</gi> --> <!-- or 
<gi>alt</gi> tags are drawn. --></item>
<label><att>targFunc</att></label>
<item>describes the function of each of the values of the 
<att>targets</att> attribute of the enclosed <gi>link</gi>, 
<gi>join</gi> or <gi>alt</gi> tags.</item>
</list>

<!-- extendTarg"> killed by LB -->
<!--      linkGrp   (SApt)                                    -->
<!--      joinGrp   (SAag)                                    -->
<!--      altGrp    (SAat)                                    -->

It is also a member of the <ident type=class>pointer</ident> class, and
therefore also carries the attributes specified in section
<ptr target=SAptl> above, in particular the <att>type</att> attribute:

<list type=gloss>
<label><att>type</att></label>
<item>categorizes the pointer in some respect, using any 
convenient set of categories.</item>
</list>

<p>The <gi>linkGrp</gi> element provides a convenient way of
establishing a default for the <att>type</att> attribute on a group of
links of the same type:  by default, the <att>type</att> attribute on a
<gi>link</gi> element has the same value as that given for
<att>type</att> on the enclosing <gi>linkGrp</gi>.

<p>Typical software might hide a web entirely from the user, but use it
as a source of information about links, which are displayed
independently at their referenced locations.  Alternatively, software
might provide a direct view of the link collection, along with added
functions for manipulating the collection, as by filtering, sorting, and
so on.

<!-- <p>If many <tag>link</tag> tags are used, they may be    -->
<!-- grouped together within a <tag>linkGrp</tag>, and the    -->
<!-- attributes of that tag used to make precise how all the  -->
<!-- links are to be understood.                              -->

To continue our previous example, this text contains many other notes,
of a kind similar to the one shown above.  To avoid having to repeat the
<att>type=imitation</att> on each <gi>note</gi>, we may specify it once
for all on a <gi>linkGrp</gi> element containing all links of this type.
The <att>targType</att> and <att>targOrder</att> attributes can also be
specified for a <gi>linkGrp</gi> element:

<eg>
<![ CDATA [
<l id=L2.79>A place there is, betwixt earth, air and seas</l>
<l id=L2.80>Where from Ambrosia, Jove retires for ease.</l>
<l> ...
<l id=L2.88>Sign'd with that Ichor which from Gods distills.</l>
<l> ...
<l id=L3.283>(Diff'rent our parties, but with equal grace</l>
<l id=L3.284>The Goddess smiles on Whig and Tory race,</l>
<l id=L3.285>'Tis the same rope at sev'ral ends they twist,</l>
<l id=L3.286>To Dulness, Ridpath is as dear as Mist)</l>
<!-- ... -->
<!-- elsewhere in the document ... -->
<note id=N2.79 place=foot anchored=no><bibl>Ovid Met. 12.</bibl>
    <quote lang=la>
        <l>Orbe locus media est, inter terrasq; fretumq;
        </l><l>C&oelig;lestesq; plagas &mdash;
    </l></quote>
</note>
<note id=N2.88 place=foot anchored=no>
    Alludes to <bibl>Homer, Iliad 5</bibl>
<!-- .... -->
</note>
<!-- ... -->
<note id=N3.284 place=foot anchored=no><bibl>Virg. &AElig;n. 10.</bibl>
    <quote><l>Tros Rutulusve fuat; nullo discrimine habebo.
    </l><l>&mdash;&mdash; Rex Jupiter omnibus idem.
    </l></quote>
</note>
<!-- ... -->
<!-- yet elsewhere in the document ... -->
<linkGrp type='imitation' targType='note l' targOrder=Y>
  <link targets='N2.79 L2.79'>
  <link targets='N2.88 L2.88'>
  <!-- ... -->
  <link targets='N3.284 L3.284'>
  <!-- ... -->
</linkGrp>
]]>
</eg>

<p>Additional information for applications that use <gi>linkGrp</gi>
elements can be provided by means of special attributes.  First, the
<att>domains</att> attribute can be used to identify the text elements
within which the individual targets of the links are to be found.
Suppose that the text under discussion is organized into a <gi>body</gi>
element, containing the text of the poem, and a <gi>back</gi> element
containing the notes.  Then the <att>domains</att> attribute can have as
its value the identifiers of the <gi>body</gi> and the <gi>back</gi>, to
enable an application to verify that the link targets are in fact
contained by appropriate elements, or to limit its search space:

<eg>
<![ CDATA [
<body id=dunciad>
<!-- .... -->
<l id=L2.79>A place there is, betwixt earth, air and seas</l>
<l id=L2.80>Where from Ambrosia, Jove retires for ease.</l>
<l> ...
<l id=L2.88>Sign'd with that Ichor which from Gods distills.</l>
<l> ...
<l id=L3.283>(Diff'rent our parties, but with equal grace</l>
<l id=L3.284>The Goddess smiles on Whig and Tory race,</l>
<l id=L3.285>'Tis the same rope at sev'ral ends they twist,</l>
<l id=L3.286>To Dulness, Ridpath is as dear as Mist)</l>
<!-- ... -->
</body>
<back>
<div type="Notes" id=dunnotes><head>Notes to the Dunciad</head>
<!-- ... -->
<note id=N2.79 place=foot anchored=no><bibl>Ovid Met. 12.</bibl>
    <quote lang=la><l>
        Orbe locus media est, inter terrasq; fretumq;
        </l><l>C&oelig;lestesq; plagas &mdash;
    </l></quote>
</note>
<note id=N2.88 place=foot anchored=no>
    Alludes to <bibl>Homer, Iliad 5</bibl>
<!-- .... -->
</note>
<!-- ... -->
<note id=N3.284 place=foot anchored=no><bibl>Virg. &AElig;n. 10.</bibl>
    <quote><l>Tros Rutulusve fuat; nullo discrimine habebo.
    </l><l>&mdash;&mdash; Rex Jupiter omnibus idem.
    </l></quote>
</note>
<!-- ... -->
</back>
<!-- elsewhere in the document ... -->
<linkGrp type='imitation'
         domains='dunciad dunnotes'
         targType='note l'
         targOrder=Y>
  <link targets='N2.79 L2.79'>
  <link targets='N2.88 L2.88'>
  <!-- ... -->
  <link targets='N3.284 L3.284'>
  <!-- ... -->
</linkGrp>
]]>
</eg>

<p>Note that there must be a single parent element for each
<soCalled>domain</soCalled>; if some notes are contained by a section
with identifier <code type=value>dunnotes</code>, and others by a
section with identifier <code type=value>dunimits</code>, an
intermediate pointer must be provided (as described in section <ptr
target=SAptip>) within the <gi>linkGrp</gi> and its identifier used
instead.

<!-- and where does the linkGrp go itself? -->

<p>Next, the <att>targFunc</att> attribute can be used to provide
further information about the role or function of the various targets
specified for each link in the group.

<!-- type of link being used in that particular -->
<!-- gi>linkGrp</gi> tag beyond that which is provided by the -->
<!-- <att>type</att> and <att>targType</att> attributes.   -->

The value of the <att>targFunc</att> attribute is a list of names
(formally, SGML name tokens), one for each of the targets in the link;
these names can be chosen freely by the encoder, but their significance
should be documented in the encoding declaration in the header.<note>No
special element is provided for this purpose at present:  the
information should be supplied as a series of paragraphs at the end of
the <gi>encodingDesc</gi> element described in section <ptr
target=HD5>.</note>  In the current example, we might think of the note
as containing the <term rend=noindex>source</term> of the imitation and
the verse line as containing the <term rend=noindex>goal</term> of the
imitation.  Accordingly, we can specify the <gi>linkGrp</gi> in the
preceding example thus:

<eg><![ CDATA [
<linkGrp type='imitation'
         domains='dunciad dunnotes'
         targType='note l'
         targFunc='source goal'
         targOrder=Y>
  <link targets='N2.79 L2.79'>
  <link targets='N2.88 L2.88'>
  <!-- ... -->
  <link targets='N3.284 L3.284'>
  <!-- ... -->
</linkGrp>
]]>
</eg>

<!-- extendTarg attribute axed by LB pending further clarification -->


<!-- <p>Finally, the <att>extendTarg</att> attribute can be used -->
<!-- to combine links which share one or more target -->
<!-- identifiers.  Suppose that more than one different verse -->
<!-- line may imitate the same classical source as recorded in a -->
<!-- single note; in particular suppose that not only line L2.79, -->
<!-- but also lines 2.302 and L3.154 imitate the Ovid passage -->
<!-- quoted in note N2.79. -->

<!-- <note place=foot>For purposes of this illustration, -->
<!-- assume that the notes are not explicitly tied to the -->
<!-- verse lines in any way (in particular, that the notes do not -->
<!-- contain cross-references to the verse lines), as if the -->
<!-- author of the verse and the notes were challenging the -->
<!-- reader to discover the links between them.  The encoder in -->
<!-- this case may be considered to be recording the scholarship -->
<!-- of the critic NPR in figuring out the links between the text -->
<!-- and the notes.</note> -->

<!-- <p>These can be recorded as separate links, thus: -->

<!-- <eg><![ CDATA [ -->
<!-- <link resp=NPR targets='N2.79 L2.79'> -->
<!-- <link resp=NPR targets='N2.79 L2.302'> -->
<!-- <link resp=NPR targets='N2.79 L3.154'> -->
<!-- ]]> -->
<!-- </eg> -->

<!-- <p>Alternatively, if the <att>extendTarg</att> attribute is -->
<!-- given the value <term>2</term>, meaning that the second -->
<!-- target (consisting of pointers to verse lines) can be -->
<!-- <term>extended</term> with additional values, then the three -->
<!-- <gi>link</gi> tags can be combined into one: -->

<!-- <eg><![ CDATA [ -->
<!-- <linkGrp resp=NPR -->
<!--          type='imitation' -->
<!--          domains='dunciad dunnotes' -->
<!--          targType='note l' -->
<!--          targFunc='source goal' -->
<!--          targOrder=Y -->
<!--          extendTarg=2> -->
<!--   <link targets='N2.79 L2.79 L2.302 L3.154'> -->
<!--   <link targets='N2.88 L2.88'> -->
<!--    ... -->
<!--   <link targets='N3.284 L3.284'> -->
<!--    ... -->
<!-- </linkGrp> -->
<!-- ]]> -->
<!-- </eg> -->

<!-- <p>The default value of the <att>extendTarg</att> -->
<!-- attribute is 0, which means that the number of targets -->
<!-- in each <gi>link</gi> element should exactly match the number -->
<!-- of arguments in the <att>domains</att>, <att>targType</att> -->
<!-- and <att>targFunc</att> attributes (which should also all -->
<!-- match each other no matter what the value of the -->
<!-- <att>extendTarg</att> attribute is). -->

<p>The <gi>link</gi> and <gi>linkGrp</gi> elements are formally defined
as follows:

<eg id=dsapt>
<![ CDATA [
<!-- 14.1.3:  Links                                           -->
<!ELEMENT link          - o  EMPTY                              >
<!ATTLIST link               %a.global;
          crdate             CDATA               #IMPLIED
          evaluate           (all | one | none)  #IMPLIED
          resp               CDATA               #IMPLIED
          targOrder          (Y | N | U)         U
          targType           NAMES               #IMPLIED
          targets            IDREFS              #REQUIRED
          type               CDATA               %INHERITED;    >
<!ELEMENT linkGrp       - -  (link | ptr | xptr)+               >
<!ATTLIST linkGrp            %a.global;
                             %a.pointerGroup;                   >
<!-- This fragment is used in sec. 14                         -->
]]>
</eg>


<div3 id=SAptip><head>Intermediate Pointers</head>

<p>In the preceding examples, we have shown various ways of linking an
annotation and a single verse line.  However, the example cited in fact
requires us to encode an association between the note and a
<emph>pair</emph> of verse lines (lines 284 and 285).

<p>There are a number of possible ways of correcting this error:  one
could use the <att>target</att> and <att>targetEnd</att> attributes of
the <gi>note</gi> element to delimit the span to which the note applies
(see further section <ptr target=COno>).  Alternatively one could
create an element to encode the couplet itself and assign it an
<att>id</att> attribute, which can then be linked to the <gi>note</gi>
and <gi>ref</gi> elements.  This could be done either explicitly by
means of a <gi>lg</gi> element, as defined in section <ptr
target=COve>, or a <gi>seg</gi> element, as defined in section <ptr
target=SAse>, or implicitly, by means of the <gi>join</gi> element
discussed in section <ptr target=SAag>.

<p>A third possibility however, is to use an <soCalled>intermediate
pointer</soCalled> as follows:

<eg>
<![ CDATA [
<l id=L3.283>(Diff'rent our parties, but with equal grace</l>
<l id=L3.284>The Goddess smiles on Whig and Tory race,</l>
<!-- ... -->
<ptr id=L3.283284 target='L3.283 L3.284' targOrder=Y >
]]>
</eg>

<!-- sentence deleted by Terry but restored by LB -->

When the <att>target</att> attribute of a <gi>ptr</gi> or <gi>ref</gi>
element specifies more than one element, the indicated elements are
always understood to be combined or aggregated in some way to produce
the object of the pointer.

<p>In this example, the <att>targOrder</att> attribute should be
specified to indicate that the order in which identifier values are
supplied in the <att>target</att> attribute is significant.  The
<att>id</att> attribute provides an identifier which can then be linked
to the <gi>note</gi> and <gi>ref</gi> elements:

<eg>
<![ CDATA [
<link targets='N3.284 R3.284 L3.283284'
      targType='note ref ptr' evaluate=all>
]]>
</eg><!-- Pope, Dunciad (1729) III.284 -->

<p>The <att>evaluate=all</att> attribute value is used on the
<gi>link</gi> element to specify that any pointer encountered as a
target of that element is itself evaluated.  If <att>evaluate</att> had
the value <code type=value>none</code>, the link target would be the
pointer itself, rather than the objects it points to.

<p>Where a <gi>linkGrp</gi> element is used to group a collection of
<gi>link</gi> elements, any intermediate pointer elements used by those
<gi>link</gi> elements should be included within the <gi>linkGrp</gi>.

<p>Intermediate pointers of this kind are particularly important when
extended pointers (discussed in the next section) are in use.

<!-- material deleted by Terry and not yet restored -->
<!-- <p>This use of<soCalled>multi-headed< /soCalled>      -->
<!-- pointing should be carefully distinguished from that     -->
<!-- used by the<att>targets< /att> attribute of the<     -->
<!-- gi>link< /gi> element.  As the attribute name            -->
<!-- suggests, in the latter case, the indicated elements     -->
<!-- are not simply combined together as if they were a       -->
<!-- single target, but associated in some respect,           -->
<!-- specifically, that indicated by the<att>type< /att>    -->
<!-- attribute.  Crucially, the intended relationship         -->
<!-- between every item in a list of identifiers must be      -->
<!-- identical.  To represent the link discussed above as     -->
<!-- follows would be erroneous:                              -->

<!-- <eg >                                                   -->
<!-- <![ CDATA [                                             -->
<!-- <link type=imitation targets='N3.284 L3.283 L3.284' >   -->
<!-- ]] >                                                     -->
<!-- </eg >                                                  -->

<!-- This is not correct, because the association between     -->
<!-- N3.284 and L3.284 (the note and one line of text) is     -->
<!-- not of the same kind as that between L3.283 and L3.284   -->
<!-- (the two lines of text).  A processor cannot be          -->
<!-- expected to process this kind of target list             -->
<!-- correctly.  To represent the link correctly, an          -->
<!-- intermediate pointer or a virtual element must be        -->
<!-- introduced as discussed above.                           -->
<!-- End material deleted -->


<!-- $Id: p2saxr.odd,v 1.8 1998/02/05 17:14:35 tei Exp $ -->
<!--*
    **
    * $Log: p2saxr.odd,v $
    * Revision 1.8  1998/02/05 17:14:35  tei
    * make examples parse
    *
    * Revision 1.7  98/02/01  16:52:05  tei
    * change system identifiers to public identifiers
    * fix log keyword
    * normalize SGML
    *
    * Revision 1.6  98/01/28  11:09:58  cmsmcq
    * LB changes of January 1998
    *
    * Revision 1.5  1994/04/08  18:54:36  msmcq
    * Last-second fixes for P3
    *
    * Revision 1.4  1994/03/27  21:47:19  msmcq
    * Correction of typos found by SJ, DB et al.
    *
    * Revision 1.3  1994/03/16  03:29:41  msmcq
    * Changes as per JL, with some LB and TL.
    * -->
<!-- Latex Probs in this file:
  <q>#CDATA</q>
-->
<!-- Revisions:                                               -->
<!-- 18 jan 98 : LB : fix xref error from Greg Murphy -->
<!-- 7 jan 98 : LB : fix typos (circ in cdata) from MSM -->
<!-- 94-04-08 : MSM : fix a ms close problem?                 -->
<!-- 94-04-08 : MSM : change tagdesc for xref, xptr           -->
<!-- 94-04-08 : MSM : discuss doc, from, to as inherited from xpointer -->
<!-- 94-04-08 : MSM : (not local)                             -->
<!-- 94-03-27 : MSM : remove terminal semicolon from bnf (DB) -->
<!-- 94-03-26 : MSM : typos from HG, DB, SJ                   -->
<!-- 94-03-26 : MSM : disambiguate TERM, Q (into code, ident, -->
<!--                  etc.  Location term keywords are tagged -->
<!--                  as CODE TYPE=TEIKW, nonterminals of the -->
<!--                  grammar as IDENT TYPE=NONTERM           -->
<!-- 94-03-15 : MSM : change ID for FOLLOWING section (dup)   -->
<!-- 94-03-15 : MSM : supply TYPE on all IDENT elems          -->
<!-- 94-03-15 : CMSMcQ : require value for each att in a step -->
<!-- 12 Mar 94 : CMSMcQ : make John Lavagnino's suggested     -->
<!--                      changes, for canonical refs         -->
<!-- 3 feb 94: LB check for funny chars, minor revision of  structure -->
<!-- 93-06-05 : MSM : suppress dot in col 1                   -->
<!-- 93-01-26 : MSM : make adList point to Pointer not Loc    -->
<!-- 93-01-26 : MSM : changes for publication                 -->
<!-- 93-01-21 : MSM : revise thoroughly, add bnf, exx         -->
<!-- 92-12-23 : MSM : strip header                            -->
<!-- Date: Wed, 23 Dec 1992 14:25:57 +0000                    -->
<!-- From: Lou Burnard <lou@vax.ox.ac.uk>                     -->
<!-- To: U35395@UICVM.UIC.EDU                                 -->
<!-- Subject: saxr.odd (5 of 9)                               -->

<div2 id="SAxr"><head>Extended Pointers</head>

<p>Where the object of a link or pointer element is not contained within
the current document, or where it does not bear an <att>id</att>
attribute, it is not possible to point at it with a <gi>ptr</gi> or
<gi>ref</gi> element, nor to link it directly with a <gi>link</gi>
element, because no IDREF value can be supplied for the
<att>target</att> or <att>targets</att> attribute of these elements.  In
such cases, the encoder must indicate the intended element indirectly by
means of the elements discussed in this section.  These elements
identify their target using a special TEI-defined extended pointer
notation, defined in section <ptr target="SAxrs"> below and designed for
compatibility with HyTime.
<note>HyTime is an international standard (ISO 10744) built on SGML.
It provides facilities for representing both static and dynamic
information for processing and interchange by hypertext and multimedia
applications.  See <bibl><title> ISO/IEC 10744 Information
Technology --- Hypermedia/Time-based Structuring Language
(HyTime)</title>
([Geneva]:  International Organization for Standardization,
1992)</bibl>.</note>
<!-- For discussion of the relation between TEI proposals  -->
<!-- and Hytime, see chapter <ptr target=OS>. -->
<!-- ... but not till it gets written ... --></p>

<div3 id="SAxr1"><head>Extended Pointer Elements</head>

<p>To point or refer to locations in the current or some other document
<emph>without</emph> requiring that the target bear an SGML identifier,
the following elements should be used:

<list type=gloss>
<label><gi>xptr</gi></label>
<item>defines a pointer to another location in the current 
document
or an external document.</item>
<label><gi>xref</gi></label>
<item>defines a reference to another location in the current 
document,
or an external document, using an extended 
pointer notation,
possibly modified by additional text or 
comment.</item>
</list>


These elements are both members of the element class
<ident type="class">pointer</ident>, and therefore carry the same
attributes as other members of that class, listed above (see section
<ptr target="SAptl">).

<!-- adList classDoc=pointer
        atts="type resp crdate targType targOrder evaluate" -->

<!-- do targType and targOrder make much sense here? -->

They are also members of the class <ident type="class">xPointer</ident>,
from which they inherit the following attributes:

<list type=gloss>
<label><att>doc</att></label>
<item>specifies the document within which the desired location is 
to be found.</item>
<label><att>from</att></label>
<item>specifies the start of the destination of the pointer, as 
an expression in the TEI extended-pointer notation 
described in section <ptr target=SAxr>.</item>
<label><att>to</att></label>
<item>specifies the endpoint of the destination of the pointer, 
as an expression in the TEI extended pointer notation.</item>
</list>
</p>

<p>Unlike the pointer elements discussed in the previous section, these
elements do not specify their target by means of a <att>target</att>
attribute.  Instead these elements use one or both of the attributes
<att>from</att> and <att>to</att> to delimit a portion of some document
specified by the <att>doc</att> attribute.  In all other respects, these
elements correspond with the elements <gi>ptr</gi> and <gi>ref</gi>
discussed in sections <ptr target="COxr">, and <ptr target="SApt">.  Note
that there is no element <gi tei="no">xlink</gi> corresponding with the
<gi>link</gi> element; links can be made both within and between
documents using the same syntax, as further discussed below.</p>

<p>The values of the <att>from</att> and <att>to</att> attributes on the
<gi>xptr</gi> and <gi>xref</gi> elements indicate the point or passage
being referred to by showing how to locate it, using one or more special
keywords, as defined below in section <ptr target="SAxrs">.  Examples are
given there.</p>

<p>The <gi>xptr</gi> and <gi>xref</gi> elements are formally defined as
follows:

<eg id=dsaxr>
<![ CDATA [
<!-- 14.2.1:  Extended pointers                               -->
<!ELEMENT xref          - O  (%paraContent)                     >
<!ATTLIST xref               %a.global;
                             %a.xPointer;                       >
<!ELEMENT xptr          - O  EMPTY                              >
<!ATTLIST xptr               %a.global;
                             %a.xPointer;                       >
<!-- This fragment is used in sec. 14                         -->
]]>
</eg>
</p></div3>

<div3 id="SAxrs"><head>Extended Pointer Syntax</head>

<p>As noted above, the elements <gi>xptr</gi> and <gi>xref</gi> are used
to represent a link between their own location (the <socalled>link
origin</socalled>) and some other location (the
<socalled>destination</socalled>), which may or may not be in the same
document.  Software supporting intra- and inter-document links (e.g.
hypertext systems) should provide access from the location of such an
element to the destination.</p>

<p>This section defines the allowable values for the attributes
<att>from</att>, <att>to</att>, and <att>doc</att> of the <gi>xptr</gi>
and <gi>xref</gi> elements.</p>

<p>An <gi>xptr</gi> or <gi>xref</gi> element with <emph>no</emph>
attributes at all is, by definition, a link to the root (i.e. the
<term rend="noindex">document element</term> --- by default, this is the
<gi>TEI.2</gi> element) of the document in which it appears.</p>

<p>The <att>doc</att> attribute value must be the name of an entity
declared in the SGML document type declaration.  If only the
<att>doc</att> attribute is given a value, then by definition the
destination is the entire entity named by the <att>doc</att> value.  A
more specific location within another entity must be specified with the
<att>from</att> and the <att>to</att> attributes, as described below.

<!-- Removed requirement that FROM and TO both have values.   -->
<!-- Maybe wrongly.  -msm                                     --></p>

<p>The <att>from</att> and the <att>to</att> attributes indicate the
specific location pointed at, within the entity named by the
<att>doc</att> attribute (or within the current document, if no
<att>doc</att> value is given).  Their values are referred to below as
<term>location pointer specification</term>s.  When both attributes are
specified, the span pointed at by the element runs from the starting
point of the span indicated by <att>from</att> to the ending point of
the string specified by <att>to</att>.  If the latter precedes the
former in the document, then the pointer is in error and fails.  If only
the <att>from</att> attribute is specified, the <att>to</att> attribute
defaults to the same value; the effect is that the element as a whole
points to the span indicated by the <att>from</att> attribute.  It is a
semantic error to specify a value for <att>to</att> but not for
<att>from</att>.</p>

<div4 id="SAxr11"><head>Location Ladders</head>

<p>Each location pointer specification consists of a sequence of
<term>location term</term>s, each of which consists of a keyword
specifying a <term>location type</term> followed by one or more
parenthesized parameter lists, each of which specifies a <term>location
value</term> via a list of parameters.  Location types and values, and
the parameters within a location value, must be separated by white space
characters.</p>

<p>Using terms borrowed from <term>HyTime</term>, we say that each TEI
location term in a specification provides the <term>location
source</term> for the next, and the entire specification is equivalent
to a <term>location ladder</term>.  By specifying the entire ladder in a
single attribute value, the TEI extended pointer mechanism greatly
reduces the syntactic and processing complexity of hypertextual
pointers.</p>

<p>In formal terms:<note place="foot">
<!-- The formal grammar specified in this section is          -->
<!-- reproduced as a unit in the appendix.                    -->
The notation used for this formal grammar is that defined in chapter
<ptr target="GR">.</note>

<eg rend=syntax>
<![ CDATA [
ladder   ::=  locterm
         |    ladder locterm
]]>
</eg></p></div4>

<div4 id="SAxr12"><head>Location Terms</head>

<p>The keywords used in location terms are these; references to <q>the
tree</q> mean the tree representing the SGML document hierarchy.

<list type="gloss">

<label>root</label>

<item>points at the root of the target document</item>

<label>here</label>

<item>points at the location of the pointer</item>

<label>id</label>

<item>points at an ID within the target document</item>

<label>ref</label>

<item>gives a <socalled>canonical reference</socalled> to a location in
the target document</item>

<label>child</label>

<item>indicates an element found by descending one level in the tree</item>

<label>descendant</label>

<item>indicates an element found by descending one or more levels in the
tree</item>

<label>ancestor</label>

<item>indicates an element found by ascending one or more levels in the
tree</item>

<label>previous</label>

<item>indicates an element found by traversing the older siblings of the
current location source</item>

<label>next</label>

<item>indicates an element found by traversing the younger siblings of
the current location source</item>

<label>preceding</label>

<item>indicates an element found by traversing the entire portion of the
document preceding the current location source</item>

<label>following</label>

<item>indicates an element found by traversing the entire portion of the
document which follows the current location source</item>

<label>pattern</label>

<item>specifies a regular expression to be located within the existing
location source</item>

<label>token</label>

<item>points at one or more <term rend="noindex">tokens</term> in the
character content of the location source</item>

<label>str</label>

<item>points at one or more characters in the character content of the
location source</item>

<label>space</label>

<item>points at a location using coordinates in some
(application-defined) n-dimensional space</item>

<label>foreign</label>

<item>points at a location using some non-SGML method, and gives the
name of the method</item>

<label>HyQ</label>

<item>points at a location using the HyQ query language defined by ISO
10744 (HyTime)</item>

<label>ditto</label>

<item>(in the <att>to</att> attribute only) points at the same span as
was indicated by the <att>from</att> attribute</item>

</list></p>

<p>In formal terms:

<eg rend=syntax> <![ CDATA [
locterm ::=   'ROOT'                        // default first location
         |    'HERE'                        // location of the xptr
         |    'ID' '(' NAME ')'             // only one ID allowed.
         |    'REF' '(' characters ')'      // only one ref allowed
         |    'CHILD' steps
         |    'DESCENDANT' steps
         |    'ANCESTOR' steps
         |    'PREVIOUS' steps
         |    'NEXT' steps
         |    'PRECEDING' steps
         |    'FOLLOWING' steps
         |    'PATTERN' regs                // mult patterns allowed
         |    'TOKEN' '(' range ')'
         |    'STR' '(' range ')'
         |    'SPACE' '(' NAME ')' pointpair
         |    'FOREIGN' parms
         |    'HYQ' parms
         |    'DITTO'                       // valid only in TO att.
]]>
</eg>

Note that the keywords, though shown here quoted in uppercase, are not
case sensitive.</p>

<p>Each location term specifies a location in the target document; this
location may be a single point, more often a span of text (often the
span of a single element) within the target document.  The location
ladder as a whole is interpreted from left to right, and each location
term specifies a location relative to the location specified by the
sequence prior to that point (i.e. to its location source).  Unless
<code type="teikw">here</code> or <code type="teikw">id</code> is specified
as the first location term, the beginning location source is always
<code type="teikw">root</code>.  An empty location sequence thus is the
same as <code type="teikw">root</code> and specifies the entire
destination entity.</p>

<p>In general, the search for the location specified by a location term
will be conducted only within its location source (i.e. within the
location already identified by preceding location terms).  There are
however several exceptions.  The terms <code type="teikw">root</code>,
<code type="teikw">here</code>, and <code type="teikw">id</code> all ignore
the location source defined by any preceding terms and therefore make
sense only as the first items in the ladder.  The terms <code
type="teikw">ancestor</code>, <code type="teikw">next</code>, and <code
type="teikw">previous</code> do not ignore the location source, but select
a new span from the adjacent or enclosing portions of the text, and not
from within the location source.  Finally the location terms <code
type="teikw">foreign</code>, <code type="teikw">space</code>, and <code
type="teikw">HyQ</code> are not defined fully here; they may or may not
ignore the existing location source.</p>

<p>Some of the location terms make sense only in SGML documents; these
are <code type="teikw">id</code>, <code type="teikw">child</code>, <code
type="teikw">ancestor</code>, <code type="teikw">descendant</code>, <code
type="teikw">previous</code>, <code type="teikw">next</code>, <code
type="teikw">preceding</code>, and <code type="teikw">following</code>.  The
latter six involve traversing the tree representing the SGML document
hierarchy and are most easily understood when their location source is a
single SGML element.  If the location source is not a single SGML
element, the tree-traversal keywords operate upon its beginning
end-point, its <socalled>front end</socalled> (in English, this will be
the leftmost point of the location source; in Arabic or Hebrew it will
be the rightmost point).  In this case <code type="teikw">child</code> and
<code type="teikw">descendant</code> have no meaning, since character data
has no descendants in the document tree; the first <code type="teikw">ancestor</code> of such a location source is the element
immediately containing the character data in question, and the siblings
referred to by <code type="teikw">next</code> and <code type="teikw">previous</code> are the other children of that immediately
containing element.</p>

<p>The details of each keyword are given below, along with definitions
of their syntax and semantics of their results.  Examples are also
provided.  It is strongly recommended that when IDs are available, they
should be used in preference to the other methods for pointing defined
here.</p>

<p>For all keywords, the description assumes that the target document
does in fact contain a span or element which matches the description;
otherwise, the location term has no referent and is said to
<socalled>fail</socalled>.  If any location term fails, the entire
pointer fails.  No backtracking or retrying is performed (and indeed for
the most part the location terms are defined as having only one matching
location, so backtracking would in most cases lead to no better result).</p></div4>

<div4 id="SAxr1ro"><head>The ROOT Keyword</head>

<p>The location term <code type="teikw">root</code> selects the root of
the destination document tree; in SGML terms, this is the
<socalled>document element</socalled>.  Since it ignores any existing
location source, the <code type="teikw">root</code> keyword makes sense
only as the first location term in the ladder.  Since <code
type="teikw">root</code> is assumed as the implicit first term in any
ladder, the following two location ladders have the same meaning:

<eg rend=syntax> <![ CDATA [
ROOT DESCENDANT (2 DIV1)
]]>
</eg>
<eg rend=syntax> <![ CDATA [
DESCENDANT (2 DIV1)
]]>
</eg>
<div4 id=SAxr1he><head>The HERE Keyword</head>

<p>The keyword <code type=teikw>here</code> designates the location at
which the pointer element itself is situated; it allows extended
pointers to select items like <q>the paragraph immediately preceding the
one within which this pointer occurs</q>.  Since it ignores any existing
location source, this keyword typically makes sense only as the first
location term in a location specification.

<p>To designate <q>the paragraph preceding the current one</q>, the
following location ladder could be used:

<eg rend=syntax>HERE ANCESTOR (1 P) PREVIOUS (1 P)</eg>

(See below for descriptions of the keywords <code
type=teikw>ancestor</code> and <code type=teikw>previous</code>.)

<div4 id=SAxr1id><head>The ID Keyword</head>

<p>The resulting location is the element within the destination entity
whose ID attribute has the value specified as the location value.  The
ID location type typically makes sense only as the <emph>first</emph>
location pair in a location specification, but there is no syntactic
requirement that it be so.

<p>For example, the location specification

<eg rend=syntax>ID (a27)</eg>

chooses the necessarily unique element of the destination entity which
has an attribute of declared value of type ID, whose value is <code
type=value>a27</code>.

<div4 id=SAxr1re><head>The REF Keyword</head>

<p>The resulting location is an element which can be found by
interpreting the location value in accordance with document-specific
rules for a <term>canonical reference.</term> Such reference systems,
particularly common in documents of interest to classical and biblical
scholars, must also be defined in the TEI header, using the
<gi>refsDecl</gi> element (see section <ptr target=HD54>).  If more
than one element matches the canonical reference, the first one
encountered is chosen.

<!-- If blanks or any other non-name characters are required  -->
<!-- within location values, the values must be quoted; use   -->
<!-- of blanks in canonical references is not TEI             -->
<!-- recommended practice.                                    -->
<!-- value is already enclosed in (), quotes unneeded. -msm   -->

<p>For example, the location specification

<eg rend=syntax>REF (MT.2.1)</eg>

chooses the first element of the destination entity which is identified
by the canonical reference <mentioned>MT.2.1</mentioned>

<div4 id=SAxr1ch><head>The CHILD Keyword</head>

<p>The <code type=teikw>child</code> location type specifies an element
or span of character data in the document hierarchy using a location
value which functions as a <term rend=noindex>domain-style</term>
address.  The value is a series of parenthesized steps, separated by
white space.  Each such step represents one level of the hierarchy
within the location source.  Each step may contain one or more
parameters separated by white space and interpreted in order as follows:

<list type=ordered>
<item>an instance indicator, which is a signed or unsigned integer or
the special value <code type=kw>ALL</code>
<item>optionally, an expression matching an SGML generic identifier
<item>optionally, one or more pairs of expressions, the first matching
an SGML attribute name and the second matching an SGML attribute value
</list>

<p>In formal terms, the location value of <code type=teikw>child</code>
is a series of <ident type=nonterm>steps</ident>:

<eg rend=syntax>
<![ CDATA [
steps    ::=  '(' step ')'
         |    steps '(' step ')'

step     ::=  instance
         |    instance element
         |    instance element avspecs

avspecs  ::=  attribute value
         |    avspecs attribute value

]]>
</eg>

<!-- alternative grammar, to make last attval optional        -->
<!-- avspecs  ::=  attribute                                  -->
<!--          |    attribute value                            -->
<!--          |    attribute value avspecs                    -->
<!--          ;                                               --></p>

<p>Location values of the same form are also used by the keywords
<code type="teikw">descendant</code>, <code type="teikw">ancestor</code>, <code
type="teikw">previous</code>, and <code type="teikw">next</code>; details of
the interpretation may vary from keyword to keyword.</p>

<p>If an instance indicator alone is specified, as a number <ident
type="variable">n</ident>, it selects the <ident type="variable">n</ident>th child of the location source.  If the
special value <code type="kw">ALL</code> is given, then <emph>all</emph>
the children of the location source are selected.  If the instance
indicator is specified with following parameters, it selects all, or the
<ident type="variable">n</ident>th, among those children of the location
source which satisfy the other parameters.  If a negative number is
given, the <ident type="variable">n</ident>th child is counted from the
last child of the location source to the first.  The location source
must contain at least <ident type="variable">n</ident> children;<note
place="foot">Strictly speaking, |n| (absolute value of n) children.</note>
if it does not, the <code type="teikw">child</code> term fails.</p>

<p>In formal terms, the first parameter of a <ident type="nonterm">step</ident> is an instance indicator, which in turn is
either the special value <code type="kw">ALL</code> or a signed integer:

<eg rend=syntax>
<![ CDATA [
instance ::=  'ALL'
         |    signed

signed   ::=  NUMBER                        // default sign is +
         |    '+' NUMBER
         |    '-' NUMBER

]]>
</eg></p>

<p>If a second parameter is given, it is interpreted as an SGML generic
identifier, and only elements of the type indicated will be selected.
For example, the location specification

<eg rend=syntax>CHILD (3 DIV1) (4 DIV2) (29 P)</eg>

chooses the 29th paragraph of the fourth sub-division of the third major
division of the initial location source.  The location specification

<eg rend=syntax>CHILD (3 DIV1) (4 DIV2) (-2 P)</eg>

chooses the next-to-last paragraph of the fourth <gi>div2</gi> of the
third <gi>div1</gi> in the location source.</p>

<p>Constraint by generic identifier is strongly recommended, because it
makes links more perspicuous and more robust.  It is perspicuous because
humans typically refer to things by type:  as <q>the second section</q>,
<q>the third paragraph</q>, etc.  It is robust because it increases the
chance of detecting breakage if (due to document editing) the target
originally pointed at no longer exists.</p>

<p>The generic identifier may be specified as a normal SGML name, as a
(parenthesized) regular expression, or using the reserved values <code
type="kw">#CDATA</code> or <code type="kw">*</code>.  Regular expressions
take the form described below; the location term

<eg rend=syntax>CHILD (3 (DIV[123])</eg>

matches the third element which has a generic identifier of <code
type="value">div1</code>, <code type="value">div2</code>, or <code
type="value">div3</code>.  If the generic identifier is specified as
<code type="value">*</code>, any generic identifier is matched; this means that
<q>CHILD (2 *)</q> is synonymous with <code type="frag">CHILD (2)</code>.
If the second parameter is <code type="frag">#CDATA</code>, the location
term selects only untagged sub-portions of an element having SGML mixed
content.</p>

<p>The location ladder

<eg rend=syntax>CHILD (3 #CDATA)</eg>

thus chooses the third span of character data directly contained by the
current location source.  If the location source is a paragraph
containing

<list type="ordered">
<item>a sentence (A)</item>
<item>an embedded quotation, marked as a <gi>q</gi></item>
<item>another sentence (B)</item>
<item>an embedded note, marked as a <gi>note</gi></item>
<item>another sentence (C)</item>
<item>a second embedded quotation, marked as a <gi>q</gi></item>
</list>

where the three sentences A, B, and C are character data enclosed by no
element smaller than the paragraph itself, then <code type="frag">CHILD (3
#CDATA)</code> selects sentence C, while <code type="frag">CHILD
(3)</code> selects sentence B.</p>

<p>If specified as a name (i.e. without parentheses), the generic
identifier is case sensitive if and only if the SGML declaration
specifies that generic identifiers are case sensitive (by default they
are not).  If specified as a regular expression, the expression given is
always case sensitive; in the usual case this means the regular
expression should be in uppercase, as in the examples here.</p>

<p>In formal terms the second parameter of a <ident type="nonterm">step</ident> is defined thus:

<!-- <note place=foot>If regular expressions need not be      -->
<!-- parenthesized, then this grammar and the accompanying    -->
<!-- text must be changed.  Remove this note before           -->
<!-- publication.-MSM</note>                                  -->

<eg rend=syntax>
<![ CDATA [
element  ::=  NAME
         |    '#CDATA'
         |    '*'
         |    '(' regular ')'
]]>
</eg>

<!-- Am uncertain about definition of 'bear' in next para.    -->
<!-- Alternate:  just include test (a).  This allows us to    -->
<!-- skirt, slightly longer, the open question:  for atts     -->
<!-- like LANG, with well defined TEI rules for implied       -->
<!-- values, is the application supposed to have supplied     -->
<!-- them before the search is made or not?  -msm             -->
<!-- I prefer the alternate myself.  And have edited          -->
<!-- accordingly.  LB                                         -->

<!-- <p>If a third parameter is specified, it is interpreted  -->
<!-- as an attribute name, and only elements bearing that     -->
<!-- attribute for which that attribute is defined and which  -->
<!-- satisfy the other constraints will be selected.  An      -->
<!-- element is held to <q>bear</q> an attribute if (a) the   -->
<!-- attribute is defined for that element type and (b) the   -->
<!-- value of the attribute is not <q>IMPLIED</q>.  Like the  -->
<!-- preceding, this parameter may be specified as <q>*</q>   -->
<!-- in the (unlikely) event that an attribute value          -->
<!-- constitutes a constraint regardless of what attribute    -->
<!-- name it is a value for.  The parameter may also be       -->
<!-- specified as a parenthesized regular expression.         --></p>

<p>The third and fourth parameters, if given, are interpreted as an
attribute-value pair, and only elements which match that pair in the way
described below will be selected; the fourth and fifth parameters, and
all following pairs of parameters, are interpreted in the same way.
When more than one pair is given, all must be matched.</p>

<p>The third, fifth, seventh, etc., parameters are interpreted, if
specified, as attribute names.  Like generic identifiers, attribute
names may be specified as <code type="value">*</code> in location ladders
in the (unlikely) event that an attribute value constitutes a constraint
regardless of what attribute name it is a value for.  The attribute name
parameter may also be specified as a parenthesized regular expression.</p>

<p>For example, the location term

<eg rend=syntax>CHILD (1 * TARGET *)</eg>

selects the first child of the location source for which the attribute
<att tei="no">target</att> has a value.  The location term

<eg rend=syntax>CHILD (1 * (TARGET(S?)) *)</eg>

will select the first child of the location source for which an
attribute called either <att tei="no">target</att> or <att tei="no">targets</att> has a value.</p>

<p>As with generic identifiers, attribute names are case sensitive if
and only if the SGML declaration says they are; regular expressions are
always case sensitive and should usually be uppercased, as shown here.</p>

<p>In formal terms, the attribute-name parameter of a tree-traversal
step is defined thus:

<eg rend=syntax>
<![ CDATA [
attribute ::= NAME
         |    '*'
         |    '(' regular ')'
]]>
</eg></p>

<p>If a fourth, sixth, eighth, etc., parameter is specified, it is
interpreted as an attribute value, and only elements satisfying the
other constraints and also bearing an attribute of the specified name
and value will be selected.  The attribute value may be specified
exactly as in an SGML document; as a consequence, if the attribute value
to be specified contains white space characters, it must be enclosed in
quotation marks.  The attribute value may also be specified as a regular
expression, enclosed in parentheses, or using the two special values
<code type="kw">#IMPLIED</code> and <code type="kw">*</code>.</p>

<p>For example, the location specification

<eg rend=syntax>CHILD (1 * N 2) (1 * N 1)</eg>

chooses an element using the global <att>n</att> attribute.  Beginning
at the location source, the first child (whatever kind of element it is)
with an <att>n</att> attribute having the value <code type="value">2</code> is chosen; then that element's first direct
sub-element having the value <code type="value">1</code> for the same
attribute is chosen.</p>

<p>The location specification

<eg rend=syntax>CHILD (1 FS RESP ((lanc|LANC)(s|S|ashire|ASHIRE)))</eg>

selects the first child of the location source which is an <gi>fs</gi>
element bearing a <att tei="no">resp</att> attribute with the value
<code type="value">lancs</code>, <code type="value">lancashire</code>, <code
type="value">LANCS</code>, or <code type="value">LANCASHIRE</code> (as well
as other possible combinations which are left to the reader's
ingenuity).  If specified with quotation marks or as a regular
expression, the attribute-value parameter is case-sensitive; otherwise
not.

<!-- how do I say 'if the att value is #IMPLIED' tho?  --></p>

<p>The location specification

<eg rend=syntax>CHILD (1 FS RESP #IMPLIED)</eg>

selects the first child of the location source which is an <gi>fs</gi>
element for which the <att tei="no">resp</att> attribute has been left
unspecified.  The location ladder

<eg rend=syntax>ROOT DESCENDANT (1 (DIV[01234567]) TYPE chapter N 2)</eg>

selects the second chapter of a text, regardless of whether chapters are
tagged using <gi>div</gi>, <gi>div1</gi>, <gi>div2</gi>, or some other
text-division element.  It does so by selecting the first text-division
element in the document which is of <att tei="no">type</att> chapter and
has the <att tei="no">n</att> value 2.</p>

<p>In formal terms, the attribute-value parameter of a tree-traversal
step is defined thus:

<eg rend=syntax>
<![ CDATA [
value    ::=  LITERAL                  // i.e. quoted string.
         |    NAME                     // As for attribute values in
         |    NUMBER                   // document, NMTOKENs need not
         |    NUMTOKEN                 // be quoted
         |    '#IMPLIED'               // No value specified, no default
         |    '*'                      // Any value matches.
         |    '(' regular ')'
]]>
</eg></p></div4>

<div4 id="SAxr1de"><head>The DESCENDANT Keyword</head>

<p>If the <code type="teikw">descendant</code> keyword is used, the
location term selects an element or character-data string which is a
descendant of the current location source.  Like <code type="teikw">child</code>, <code type="teikw">descendant</code> takes as a
value a series of one or more parenthesized steps, which may contain the
same four parameters described above.  The set of elements and strings
which may be selected, however, is the set of all descendants of the
location source (i.e. the set of all elements contained by it), rather
than only the set of immediate children.</p>

<p>The location specification

<eg rend=syntax>ID (a23) DESCENDANT (2 TERM LANG DE)</eg>

thus selects the second <gi>term</gi> element with a <att>lang</att> of
<code type="value">de</code> occurring within the element with an
<att>id</att> of <code type="value">a23</code>.  The search for matching
elements occurs in the same order as the SGML data stream; in terms of
the document tree, this amounts to a depth-first left-to-right search.</p>

<p>If the instance number is negative, the search is a depth-first
right-to-left search, in which the right-most, deepest matching element
is numbered -1, etc.  The location specification

<eg rend=syntax>DESCENDANT (-1 NOTE)</eg>

thus chooses the last <gi>note</gi> element in the document, that is,
the one with the rightmost start-tag.</p></div4>

<div4 id="SAxr1an"><head>The ANCESTOR Keyword</head>

<p>The <code type="teikw">ancestor</code> location term selects an element
from among the direct ancestors of the location source in the document
hierarchy.  The location value is of the same form as defined for the
<code type="teikw">child</code> and <code type="teikw">descendant</code>
location types.  However, the <code type="teikw">ancestor</code> keyword
selects elements from the list of containing elements or
<socalled>ancestors</socalled> of the location source, counting upwards
from the parent of the location source (which is ancestor number 1) to
the root of the document instance (which is ancestor number -1).</p>

<p>The location source must have at least as many ancestors as the
absolute value of the instance number specified as the first parameter
of the step.  The <code type="teikw">ancestor</code> type thus may not be
specified as the first component of a location specification, because
the initial location source in effect at that point is the root, which
has no ancestors.</p>

<p>For example, the location term

<eg rend=syntax>ANCESTOR (1 * N 1) (1 DIV)</eg>

first chooses the smallest element properly containing the location
source and having attribute <att>n</att> with value <code type="value">1</code>; and then the smallest <gi>div</gi> element properly
containing it.  The location term

<eg rend=syntax>ANCESTOR (1)</eg>

chooses the immediate parent of the location source, regardless of its
type or attributes.  The location term

<eg rend=syntax>ANCESTOR (1 * LANG fr)</eg>

selects the smallest ancestor for which the <att>lang</att> attribute
has the value <code type="value">fr</code>.  The term

<eg rend=syntax>ANCESTOR (-1 * LANG fr)</eg>

selects the <emph>largest</emph> ancestor for which the <att>lang</att>
attribute has the value <code type="value">fr</code>.  Without the
attribute specification, the term

<eg rend=syntax>ANCESTOR (-1)</eg>

selects the largest ancestor of the location source and is thus normally
synonymous with the keyword <code type="kw">ROOT</code>.  If the instance
indicator is given as <code type="kw">ALL</code>, then all the ancestor
elements which match the later parameters are selected; since the
largest of these will necessarily include all the others, the value
<code type="kw">ALL</code> is thus synonymous with the value <code
type="value">(-1)</code> when used with <code type="kw">ANCESTOR</code>.

Finally, the term

<eg rend=syntax>ANCESTOR (1 (DIV[0123456789]?))</eg>

chooses the smallest <gi>div</gi> element of any level which contains
the location source.</p></div4>

<div4 id="SAxr1pr"><head>The PREVIOUS Keyword</head>

<p>The <code type="teikw">previous</code> keyword selects an element or
character-data string from among those which precede the location source
within the same containing element.  We speak of the elements and
character-data strings contained by the same <code type="teikw">parent</code> element as <term>siblings</term>; those which
precede a given element or string in the document are its <term>elder
siblings</term>; those which follow it are its <term>younger
siblings</term>.</p>

<p>The instance number in the location value of a <code type="teikw">previous</code> term designates the nth elder sibling of the
location source, counting from most recent to less recent.  The location
ladder

<eg rend=syntax>ID (a23) PREVIOUS (1)</eg>

thus designates the element immediately preceding the element with an
<att>id</att> of <code type="value">a23</code>.  Negative instance numbers
also designate elder siblings, counting from the eldest sibling to the
youngest.  The location source must have at least as many elder siblings
as the absolute value of the instance number.  If the location source
has at least one elder sibling, then the location term

<eg rend=syntax>PREVIOUS (-1)</eg>

designates its eldest sibling and is thus synonymous with the ladder

<eg rend=syntax>ANCESTOR (1) CHILD (1)</eg>

The value <code type="kw">ALL</code> may be used to select the entire
range of elder siblings of an element:  the location ladder

<eg rend=syntax>ID (a23) PREVIOUS (ALL)</eg>

thus designates the set of elements which precede the element with an
<att>id</att> of <code type="value">a23</code> and are contained by the
same parent.</p></div4>

<div4 id="SAxr1ne"><head>The NEXT Keyword</head>

<p>The keyword <code type="teikw">next</code> behaves like <code
type="teikw">previous</code>, but selects from the younger siblings of the
location source, not the elder siblings.  The location ladder

<eg rend=syntax>ID (a23) NEXT (1)</eg>

thus designates the element or string immediately following the element
which has an <att>id</att> of <code type="value">a23</code>.  Negative
instance numbers also designate younger siblings, counting from the
youngest sibling to the location source.  The location source must have
at least as many younger siblings as the absolute value of the instance
number.  If the location source has at least one younger sibling, then
the location term

<eg rend=syntax>NEXT (-1)</eg>

designates its youngest sibling and is thus synonymous with the ladder

<eg rend=syntax>ANCESTOR (1) CHILD (-1)</eg></p></div4>

<div4 id="SAxr1pc"><head>The PRECEDING Keyword</head>

<p>The <code type="teikw">preceding</code> keyword selects an element or
character-data string from among those which precede the location
source, without being limited to the same containing element.  The set
of elements and strings which may be selected is the set of all elements
and strings in the entire document which occur or begin before the
location source.  (For purposes of the keywords <code type="kw">PRECEDING</code> and <code type="kw">FOLLOWING</code>, elements
are interpreted as occurring where their start-tag occurs.)  The <code
type="kw">PRECEDING</code> keyword thus resembles <code type="kw">PREVIOUS</code> but differs in searching a larger set of strings
and elements; its result is not guaranteed to be a subset of its
location source.</p>

<p>The instance number in the location value of a <code type="teikw">preceding</code> term designates the nth element or
character-data string preceding the location source, counting from most
recent to less recent.  The location ladder

<eg rend=syntax>ID (a23) PRECEDING (5)</eg>

thus designates the fifth element or string before the element with an
<att>id</att> of <code type="value">a23</code>.  Negative instance numbers
also designate preceding elements or strings, counting from the eldest
to the youngest; the ladder

<eg rend=syntax>ID (a23) PRECEDING (-5)</eg>

thus selects the fifth element or string in the document overall,
assuming that it precedes the element with an <att>id</att> of <code
type="value">a23</code>.  It is thus normally synonymous with

<eg rend=syntax>ROOT DESCENDANT (5)</eg>

differing only in that it fails if four items or fewer precede element
A23.

The location source must have at least as many elder siblings as the
absolute value of the instance number; otherwise, the <code
type="teikw">preceding</code> term fails.

The value <code type="kw">ALL</code> may be used to select the entire
portion of the document preceding the beginning of the location source:
the location ladder

<eg rend=syntax>ID (a23) PRECEDING (ALL)</eg>

designates the entire portion of the document preceding the start-tag
for element A23.</p></div4>

<div4 id="SAxr1fw"><head>The FOLLOWING Keyword</head>

<p>The keyword <code type="teikw">following</code> behaves like <code
type="teikw">preceding</code>, but selects from the portion of the
document following the location source, not that preceding it.  The
location ladder

<eg rend=syntax>ID (a23) FOLLOWING (1)</eg>

thus designates the element or string immediately following the element
which has an <att>id</att> of <code type="value">a23</code>.  Negative
instance numbers select elements or strings counting from the end of the
document to the location source.  There must be at least as many
elements or strings following the location source as the absolute value
of the instance number.  If the location source has at least one
following element or string, then the location term

<eg rend=syntax>FOLLOWING (-1)</eg>

designates the youngest of these and is thus synonymous with the ladder

<eg rend=syntax>ROOT DESCENDANT (-1)</eg></p></div4>

<div4 id="SAxr1pa"><head>The PATTERN Keyword</head>

<p>The <code type="teikw">pattern</code> keyword selects the
<emph>first</emph> place within the location source which matches a
pattern-matching expression included as the location value.  If more
than one location matches that expression, there is no error, but the
second and later matches are ignored.</p>

<p>Matching is defined to be case-sensitive, i.e. <mentioned>abc</mentioned> is
<emph>not</emph> the same as <mentioned>ABC</mentioned>.  The pattern is
expressed as a regular expression in which the following characters have
special meanings, similar to those of many Unix programs (such as
<ident type="prog">grep</ident>) which handle regular expressions:

<list id="rechars" rend="dl" type="gloss">

<label>.</label><item>match any single character (including white
space characters).</item>

<label>[ ...  ]</label><item>match any character from the set enclosed
within the brackets.  If, however, the first enclosed character is
<mentioned>&circ;</mentioned>, then match any character <emph>not</emph> from
the set enclosed within the brackets.  For example,
<mentioned>[&circ;aeiou]</mentioned> would match any character except a, e, i,
o, or u.</item>

<label>\</label><item>If the next character is a, d, n, or s, the
expression matches any character from a pre-defined group, as shown
below; otherwise, the next character is to be taken literally, even if
it would otherwise have a special meaning.  The special character
classes are:
<list type="gloss">
<label>\a</label><item>any alphabetic character (as defined in the writing
system declaration)</item>
<label>\d</label><item>any digit (0 through 9)</item>
<label>\n</label><item>any line boundary</item>
<label>\s</label><item>any white-space character (space, tab, record end, record
start)</item>
</list>
Note that although \n for newline is provided, its use is
discouraged.</item>

<!-- what DOES this mean? if we find someone using it do we chop  -->
<!-- their hands off? lock them in a room with Michael Hart? or what? -->

<label>*</label><item>match zero or more occurrences of the previous
regular expression.</item>

<label>+</label><item>match one or more occurrences of the preceding
regular expression.</item>

<label>?</label><item>match zero or one occurrences of the preceding
regular expression.</item>

<label>&circ;</label><item>match the following regular expression only at
the beginning of the location source.</item>

<label>$</label><item>match the preceding regular expression only at the
end of the location source.</item>

<label>|</label><item>match either the regular expression on the left,
or the one on the right.</item>

<label>(...)</label><item>match the regular expression within the
parentheses.  (Parentheses are used to control application of the *, ?,
+, and | operators, etc.)</item>

</list></p>

<p>For example, the location specification

<eg rend=syntax>PATTERN (Chapter.8)</eg>

chooses the first instance of the content string <mentioned>Chapter</mentioned>
which is followed by any single character and then the digit 8, within
the location source.  Various elements which contain that location could
be selected by following the <code type="teikw">pattern</code> location
term with one or more of other types such as <code type="teikw">ancestor</code> (see above).</p>

<p>It is recommended practice to use structure-oriented location types
to specify the destination element as narrowly as possible, and then to
specify a pattern only within that element context.  If element
boundaries are encountered within the location source, however, they are
ignored and have no effect on the pattern matching operation.</p>

<p>In formal terms, the location value of the <code type="teikw">pattern</code> keyword is defined thus:

<eg rend=syntax>
<![ CDATA [
regs     ::= '(' regular ')'
         |    regs '(' regular ')'

regular  ::=  character
         |    '.'                           // match any character
         |    '^' || characters || ']'     // match any char not in list
         |    '[' || characters || ']'      // match any char in list
         |    '\a'                     // match any alphabetic
         |    '\d'                     // match any digit 0-9
         |    '\n'                     // match newline (&#RE;&#RS;)
         |    '\s'                     // match any whitespace character
         |    '\\'                     // match backslash (rev. solidus)
         |    '\' || nonspecial        // match nonspecial character
         |    regular || '*'           // match 0-n of 'regular'
         |    regular || '+'           // match 1-n of 'regular'
         |    regular || '?'           // match 0-1 of 'regular'
         |    '^' || regular           // match at start of loc source
         |    regular || '$'           // match at end of loc source
         |    regular || regular       // match 1st, then 2d regular exp.
         |    regular || '|' || regular // match either 1st or 2d
         |    '(' || regular || ')'    // use parentheses for grouping

characters ::= /* empty string */
         |    characters character

nonspecial ::= /* any character except a, d, n, or s */
]]>
</eg></p></div4>

<div4 id="SAxr1to"><head>The TOKEN Keyword</head>

<p>The <code type="teikw">token</code> keyword selects a sequence of one
or more <term rend="noindex">tokens</term> chosen from within the
character content of the location source, where tokens are counted
exactly as for the corresponding HyTime <code type="kw">tokenloc</code>
form.  The location value must be either a single positive integer, or a
pair of positive integers separated by white space, representing the
first and the last token numbers to be included in the resulting
location.  If two integers are specified, the second must not be less
than the first.  The location source must contain at least as many
tokens as are specified in the location value.</p>

<p>This location type should not be used to count across element
boundaries.  It is recommended practice to use structure-oriented
location types to specify the destination element as narrowly as
possible, and then to specify a token location only within that element
context.  If element boundaries are encountered within the location
source, they are ignored.</p>

<p>This location type behaves intuitively only for strings containing an
alternating sequence of SGML name-characters and white space; this is
the type of string found, for example, in SGML attribute values of type
IDREFS, such as <code type="value">a21 z a13</code>.

<!-- It is not TEI recommended practice to apply TOKENLOC to  -->
<!-- other string types, in part because it would compromise  -->
<!-- interconvertibility with HyTime; but if such counting is  -->
<!-- needed, tokens shall be counted as if all non white space  -->
<!-- characters (such as punctuation) were added to the class of  -->
<!-- name characters.  That is, only white space characters  -->
<!-- separate tokens.< /note>  -->

For compatibility with the HyTime standard, all characters not included
in the class of name characters by the current SGML declaration (by
default this includes all punctuation other than the hyphen and full
stop) are treated as white space characters.</p>

<p>For example, the location specification

<eg rend=syntax>ID (a27) TOKEN (3 5)</eg>

chooses the 3rd, 4th, and 5th tokens from the content of the element
whose identifier is <code type="value">a27</code>.  If this element
contained the string <mentioned>This is _not_ a very good idea</mentioned>, the
target selected would be <mentioned>not_ a very</mentioned>.</p>

<p>In formal terms the location value of the <code type="teikw">token</code> and <code type="teikw">str</code> keywords is
defined as a range:

<eg rend=syntax>
<![ CDATA [
range    ::=  NUMBER
         |    NUMBER NUMBER
]]>
</eg></p></div4>

<div4 id="SAxr1st"><head>The STR Keyword</head>

<p>The <code type="teikw">str</code> keyword identifies a sequence of one
or more <term rend="noindex">characters</term> chosen from within the
character content of the location source, where characters are counted
exactly as for the HyTime <code type="kw">dataloc</code> form with <code
type="frag">quantum=str</code>, which has a corresponding meaning and
usage.  The location value must be either a single positive integer, or
a pair of positive integers separated by white space, indicating the
first and the last characters to be included in the resulting location.
If two integers are specified, the second must not be less than the
first.  The location source must have at least as many characters as are
specified in the larger of the integers.</p>

<p>This location type should not be used to count across element
boundaries.  The recommended practice is to use structure-oriented
location types to specify the destination element, and then to specify a
character location only within that element context.  If element
boundaries are encountered, however, within the location source, they
have no effect.</p>

<p>Character offsets in an SGML document must be counted not from the
original source file, but from the output of the SGML parser, (the
<term>element structure information set</term> or <term>ESIS</term>).
This is because the rules of SGML allow certain characters to be deleted
or expanded transparently.</p>

<p>For example, the location specification

<eg rend=syntax>ID (a27) STRLOC (3 5)</eg>

chooses the 3rd 4th and 5th characters of the content of the element
having identifier a27.  If this element contained the string <q>This
turned out to be an even worse idea</q>, the result would be the string
<mentioned>is </mentioned> (i, s and a space).

<!-- Not sure whether or not to keep the following one: -->
<!-- It needs to be checked for consistency with whatever goes -->
<!-- into graphs, figures etc. --></p>

<p>In multi-byte character sets it is characters which are counted, not
bytes.  However, in the case of diacritics coded by sequences of bit
combinations rather than having separate code points for every
combination of letter and diacritic, the diacritics are counted.  This
means that the following location ladder may retrieve different strings,
depending on the system character set in use and on the entity
declarations in effect:

<eg rend=syntax>
<![ CDATA [
PATTERN (Wagner's\sG&ouml;tterd&aum;mmerung) STR (10 24)
]]>
</eg>

In some character sets, where &ouml; and &auml; are encoded as single
characters, it will select the string
<mentioned>G&ouml;tterd&auml;mmerung</mentioned>; in others, where they are
encoded with distinct characters for umlaut, a, and o, it will select
the string <mentioned>G&ouml;tterd&auml;mmeru</mentioned>, truncating the last
two letters.  If a system-dependent definition is used (containing e.g.
a printer escape sequence), the results are even less predictable.  For
this reason, the <code type="teikw">str</code> keyword must be used with
caution and should be avoided where possible.</p></div4>

<div4 id="SAxr1sp"><head>The SPACE Keyword</head>

<p>The <code type="teikw">space</code> location term applies to entities
which represent graphical or spatio-temporal data; typically such
entities are not encoded in SGML, but in one of many specialized
graphical formats.  SGML provides standard mechanisms (the NOTATION
declaration and related constructs) for specifying what format such an
entity uses.</p>

<p>The location value for <code type="teikw">space</code> consists of two
or three parenthesized parameter lists.  The first contains the name of
the co-ordinate space in use.  The second and third each consist of any
number of signed integers.  The numbers in a parameter list represent
locations along each dimension of a Cartesian co-ordinate space with all
axes orthogonal; the length of the list equals the number of
dimensions/axes of the space (usually, but not inevitably, 2, 3, or 4).</p>

<p>If the third parameter list is not specified, the location is the
single point in the co-ordinate space specified by the second parameter
list.  If all three parameter lists are specified, the location is the
rectangular prism defined by treating corresponding items of the second
and third lists as inclusive bounds along each dimension in turn.</p>

<p>The mapping from co-ordinates to physical or display space, and the
meaning and ordering of the axes, are not defined by these guidelines.
They should be specified in the TEI header unless they can be determined
by definition from the format in which the referenced entity is known to
be encoded (for example, many graphics formats can only encode locations
in units of pixels, counted in a 3 dimensional left-handed co-ordinate
space).</p>

<p>Time may be construed as an axis in addition to any others; when it
is, it is TEI recommended practice that it be positioned last.  The
units used must be defined in the TEI header; it is acceptable in
certain media (such as videodiscs) to use frame numbers as a surrogate
axis for time.</p>

<p>For example,

<eg rend=syntax>SPACE (2D) (0 0) (1 1)</eg>

specifies the location of the unit square tangent to the origin in
quadrant 1 of a common graph.</p>

<p>The location value for a <code type="teikw">space</code> location term
is a NAME enclosed in parentheses, followed by a point pair:

<eg rend=syntax>
<![ CDATA [
pointpair ::= '(' numbers ')'
         |    '(' numbers ')' '(' numbers ')'

numbers  ::=  signed
         |    numbers signed
]]>
</eg>

<!-- Changed definition of numbers to from the following,     -->
<!-- which contradicts the prose (NUMBER is unsigned, no?)    -->
<!-- msm                                                      -->
<!-- numbers  ::=  NUMBER                                     -->
<!--          |    numbers NUMBER                             -->
<!--          ;                                               --></p></div4>

<div4 id="SAxr1fo"><head>The FOREIGN Keyword</head>

<p>The <code type="teikw">foreign</code> keyword takes any number of
parenthesized parameter lists, and is terminated by the end of the
attribute value, or by the next non-parenthesized token, whichever comes
first.</p>

<p>The meaning of the <code type="teikw">foreign</code> location term is
not defined by these Guidelines.  It is intended for use in pointing to
special kinds of non-SGML, non-coordinate space data.  That is, it
should be used for making links to data which cannot be specified using
the other mechanisms.  The meaning of any <code type="teikw">foreign</code> location types must be specified in the TEI
header, as a series of paragraphs at the end of the
<gi>encodingDesc</gi> element defined in section <ptr target="HD5">.

<!-- BUT WHERE? -->
<!-- encodingDesc.  I think. -msm -->

If more than one such type is used, it is TEI recommended practice that
the first parameter list to <code type="teikw">foreign</code> be a name
associated with the particular type by documentation in the TEI header.</p>

<p>For example, assume that some program uses a proprietary data format
called XFORM, and that the program has supplied an identifier <code
type="value">06286208998</code> for some piece of data it owns.  Then the
location specification

<eg rend=syntax>FOREIGN (XFORM) (06286208998)</eg>

would be one way of expressing a link to that piece of data.</p></div4>

<div4 id="SAxr1hy"><head>The HYQ Keyword</head>

<p>The <code type="teikw">HyQ</code> keyword takes a single parenthesized
parameter lists, which contains an expression in the <code
type="teikw">HyQ</code> query language defined by the HyTime standard.
See documentation on HyTime and HyQ for definitions of HyQ expressions.</p></div4>

<div4 id="SAxr1di"><head>The DITTO Keyword</head>

<p>The <code type="teikw">ditto</code> keyword is valid only as the first
location term in a ladder, and only within the <att>to</att> attribute
of an extended pointer element.  It designates the location result of
the <att>from</att> attribute on the same element.  Thus in the pointer

<eg>
<![ CDATA [
<xptr from='ID (a23) ANCESTOR (1 DIV[0123]) PATTERN (Wagnerian)'
      to='DITTO PATTERN (Liebestod)'>
]]>
</eg>

the <att>from</att> attribute designates the first occurrence of the
string <mentioned>Wagnerian</mentioned> in the <gi>div</gi> containing the
element with an <att>id</att> of <code type="value">a23</code>.  The
<att>to</att> attribute designates the first occurrence of the string
<mentioned>Liebestod</mentioned> which occurs <emph>after</emph>
<mentioned>Wagnerian</mentioned>, within the same <gi>div</gi>.  Without the
<code type="teikw">ditto</code> keyword, it would be necessary to repeat
the entire location ladder of the <att>from</att> attribute in the
<att>to</att> attribute, which would be error-prone for complex
expressions.</p></div4></div3>

<div3 id="SAxr2"><head>Using Extended Pointers</head>

<p>As noted above, when only the <att>from</att> attribute is specified,
the <gi>xref</gi> or <gi>xptr</gi> element points at the span indicated
by <att>from</att>.  When both <att>from</att> and <att>to</att> are
specified, the element points at the span running from the beginning of
the span indicated by the former to the end of the span indicated by the
latter.  To point at the second, third, and fourth paragraphs of the
second chapter (<gi>div1</gi>) in the body of the current document,
therefore, one may specify either of the following:

<eg>
<![ CDATA [
<xptr from='DESCENDANT (1 body) CHILD (2 div1) (2 p)'
      to = 'DESCENDANT (1 body) CHILD (2 div1) (4 p)' >
<!-- or equivalently: -->
<xptr from='DESCENDANT (1 body) CHILD (2 div1) (2 p)'
      to = 'DITTO NEXT (2 p)'>
]]>
</eg></p>

<p>To point to <q>the <gi>term</gi> occurring in the current
<gi>termEntry</gi> with attribute <att>n</att> = 2</q>, only the
<att>from</att> attribute would be required:

<eg>
<![ CDATA [
<xptr from='HERE ANCESTOR (1 TERMENTRY) DESCENDANT (1 TERM N 2)'>
]]>
</eg></p>

<p>The following example demonstrates how elements from two different
documents may be combined

<eg>
<![ CDATA [

<xptr id=x1 doc=doc1 from='id (d1.1)'>
<xptr id=x2 doc=doc2 from='id (d2.1) tree (2 *)'>

<ptr id=p1 target='x1 x2'>

<link targets='p1 s1 s2' evaluate=all>
]]>
</eg>

The first <gi>xptr</gi> indicates the element in doc1 which has
identifier <code type="value">d1.1</code>.  The second indicates the
second subelement of the element in doc2 which has identifier <code
type="value">d2.1</code>.  These two elements are pointed to as a single
item by the <gi>ptr</gi> element and given the identifier <code
type="value">p1</code>.  This aggregation, finally, is linked with two
other elements both in the current document, with identifiers <code
type="value">s1</code> and <code type="value">s2</code>.</p>

<p>An extended pointer, as described above, may specify as its target
only a single destination.  Where the intended destination of a link is
an aggregation or alignment of destinations, possibly in separate
documents, an intermediate pointer of some kind must be used, as
described in section <ptr target="SAptip"> elsewhere in this chapter.
Like any other element, an <gi>xref</gi> and <gi>xptr</gi> may be given
a unique id within the document that contains them.  This id value can
then be supplied as one of the <att>target</att> values for an
intermediate <gi>ptr</gi> or <gi>link</gi> element, to represent
aggregation or linkage respectively.  The <gi>join</gi> element
discussed in section <ptr target="SAag"> may also be used.</p>

<p>For example, a modern commentary on an older text must frequently
refer to that text, which might well be encoded in a separate SGML
document.  Some discussions will refer to set of discrete passages in
the older text, and will thus require multi-headed pointers.  In such a
case, the document type declaration must contain a declaration for an
SGML entity containing the older text, which might look something like
this:

<eg>
<![ CDATA [
<!-- the 1729 Dunciad Variorum -->
<!ENTITY dunciad system 'dunc1729.tei' >
]]>
</eg>

In the commentary itself, reference will be made to this external
document, using <gi>xptr</gi> and <gi>xref</gi> elements.  When the
commentary refers to aggregates of discontiguous passages, <gi>xptr</gi>
elements are used to point to the individual passage, and a <gi>ref</gi>
element may refer to these passages as a group by pointing to the
<gi>xptr</gi>s:

<!-- These examples should be pointing at notes and lines in  -->
<!-- the Dunciad which really do refer to Theobald and Curl,  -->
<!-- and it would be nice to have a link for something other  -->
<!-- than a person named; possibly imitations of Vergil vs.   -->
<!-- imitations of Ovid, or references to gluttony vs.        -->
<!-- references to piss vs. references to shit.  I'll work    -->
<!-- on this this evening.                                    -->
<!-- These are not at all exhausting, but at least the line   -->
<!-- numbers given are real ones now.                         -->

<!-- Perhaps for P3 or for the case book we can get someone   -->
<!-- to give us a real web from an Intermedia system or       -->
<!-- something, or maybe Elli can reproduce part of Perseus.  -->

<eg>
<![ CDATA [
<xptr id='xL2.5'   doc=dunciad from='ID (L2.5)'  >
<xptr id='xN1.48'  doc=dunciad from='ID (N1.48)' >
<xptr id='xN1.68'  doc=dunciad from='ID (N1.68)' >
<xptr id='xN1.104' doc=dunciad from='ID (N1.104)'>
<xptr id='xN1.106' doc=dunciad from='ID (N1.106)'>
 ...
<p>In <ref target='xL2.5 xN1.48 xN1.68 xN1.104 xN1.106'
evaluate=all>the references to Theobald</ref>, Pope's satire
characteristically ...</p>
]]>
</eg>

If the same discontiguous target is to be referred to repeatedly, it may
be convenient to give it a single identifier, thus:

<eg>
<![ CDATA [
<xptr id='xL2.5'   doc=dunciad from='ID (L2.5)'  >
<xptr id='xN1.48'  doc=dunciad from='ID (N1.48)' >
<xptr id='xN1.68'  doc=dunciad from='ID (N1.68)' >
<xptr id='xN1.104' doc=dunciad from='ID (N1.104)'>
<xptr id='xN1.106' doc=dunciad from='ID (N1.106)'>
<ptr id='Theobald' target='xL2.5 xN1.48 xN1.68 xN1.104 xN1.106'>
 ...
<p>In <ref target='Theobald' evaluate=all>the references to
Theobald</ref>, Pope's satire characteristically ...</p>
]]>
</eg></p>

<p>A hypertext web might associate passages of the text and notes with
the individuals mentioned, the ancient authors imitated, or thematic
content, thus:

<eg>
<![ CDATA [
<xptr id='xL2.5'   doc=dunciad from='ID (L2.5)'  >
<xptr id='xN1.48'  doc=dunciad from='ID (N1.48)' >
<xptr id='xN1.68'  doc=dunciad from='ID (N1.68)' >
<xptr id='xN1.104' doc=dunciad from='ID (N1.104)'>
<xptr id='xN1.106' doc=dunciad from='ID (N1.106)'>
<ptr id='Theorefs' target='xL2.5 xN1.48 xN1.68 xN1.104 xN1.106'>

<xptr id='xN2.3'   doc=dunciad from='ID (N2.3)'  >
<xptr id='xN2.46'  doc=dunciad from='ID (N2.46)' >
<xptr id='xN2.54'  doc=dunciad from='ID (N2.54)' >
<xptr id='xN2.66'  doc=dunciad from='ID (N2.66)'>
<xptr id='xN2.78'  doc=dunciad from='ID (N2.78)'>
<xptr id='xN1.104' doc=dunciad from='ID (N1.104)'>
<ptr id='Curlrefs' target='xN2.3 xN2.46 xN2.54 xN2.66 xN2.78 xN1.104'>

 <!-- ... -->
<div><head>Individuals Named in the Text</head>
<list type=gloss>
<label id=curlname>Curll, Edmund</label>
<item  id=curldesc>A bookseller and publisher ... </item>
 <!-- ... -->
<label id=Theoname>Theobald, Lewis.</label>
<item  id=Theodesc>Attorney, active also as editor and reviewer ...
</item>
 <!-- ... -->
</list>

 <!-- ... -->
<div><head>Ancient Authors Imitated in the Text</head>
<list type=bulleted>
<item id=virgil>Virgil
<item id=homer >Homer
<item id=ovid  >Ovid
 <!-- ... -->
</list>

<ptr id=Curll    target='curlname curldesc'>
<ptr id=Theobald target='theoname theodesc'>
 <!-- ... -->
<linkGrp type=bio>
<link targets='theobald theorefs'>
<link targets='curl     curlrefs'>
 <!-- ... -->
</linkGrp>
<linkGrp type=imitations>
<link targets='virgil   virgrefs'>
<link targets='homer    homerefs'>
 <!-- ... -->
</linkGrp>
]]>
</eg>
</p></div3></div2>
<!-- more, and realler, examples needed -->
<!-- damn straight. -msm                -->


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

<!-- $Id: p2sase.odd,v 1.9 1999/05/17 17:53:27 tei Exp $ -->
<!--*
    * $Log: p2sase.odd,v $
    * Revision 1.9  1999/05/17 17:53:27  tei
    * fix bad linebreak in eg
    *
    * Revision 1.8  1998/02/05 17:14:35  tei
    * make examples parse
    *
    * Revision 1.7  98/01/28  11:09:58  cmsmcq
    * LB changes of January 1998
    *
    * Revision 1.6  1994/03/27  21:47:19  msmcq
    * Correction of typos found by SJ, DB et al.
    *
    * Revision 1.5  1994/03/16  03:29:41  msmcq
    * Changes as per JL, with some LB and TL.
    *
    * Revision 1.4  1994/02/12  10:22:43  lou
    * reviions for P3
    *
    * Revision 1.2  1993/09/16  19:01:31  msmcq
    * Minor SGML cleanup, add RCS log keyword
    * -->
<!-- Revisions:                                               -->
<!-- 8 Jan 98: LB : added ab element -->
<!-- 94-03-26 : MSM : corrections from SJ                     -->
<!-- 94-03-26 : MSM : disambiguate TERM, Q (> code, ident...) -->
<!-- 94-03-15 : MSM : changes as per LB, TL, JL               -->
<!-- 4 feb LB merged in anchor; revised and expanded          -->
<!-- 19 dec 93: LB: fixed an xref                             -->
<!-- 93-09-15 : MSM : minor SGML cleanup                      -->
<!-- 93-07-22 : DTL : more minor fixes                        -->
<!-- 93-07-12 : DTL : minor fixes                             -->
<!-- 93-07-08 : DTL : rewrite material on arbitrary           -->
<!-- segments from COse; exx from Shields "Dead Languages",   -->
<!-- refer to Pope ex in SApt, Sigmund ex in AIsp             -->
<div2 id=SAse><head>Blocks, Segments and Anchors</head>

<p>In this section, we define three general purposes elements which may be
used to mark and categorize both a span of text and a point within one.
These elements have several uses, most notably to provide elements which
can be given identifiers for use when aligning or linking to parts of a
document, as discussed elsewhere in this chapter.  They also provide a
convenient way of extending the semantics of the TEI markup scheme in a
theory-neutral manner, by providing for two neutral or <soCalled>anonymous</socalled> elements to which the encoder can add any meaning not
supplied by other TEI defined elements.

<list type=gloss>
<label><gi>anchor</gi></label>
<item>attaches an identifier to a
point within a text, whether 
or not it corresponds with a textual
element.</item>
<label><gi>seg</gi></label>
<item>contains any arbitrary phrase-level unit of text (including
other <gi>seg</gi> elements).
Attributes include:
<list type=gloss>
<label><att>part</att></label>
<item>specifies whether or not the segment is complete.
Legal values are:
<list type=gloss>
<label><term>F</term></label>
<item>the final part of an incomplete segment</item>
<label><term>Y</term></label>
<item>the segment is incomplete</item>
<label><term>N</term></label>
<item>either the segment is complete, or no claim is made as to 
its completeness</item>
<label><term>I</term></label>
<item>the initial part of an incomplete segment</item>
<label><term>M</term></label>
<item>a medial part of an incomplete segment</item>
</list></item>
</list>
</item>
<label><gi>ab</gi></label>
<item>contains any arbitrary component-level unit of text, acting 
as
an anonymous container for phrase or inter level 
elements analogous to, but
without the semantic baggage 
of, a paragraph.
Attributes include:
<list type=gloss>
<label><att>part</att></label>
<item>specifies whether or not the block is complete.
Legal values are:
<list type=gloss>
<label><term>F</term></label>
<item>the final part of an incomplete block</item>
<label><term>Y</term></label>
<item>the block is incomplete</item>
<label><term>N</term></label>
<item>either the block is complete, or no claim is made as to its 
completeness</item>
<label><term>I</term></label>
<item>the initial part of an incomplete block</item>
<label><term>M</term></label>
<item>a medial part of an incomplete block</item>
</list></item>
</list>
</item>
</list>


These elements are all members of the class <ident
type=class>typed</ident>, and inherit from it the attributes
<att>type</att> and <att>subtype</att>:

<list type=gloss>
<label><att>type</att></label>
<item>characterizes the element in some sense, using any 
convenient classification scheme or typology.</item>
<label><att>subtype</att></label>
<item>provides a sub-categorization of the element, if needed</item>
</list>

<!-- Killed following example as insufficiently convincing -->
<!-- for reasons given in note. -->
<!-- Substituted references elsewhere and following discussion. -->

<!-- <p>For example, the <gi>seg</gi> tag may be used to -->
<!-- delimit the sequence of words at the beginning of a text -->
<!-- division that are highlighted in some way. -->

<!-- <note place=foot>The <gi>hi</gi> tag (see <ptr -->
<!-- target=COhqhe>) may, of course, also be used in this case, -->
<!-- but the <att>type</att> attribute of the <gi>seg</gi> tag -->
<!-- makes it possible to specify the purpose of the -->
<!-- highlighting.</note> -->

<!-- David Shields, Dead Languages, 1990, p56 -->
<!-- <eg><![ CDATA [ -->
<!-- <div1 n=8> -->
<!-- <p><s><seg type='beginning of chapter' rend=caps> -->
<!-- So father's only</seg> -->
<!-- glory was the ballfield.</s> -->
<!-- ]]> -->
<!-- </eg> -->

<p>The <gi>anchor</gi> element may be thought of as an empty
<gi>seg</gi>, or as an artifice enabling an identifier to be attached
to any position in a text. Like the <gi>milestone</gi> element
discussed in section <ptr target=COrs>, it is useful where multiple
views of a document are to be combined, for example, when a logical
view based on paragraphs or verse lines is to be mapped on to a
physical view based on manuscript lines.  However, it differs from the
milestone and related elements in that the <gi>anchor</gi> element
should not be used to mark the start or end of an arbitrary zone
within a text, but only to mark an arbitrary point used for alignment,
or as the target of a spanning element such as those discussed in
section <ptr target=PHad>.

<!-- I think this is a really bizarro example -->
<!-- but havent been able to find  a better one (LB) -->

<p>For example, suppose that we wish to mark the end of the fifth word
following each occurrence of some term in a particular text, perhaps to
assist with some collocational analysis.  This can most easily be done
with the help of the <tag>anchor</tag> tag, as follows:

<!-- Vladimir Nabokov, Pnin, 1953, p14 of 1967 Avon pb reprinting -->
<eg><![ CDATA [
<!-- ... -->
English language.  Except for not very<anchor id=eng1 >
<!-- ... -->
English at all at the time<anchor id=eng2 >
<!-- ... -->
English was still full of flaws<anchor id=eng3 >
<!-- ... -->
English.  This was revised by young<anchor id=eng4>
]]>
</eg>

In  section <ptr target="sacs1"> we discuss
ways in which these <gi>anchor</gi>
points might be used to represent an alignment such as one
might get in a keyword-in-context concordance.

<!-- add more examples/ cross references -->

<p>The <gi>seg</gi> element may be used at the encoder's discretion to
mark almost any segment of the text of interest for processing.  One use
of the element is to mark text features for which no appropriate markup
is otherwise defined, i.e. as a simple extension mechanism.  Another use
is to provide an identifier for some segment which is to be pointed at
by some other element, i.e. to provide a target, or a part of a target,
for a <gi>ptr</gi> or other similar element.

<p>Several examples of uses for the <gi>seg</gi> element are provided
elsewhere in these Guidelines. For example:
<list>
<item>as a means of marking segments significant in a metrical or
rhyming analysis (see section <ptr target=VEme>)
<item>as a means of marking typographic lines in drama (see section
<ptr target=DRbod>) or title pages (see section <ptr target=DStitl>)
<item>as a means of marking prosody- or pause-defined units in
transcribed speech (see section <ptr target=TSsase>)
<item>as a means of marking linguistic or other analyses in a
theory-neutral manner (see chapter <ptr target=AI> passim)
</list>

<p>In the following simple example, the <gi>seg</gi> element simply
delimits the extent of a stutter, a textual feature for which no
element is provided in these Guidelines.

<eg><![ CDATA [
<q>Don't say
<q><seg type=stutter>I-I-I</seg>'m afraid,</q>
Melvin, just say
<q>I'm afraid.</q></q>
]]>
</eg>
<!-- David Shields, Dead Languages, 1990, p10 -->
<!-- removed irrelevant tagging LB -->

The <gi>seg</gi> element is particularly useful for the mark-up of
linguistically significant constituents such as the phrases that may be
the output of an automatic parsing system.  This example also
demonstrates the use of the <att>id</att> attribute to carry an
identifier which other parts of a document may use to point to, or align
with:

<eg><![ CDATA [
<seg type=sentence id=BL0034>
  <seg type=phrase id=BL0034.1>Literate and illiterate speech</seg>
  <seg type=phrase id=BL0034.2>in a language like English</seg>
  <seg type=phrase id=BL0034.3>are plainly different.</seg>
</seg>
]]>
</eg>
<!-- Bloomfield, "Literate and Illiterate Speech", 1927   -->
<!-- removed irrelevant rend attribute -->

<p>As the above example shows, <gi>seg</gi> elements may be nested
directly within one another, to any degree of analysis considered
appropriate.  This is taken a little further in the following example,
where the <att>type</att> and <att>subtype</att> attributes have been
used to further categorise each word of the sentence (the <att>id</att>
attributes have been removed to reduce the complexity of the example):

<eg><![CDATA[
<seg type=sentence subtype=declarative>
  <seg type=phrase subtype=noun>
    <seg type=word subtype=adjective>Literate</seg>
    <seg type=word subtype=conjunction>and</seg>
    <seg type=word subtype=adjective>illiterate</seg>
    <seg type=word subtype=noun>speech</seg>
    </seg>
  <seg type=phrase subtype=preposition>
    <seg type=word subtype=preposition>in</seg>
    <seg type=word subtype=article>a</seg>
    <seg type=word subtype=noun>language</seg>
    <seg type=word subtype=preposition>like</seg>
    <seg type=word subtype=noun>English</seg>
    </seg>
  <seg type=phrase subtype=verb>
    <seg type=word subtype=verb>are</seg>
    <seg type=word subtype=adverb>plainly  </seg>
    <seg type=word subtype=adjective>different</seg>
    </seg>
  <seg type=punct>.</seg>
  </seg>
]]>
</eg>

<p>(The example values shown are chosen for simplicity of comprehension,
rather than verisimilitude).  It should also be noted that specialized
segment elements are defined in section <ptr target=AIlc> to facilitate
this particular kind of analysis.  These allow for the explicit mark up
of units called <term>s-units</term>, <term>clauses</term>,
<term>phrases</term>, <term>words</term>, <term>morphemes</term> and
<term>characters</term>, which may be felt preferable to the more
generic approach typified by use of the <gi>seg</gi> element.  Using
these, the first phrase above might be encoded simply as

<eg>
<![ CDATA [
  <phr type=noun>
    <w type=adjective>Literate</w>
    <w type=conjunction>and</w>
    <w type=adjective>illiterate</w>
    <w type=noun>speech</w>
  </phr>
]]>
</eg>

Note the way in which the <att>type</att> attribute of these specialized
elements now carries the value carried by the <att>subtype</att>
attribute of the more general <gi>seg</gi> element.  For an analysis not
using these traditional linguistic categories however, the <gi>seg</gi>
element provides a simple but powerful mechanism.

<p>In language corpora and similar material, the <gi>seg</gi> element
may be used to provide an end-to-end segmentation as an alternative to
the more specific <gi>s</gi> element proposed in chapter <ptr
target=AIlc> for the mark-up of orthographic sentences, or
<term>s-units</term>.  However, it may be more useful to use the
<gi>s</gi> element for this purpose, since this means that the
<gi>seg</gi> element can then be used to mark both features within
s-units and segments composed of s-units, as in the following example:
<note place=foot>See section <ptr target=AIsp>, where the text from
which this fragment is taken is analyzed.</note>

<eg><![ CDATA [
<seg id=S1S3 type='narrative unit'>
<s id=S1>Sigmund, the
  <seg type=patronymic>son of Volsung</seg>,
   was a king in Frankish country.</s>
<s id=S2>Sinfiotli was the eldest of his sons.</s>
<s id=S3><!-- ... --></s>
</seg>
]]>
</eg>

<p>Like other elements, the <gi>seg</gi> tag must be properly enclosed
within other elements.  Thus, a single <gi>seg</gi> element can be used
to group together words in different sentences only if the sentences are
not themselves tagged.  The first of the following two encodings is
legal, but the second is not.

<!-- Made up example -->
<eg rend=erroneous><![ CDATA [
Give me <seg type=phrase>a dozen.  Or two or three.</seg>

<!-- Illegal! -->
<s>Give me <seg type=phrase>a dozen.</s>
<s>Or two or three.</s></seg>
]]>
</eg>

<p>The <att>part</att> attribute may be used as one simple method of
overcoming this restriction:

<eg><![ CDATA [
<s>Give me <seg type=phrase part=I>a dozen.</seg></s>
<s><seg part=F>Or two or three.</seg></s>
]]>
</eg>

Another solution is to use the <gi>join</gi> element discussed in
section <ptr target=SAag>; this requires that each of the <gi>seg</gi>
elements be given an identifier.  For further discussion of this generic
encoding problem see also chapter <ptr target=NH>.

<p>The <gi>seg</gi> element has the same content as a paragraph in
prose:  it can therefore be used to group together consecutive sequences
of <ident type=class>inter</ident> class elements, such as lists,
quotations, notes, stage directions etc. as well as to contain sequences
of phrase-level elements.  It cannot however be used to group together
sequences of paragraphs or similar text units such as verse lines; for
this purpose, the encoder should use intermediate pointers, as described
in section <ptr target=SAptip> or the methods described in section
<ptr target=SAag>.

<!-- deleted (mistagged?) example of how not to do it LB  -->
<!-- M.F.K. Fisher, "I was really very hungry", As They       -->
<!-- Were, 1983, p41                                          -->
<!-- <eg><![ CDATA [ -->
<!-- Illegal! -->
<!-- <seg> -->
<!-- <p> -->
<!--  -->
<!-- <q who=MFKF><foreign lang=FR>Mon Dieu!</foreign> All for -->
<!-- me?</q> I peered at her.  She nodded, her discretion quite -->
<!-- gone now and a look of ecstatic worry on her pale face and -->
<!-- eyes and lips.  </p> <p> There were at least eight dishes. -->
<!-- I felt almost embarrassed, and sat for a minute looking -->
<!-- weakly at the fork and spoon in my hand.  </p> </seg> ]]> -->
<!-- </eg> -->


It is particularly important that the encoder provide a clear
description of the principles by which a text has been segmented, and
the way in which that segmentation is represented.  This should include
a description of the method used and the significance of any
categorization codes.  The description should be provided as a series of
paragraphs within the <gi>segmentation</gi> element of the encoding
description in the TEI header, as described in section <ptr
target=HD53>.

<!-- EDITORS: I can't readily locate where you have said      -->
<!-- this; please supply any missing details.  This problem   -->
<!-- also occurs elsewhere.  (DTL)                            -->
<!-- done. Lou -->

<P>The remainder of this chapter contains a number of examples of the use
of the <GI>seg</GI> element simply to provide an element to which an
identifier may be attached, for example so that another segment may be
linked or related to it in some way.
</P><P>
The <GI>ab</GI> (anonymous block)
element performs a similar function to that of the <gi>seg</gi> element,
but is used for portions of the
text which occur not within paragraphs or other component-level
elements, but at the component level themselves.  It may be used, for
example, to tag the canonical verse divisions of Biblical texts:
<EG>
<![CDATA [<div1 type='book' n='Gen'>
<head>The First Book of Moses, Called</head>
<head type='main'>Genesis</head>
<div2 type='chapter' n='1'>
<ab n='1'>In the beginning God created the heaven and the
earth.</ab>
<ab n='2'>And the earth was without form, and void; and darkness
<hi>was</hi> upon the face of the deep.  And the Spirit of God
moved upon the face of the waters.</ab>
<ab n='3'>And God said, Let there be light:  and there was
light.</ab>
<!-- ... -->
]]>
</EG>
<!--* Authorised Version *-->
</P><P>
In other cases, where the text clearly indicates paragraph divisions
containing one or more verses, the <GI>p</GI> element may be used to
tag the paragraphs, and the <GI>seg</GI> element used to subdivide
them. The <GI>ab</GI> element is provided as an alternative to the
<GI>p</GI> element; it may <EMPH>not</EMPH> be used  within
paragraphs. The <GI>seg</GI> element, by contrast, may appear only
within and not between paragraphs (or anonymous block elements).<EG>
<![CDATA [<div1 type='book' n='Gen'><head>Das Erste Buch Mose.</head>
<div2 type='chapter' n='1'>
<p>
<seg n='1'>Am Anfang schuff Gott Himel vnd Erden.</seg>
<seg n='2'>Vnd die Erde war w&uuml;st vnd leer / vnd es war
finster auff der Tieffe / Vnd der Geist Gottes schwebet auff
dem Wasser.</seg>
</p>
<p>
<seg n='3'>Vnd Gott sprach / Es werde Liecht / Vnd es ward
Liecht.</seg>
<!-- ... -->
]]>
</EG>
<!--* Martin Luther [tr].  Die gantze Heilige Schrifft Deudsch.
Wittenberg 1545.  Letzte zu Luthers Lebzeiten erchienene Ausgabe, hsg.
Hans Volz unter Mitarbeit von Heinz Blanke. Textredaktion Friedrich Kur.
M&uuml;nchen:  Rogner & Bernhard, 1972. *-->
</P><P>
The <GI>ab</GI> element is also useful for marking dramatic speeches
when it is not clear whether the speech is to be regarded as prose or
verse.  If, for example, an encoder does not wish to express an opinion
as to whether the opening lines of Shakespeare's
<TITLE>The Tempest</TITLE> are to be
regarded as prose or as verse, they might be tagged as follows:
<EG><![CDATA [<div1 type=act n='I'> <div2 type=scene n='1'>
<head rend=italic>Actus primus, Scena prima.</head>
<stage type=setting rend=italic> A tempestuous noise of Thunder and
Lightning heard:  Enter a Ship-master, and a Boteswaine.</stage>
<sp><speaker>Master.</speaker>
<ab>Bote-swaine.</ab></sp>
<sp><speaker>Botes.</speaker>
<ab>Heere Master: What cheere?</ab></sp>
<sp><speaker>Mast.</speaker>
<ab> Good: Speake to th' Mariners: fall too't, yarely, or
we run our selues a ground, bestirre, bestirre.
<stage type=move>Exit.</stage></ab></sp>
<stage type=move>Enter Mariners.</stage>
<sp><speaker>Botes.</speaker>
<ab>Heigh my hearts, cheerely, cheerely my harts:
yare, yare: Take in the toppe-sale: Tend to th' Masters
whistle: Blow till thou burst thy winde, if roome e-nough.</ab></sp>
]]></EG>  See further section  6.11.2, "Core Tags for Drama," on p. 212,
and section 10.2.4, "Speech Contents," on p. 285).</P>

<p>These elements are formally defined as follows:

<eg id=dsasa>
<![ CDATA [
<!-- 14.3:  Blocks, Segments and Anchors                      -->
<!ELEMENT anchor        - O  EMPTY                              >
<!ATTLIST anchor             %a.analysis;
                             %a.linking;
                             %a.terminology;
          lang               IDREF               %INHERITED
          rend               CDATA               #IMPLIED
          n                  CDATA               #IMPLIED
                             %a.typed;
          id                 ID                  #REQUIRED      >
<!ELEMENT seg           - -  (%paraContent)                     >
<!ATTLIST seg                %a.global;
          function           CDATA               #IMPLIED
          type               CDATA               #IMPLIED
          part               (Y | N | I | M | F) N
          subtype            CDATA               #IMPLIED       >
<!ELEMENT ab            - -  (%paraContent)                     >
<!ATTLIST ab                 %a.global;
                             %a.typed;
          part               (Y | N | I | M | F) N              >
<!-- This fragment is used in sec. 14                         -->
]]>
</eg>



<!-- $Id: p2sacs.odd,v 1.10 1998/02/05 17:14:35 tei Exp $ -->
<!--*
    * $Log: p2sacs.odd,v $
    * Revision 1.10  1998/02/05 17:14:35  tei
    * make examples parse
    *
    * Revision 1.9  94/04/08  18:54:36  msmcq
    * Last-second fixes for P3
    *
    * Revision 1.8  1994/04/08  00:00:53  msmcq
    * add figure for Comenius
    *
    * Revision 1.7  1994/03/27  21:47:19  msmcq
    * Correction of typos found by SJ, DB et al.
    *
    * Revision 1.6  1994/03/16  03:29:41  msmcq
    * Changes as per JL, with some LB and TL.
    *
    * Revision 1.5  1994/02/12  10:22:43  lou
    * reviions for P3
    *
    * Revision 1.3  1993/09/16  19:01:31  msmcq
    * Minor SGML cleanup, add RCS log keyword
    * -->
<!-- Revisions:                                               -->
<!-- 94-04-08 : MSM : correct tagging slip in figure element (comenius) -->
<!-- 94-04-07 : MSM : add figure for Comenius                 -->
<!-- 94-03-26 : MSM : typos from HG, DB, SJ                   -->
<!-- 94-03-26 : MSM : disambiguate TERM, Q (> code, ident...) -->
<!-- 4 feb: LB moved anchor out (to sase); revised parallel  -->
<!--    text example considerably -->
<!-- 19 dec 93 : LB change name of classdoc ANA -> cllink -->
<!-- 93-09-15 : MSM : minor SGML cleanup                      -->
<!-- 93-07-21 : DTL : change argTypes= to targFunc= passim    -->
<!--                  remove objection to < xptr> inside      -->
<!--                   < linkGrp>                             -->
<!-- 93-07-13 : DTL : change title to "Correspondence"        -->
<!--                  introduce < anchor> per Eynsham discussion -->
<!--                   to serve as "pure point" tag           -->
<!--                  use corresp= as linking attribute for   -->
<!--                   correspondence                         -->
<!--                  use < link> as linking element for      -->
<!--                   correspondence                         -->
<!--                  create subsection for alignment (SAcsal) -->
<!--                  distinguish correspondence from alignment -->
<!--                   by attribute on < linkGrp>             -->
<!--                  use alignment example from Gale&Church93 -->
<!--                   instead of Biblical passage            -->
<!--                  Comenius example attached to SAcsal     -->
<!--                  < s> changed to < seg>, < corresp> changed  -->
<!--                   to < link> in that example             -->
<!-- 93-01-27 : MSM : omit domains attribute from examples    -->
<!-- 93-01-26 : MSM : changes for publication                 -->
<!-- 92-12-23 : MSM : strip header                            -->
<!-- Date: Wed, 23 Dec 1992 14:24:12 +0000                    -->
<!-- From: Lou Burnard <lou@vax.ox.ac.uk>                     -->
<!-- To: U35395@UICVM.UIC.EDU                                 -->
<!-- Subject: sacs.odd (3 of 9)                               -->
<!-- 22 Dec : added discussion and eg of csp; revised         -->
<!-- John 1.1 example; added Comenius eg                      -->
<!-- 21 Dec 92: change ref to ptr or xptr; align to corresp   -->
<!--            (pro tem)                                     -->
<!-- 15 Dec 92 : LB : very light fiddling with egs; change ids -->
<!-- 24 Jul 92 :  DTL : Add material on < web>, < link>.      -->
<!--                    Elaborate on alternative csp= markup. -->
<!--                    Make other minor changes.             -->
<!-- 21 Jul 92 :  DTL : Make minor corrections.               -->
<!-- 15 Jul 92 :  DTL : Add < analysis> tags.                 -->
<!-- 14 Jul 92 :  DTL : Correct ODD tagging.                  -->
<!-- 03 Jul 92 :  DTL : Make minor changes, add DTDFRAGs.     -->
<!-- 02 Jul 92 :  DTL : Complete first draft, including       -->
<!-- TAGDOCs for < alignGrp> and < align>, and an elaborate   -->
<!-- parallel text example.                                   -->
<!-- Changes from ver 1.14 of LING DTD:  < align.grp>         -->
<!-- becomes < alignGrp>; < align> defined as an empty        -->
<!-- element; corresp= becomes csp=; target= on < align>      -->
<!-- becomes targets=; type= on < align> and < alignGrp>      -->
<!-- becomes how=; domains= added to ATTLIST of < alignGrp>   -->
<!-- defined as IDREFS and optional; =centre and =center on   -->
<!-- how= replaced by =middle; =chunks replaced by =whole.    -->

<div2 id=SAcs><head>Correspondence and Alignment</head>

<p>In this section we introduce the notions of
<term>correspondence</term>, expressed by the <att>corresp</att>
attribute, and of <term>alignment</term>, which is a special kind of
correspondence involving an ordered set of correspondences.  Both cases
may be represented using the <gi>link</gi> and <gi>linkGrp</gi> elements
introduced in section <ptr target=SApt>.  We also discuss the special
case of alignment in time or <term>synchronization</term>, for which
special purpose elements are proposed in section <ptr target=SAsy>.

<div3 id=SAcs1><head>Correspondence</head>

<p>A common problem in text analysis is to determine correspondences
between two or more parts of a single document, or between places in
different documents.  Provided that SGML elements are available to
represent the parts or places to be linked, then the global linking
attribute <att>corresp</att> may be used to encode such correspondence,
once it has been identified.

<list type=gloss>
<label><att>corresp</att></label>
<item>points to elements that correspond to the current element 
in some way.</item>
</list>

This is one of the attributes made available by the mechanism described
in the introduction to this chapter (<ptr target=SA>).  Correspondence
can also be expressed by means of the <gi>link</gi> element introduced
in section <ptr target=SApt>.

<p>Where the correspondence is between <emph>spans</emph>, the
<gi>seg</gi> element should be used, if no other element is available.
Where the correspondence is between <emph>points</emph>, the
<gi>anchor</gi> element should be used, if no other element is
available.

<p>The use of the <att>corresp</att> attribute with spans of content is
illustrated by the following example:

<eg>
<![ CDATA [
<title id=shirley>Shirley</title>, which made
its Friday night debut only a month ago, was
not listed on <name id=nbc>NBC</name>'s new schedule,
although <seg id=network corresp=nbc>the network</seg>
says <seg id=show corresp=shirley>the show</seg>
still is being considered.
]]>
</eg>
<!-- from G Leech. -->
<!-- commas after 'Shirley' and 'ago' added conjecturally by  -->
<!-- msm after consultation with lb.                          -->

Here the anaphoric phrases <mentioned>the network</mentioned> and <mentioned>the
show</mentioned> have been associated directly with the elements to which
they refer by means of <att>corresp</att> attributes.  This mechanism is
simple to apply, but has the drawback that it is not possible to specify
more exactly what kind of correspondence is intended.  Where this
attribute is used, therefore, encoders are encouraged to specify their
intent in the associated encoding declarations in the TEI Header.

<p>Essentially, what the <att>corresp</att> attribute does is to specify
that the element that has the attribute and the element(s) the attribute
points to are doubly linked.  <note place=foot>The <att>corresp</att>
attribute is thus distinct from the <att>target</att> attribute in that
it is understood to create a double, rather than a single, link.  It is
also distinct from the <att>targets</att> attribute in that the latter
lists all the identifiers of the elements that are doubly linked,
whereas the <att>corresp</att> doubly links the element that bears the
attribute with the element(s) that make up the value of the
attribute.</note> Therefore, we can also use the <gi>link</gi> and
<gi>linkGrp</gi> elements defined in section <ptr target=SApt> to
indicate correspondence among elements.  Moreover, the use of these
elements provides a convenient place to indicate what kind of
correspondence is intended as in the following retagging of the
preceding example.

<eg>
<![ CDATA [
<title id=shirley>Shirley</title>, which made
its Friday night debut only a month ago, was not
listed on <name id=nbc>NBC</name>'s new schedule,
although <seg id=network>the network</seg> says
<seg id=show>the show</seg> still is being considered.
<!-- ... -->
<linkGrp type='anaphoric link'
        targFunc='antecedent anaphor' targOrder=Y>
  <link targType='title seg' targets='shirley show'>
  <link targType='name seg' targets='nbc network'>
</linkGrp>
]]>
</eg>

<p>In the following example, we use exactly the same mechanism to
express a correspondence amongst the anchors introduced following the
fifth word after <mentioned>English</mentioned> in a text:

<eg>
<![ CDATA [

English language.  Except for not very<anchor id=eng1>
<!-- ... -->
English at all at the time<anchor id=eng2>
<!-- ... -->
English was still full of flaws<anchor id=eng3>
<!-- ... -->
English.  This was revised by young<anchor id=eng4>

<linkGrp type='five-word collocates'
         targType='anchor anchor'
         targOrder=N>
  <link type='collocates of ENGLISH' targets='eng1 eng2 eng3 eng4'>
  <!-- ... -->
</linkGrp>
]]>
</eg>

<div3 id=SAcsal><head>Alignment of Parallel Texts</head>

<!-- Changes made by LB:                                      -->
<!-- Simplified example by using segs for alignment           -->
<!--   rather than anchors;                                   -->
<!-- corrected erroneous alignment in last eg.                -->
<!-- Removed repetitious examples.                            -->
<!-- Revised introduction slightly.                           -->

<p>One very important application area for the alignment of parallel
texts is multilingual corpora.  Consider, for example, the need to align
<socalled>translation pairs</socalled> of sentences drawn from a corpus
such as the Canadian Hansard, in which each sentence is given in both
English and French.

<!-- William A. Gale and Kenneth W. Church, "Program for      -->
<!-- aligning sentences in bilingual corpora".                -->
<!-- Computational Linguistics 19, 75-102, 1993 (ex appears   -->
<!-- on p76, from Canadian Hansards)                          -->

Concerning this problem, Gale and Church write:<note>See
<bibl><author>William A. Gale and Kenneth W. Church</author>,
<title>Program for aligning sentences in bilingual corpora</title>,
<title>Computational Linguistics</title> 19 (1993):  75-102</bibl>,
from which the example in the text is taken.</note>

<q rend=display>Most English sentences match exactly one
French sentence, but it is possible for an English sentence
to match two or more French sentences.  The first two
English sentences [in the example below] illustrate a
particularly hard case where two English sentences align to
two French sentences.  No smaller alignments are possible
because the clause <q>...sales...were higher...</q> in the
first English sentence corresponds to (part of) the second
French sentence.  The next two alignments ... illustrate the
more typical case where one English sentence aligns with
exactly one French sentence.  The final alignment matches
two English sentences to a single French sentence.  These
alignments [which were produced by a computer program]
agreed with the results produced by a human judge.</q>

<p>The alignment produced by Gale and Church's program can be expressed
in four different ways.  The encoder must first decide whether to
represent the alignment in terms of points within each text (using the
<gi>anchor</gi> element) or in terms of whole stretches of text, using
the <gi>seg</gi> element.  To some extent the choice will depend on the
process by which the software works out where alignment occurs, and the
intention of the encoder.  Secondly, the encoder may elect to represent
the actual encoding using either <att>corresp</att> attributes attached
to the individual <gi>anchor</gi> or <gi>seg</gi> elements, or using a
free standing <gi>linkGrp</gi> element.

<p>We present first a solution using <gi>anchor</gi> elements bearing
only <att>corresp</att> attributes:

<eg><![ CDATA [
<text><body>
<div1 id=E lang=EN>
<p><anchor id=EA1 corresp=FA1>According to our survey, 1988
sales of mineral water and soft drinks were much higher than
in 1987, reflecting the growing popularity of these
products.  Cola drink manufacturers in particular achieved
above-average growth rates.  <anchor id=EA2 corresp=FA2>The
higher turnover was largely due to an increase in the sales
volume.  <anchor id=EA3 corresp=FA3>Employment and
investment levels also climbed.  <anchor id=EA4
corresp=FA4>Following a two-year transitional period, the
new Foodstuffs Ordinance for Mineral Water came into effect
on April 1, 1988.  Specifically, it contains more stringent
requirements regarding quality consistency and purity
guarantees.  </div1>
<!-- ... -->
<div1 id=F lang=FR>
<p><anchor id=FA1 corresp=EA1>Quant aux eaux min&eacute;rales
et aux limonades, elles rencontrent toujours plus
d'adeptes.  En effet, notre sondage fait ressortir des
ventes nettement sup&eacute;rieures &agrave; celles de 1987,
pour les boissons &agrave; base de cola notamment.  <anchor
id=FA2 corresp=EA2>La progression des chiffres d'affaires
r&eacute;sulte en grande partie de l'accroissement du volume
des ventes.  <anchor id=FA3 corresp=EA3>L'emploi et les
investissements ont &eacute;galement augment&eacute;.
<anchor id=FA4 corresp=EA4>La nouvelle ordonnance
f&eacute;d&eacute;rale sur les denr&eacute;es alimentaires
concernant entre autres les eaux min&eacute;rales,
entr&eacute;e en vigueur le 1er avril 1988 apr&egrave;s une
p&eacute;riode transitoire de deux ans, exige surtout une
plus grande constance dans la qualit&eacute; et une garantie
de la puret&eacute;.  </div1></body></text>
]]>
</eg>

<p>There is no requirement that the <att>corresp</att> attribute be
specified in both English and French texts, since (as noted above) this
attribute is defined as representing a mutual association.  However, it
may simplify processing to do so, and also avoids giving the impression
that the English is translating the French, or vice versa.  More
seriously, this encoding does not make explicit the fact that it is in
fact the entire stretch of text between the anchors which is being
aligned, not simply the points themselves.  If for example one text
contained material omitted from the other, this approach would not be
appropriate.

<p>We now present the same passage using the alternative
<gi>linkGrp</gi> mechanism and marking explicitly the segments which
have been aligned:

<eg><![ CDATA [
<div1 id=E lang=EN>
<p><seg id=E1>According to our survey, 1988 sales of mineral
water and soft drinks were much higher than in 1987,
reflecting the growing popularity of these products.  Cola
drink manufacturers in particular achieved above-average
growth rates.</seg>
<seg id=E2>The higher turnover was largely due to an
increase in the sales volume.</seg>
<seg id=E3>Employment and investment levels also
climbed.</seg>
<seg id=E4>Following a two-year transitional period, the new
Foodstuffs Ordinance for Mineral Water came into effect on
April 1, 1988.  Specifically, it contains more stringent
requirements regarding quality consistency and purity
guarantees.</seg>
</div1>
<!-- ... -->
<div1 id=F lang=FR>
<p><seg id=F1>Quant aux eaux min&eacute;rales et aux limonades,
elles rencontrent toujours plus d'adeptes.  En effet, notre
sondage fait ressortir des ventes nettement
sup&eacute;rieures &agrave; celles de 1987, pour les
boissons &agrave; base de cola notamment.</seg>
<seg id=F2>La progression des chiffres d'affaires
r&eacute;sulte en grande partie de l'accroissement du volume
des ventes.</seg>
<seg id=F3>L'emploi et les investissements ont
&eacute;galement augment&eacute;.</seg>
<seg id=F4>La nouvelle ordonnance f&eacute;d&eacute;rale sur
les denr&eacute;es alimentaires concernant entre autres les
eaux min&eacute;rales, entr&eacute;e en vigueur le 1er avril
1988 apr&egrave;s une p&eacute;riode transitoire de deux
ans, exige surtout une plus grande constance dans la
qualit&eacute; et une garantie de la puret&eacute;.</seg>
</div1>
<!-- ... -->
<linkGrp type=alignment
         domains='E F'
  <link targets='E1 F1'>
  <link targets='E2 F2'>
  <link targets='E3 F3'>
  <link targets='E4 F4'>
</linkGrp>
]]>
</eg>

<p>Note that use of the <gi>ab</gi> element allows us to mark up the
orthographic sentences in both languages independently of the alignment:
the first translation pair in this example might be marked up as
follows:

<eg><![ CDATA [
<div1 id=E lang=EN>
<ab id=E1>
  <s>According to our survey, 1988 sales of mineral water and soft
  drinks were much higher than in 1987, reflecting the growing popularity
   of these products.</s>
  <s>Cola drink manufacturers in particular achieved above-average
   growth rates.</s>
</ab>

<!-- ... -->

<div1 id=F lang=FR>
<ab id=F1>
  <s id=fs1>Quant aux eaux min&eacute;rales et aux limonades, elles
   rencontrent toujours plus d'adeptes.</s>
  <s id=fs2>En effet, notre sondage fait ressortir des ventes nettement
   sup&eacute;rieures &agrave; celles de 1987, pour les boissons &agrave;
   base de cola notamment. </s>
</ab>

]]>
</eg>

<!-- Continuing previous subsection, rather than introducing new one -->
<!-- <div3 id=SAcsxa><head>Alignment Using External Pointers</head> -->

<div3 id=SAcsxa><head>A Three-way Alignment</head>

<p>The preceding encoding of the alignment of parallel passages from two
texts requires that those texts and the alignment all be part of the
same SGML document.  If the texts are in separate documents, then
additional <gi>xptr</gi> elements must be supplied, as discussed in
section <ptr target=SAxr>.  These external pointers may appear anywhere
within the document, but if they are created solely for use in encoding
links, they may for convenience be grouped within the <gi>linkGrp</gi>
(or other grouping element that uses them for linking).

<p>To demonstrate this facility, we consider how we might encode the
alignments in an extract from Comenius' <title>Orbis Sensualium
Pictus</title>.
<figure id='Comenius' rend='float full page'>
<figDesc>The figure shows the page from the <title>Orbis pictus</title>
of Comenius which is discussed in the text.</figDesc>
</figure>
Each topic covered in this work has three parts:  a
picture, a prose text in Latin describing the topic, and a
carefully-aligned translation of the Latin into English, German or some
other vernacular.  Key terms in the two texts are typographically
distinct, and are linked to the picture by numbers, which appear in the
two texts and within the picture as well.<note><p>Our example uses the
English translation of Charles Hoole (1659), and is taken from
<bibl><editor>John E. Sadler, ed.</editor>, <title>John Amos
Comenius Orbis Pictus:  a facsimile of the first English edition of
1659</title> (Oxford:  Oxford University Press, 1968) (The Juvenile
Library).</bibl></note>

<p>First, we present the text portions.  The English and Latin portions
have been encoded as distinct <gi>div</gi> elements.  Identifiers have
been attached to each typographic line, but no other encoding added, to
simplify the example.

<!-- S tag changed to SEG -DTL  -->

<eg><![ CDATA [
<!-- English text -->

<div id=E98 lang=EN><head>The Study</head>
<p><seg id=E9801>The Study</seg>
<seg id=E9802>is a place</seg>
<seg id=E9803>where a Student,</seg>
<seg id=E9804>a part from men,</seg>
<seg id=E9805>sitteth alone,</seg>
<seg id=E9806>addicted to his Studies,</seg>
<seg id=E9807>whilst he readeth</seg>
<seg id=E9808>Books,</seg>
<!-- ... -->
</div>

<!-- Latin text -->

<div id=L98 lang=LA><head>Mus&eacute;um</head>
<p><seg id=L9801>Museum</seg>
<seg id=L9802>est locus</seg>
<seg id=L9803>ubi Studiosus,</seg>
<seg id=L9804>secretus ab hominibus,</seg>
<seg id=L9805>solus sedet,</seg>
<seg id=L9806>Studiis deditus,</seg>
<seg id=L9807>dum lectitat</seg>
<seg id=L9808>Libros,</seg>
<!-- ... -->
</div>
]]>
</eg>

<p>Next we assume that we have stored a digitized image of the picture
itself in some external entity we will call <ident type=ge
rend=noindex>com98</ident> (for further discussion of the handling of
external images and graphics, see section <ptr target=FTgra>).  We
further assume that we can address portions of this image as a
two-dimensional co-ordinate space.  The <code type=teikw>SPACE</code>
location method of the <gi>xptr</gi> element (discussed in section <ptr
target=COxr> above) can now be used to point to the whole picture and to
two portions of it, one containing the picture of a student and the
other of a book, as follows:

<eg><![ CDATA[
<xptr n='1' id=p981 doc=com98>
<xptr n='2' id=p982 doc=com98 from='space (2d) (75 5) (133 75)'>
<xptr n='3' id=p983 doc=com98 from='space (2d) (55 42) (90 60)'>
]]>
</eg>
<!-- Redone from                                              -->
<!-- < xptr n='1' id=x981 doc=com98 >                         -->
<!-- < xptr n='2' id=x982 doc=com98 from='space (2d) (9 2) (15 10)' > -->
<!-- < xptr n='3' id=x983 doc=com98 from='space (2d) (8 6) (10 9)'  > -->
<!-- New values are measured in mm on Lou's fax to me.   -->
<!-- Original values don't match proportions of picture. -->

Note that each external pointer has its own unique identifier, in
addition to the <att>n</att> attribute, which last holds the visible
label (or <soCalled>explainer</soCalled>) used for this image portion in
the original.

<p>As printed, the text exhibits three kinds of alignment.

<list type=ordered>

<item n=1>The English and Latin portions are printed in two parallel
columns, with corresponding phrases, (represented above by <gi>seg</gi>
elements), more or less next to each other.

<item n=2>Particular words or phrases are marked as terms in the two
languages by a change of rendition:  the English text, which otherwise
uses black letter type throughout, has the words <mentioned>The
Study</mentioned>, <mentioned>a Student</mentioned>, <mentioned>Studies</mentioned>, and
<mentioned>Books</mentioned> in a roman font; in the Latin text, which is
printed in roman, the corresponding words (<mentioned>Museum</mentioned>,
<mentioned>Studiosus</mentioned>, <mentioned>Studiis</mentioned>, and
<mentioned>Libros</mentioned>) are all in italic.

<item n=3>Numbered labels appear within the text portions, linking
keywords to each other and to sections of the picture.  These labels,
which have been left out of the above encoding, are attached to the
first third and last segment in each language quoted below, and also
appear (rather indistinctly) within the picture itself.  If it is
desired to transcribe them in the text, they might be encoded using as
<gi>ref</gi> elements, <gi>anchor</gi> elements, or <gi>xptr</gi>s to
the picture; the number itself would be transcribed as the value of the
<att>n</att> attribute (or as the content of the <gi>ref</gi>).

</list>

<p>The first kind of alignment might be represented by using the
<att>corresp</att> attribute on the <gi>seg</gi> element.  The second
kind might be represented by using the <gi>gloss</gi> and <gi>term</gi>
mechanism described in section <ptr target=COhqu>.  The third kind of
alignment might be represented using pointers embedded within the texts,
although this would involve some duplication.  We choose however to use
the <gi>link</gi> element, since this provides an efficient way of
representing the three-way alignment between English, Latin and picture
without redundancy.

<eg><![ CDATA [
<linkGrp type=alignment>
  <link targets='E9801 L9801 p981'>
  <link targets='E9802 L9802     '>
  <link targets='E9803 L9803 p982'>
  <link targets='E9804 L9804     '>
  <link targets='E9805 L9805     '>
  <link targets='E9806 L9806     '>
  <link targets='E9807 L9807     '>
  <link targets='E9808 L9808 p983'>
</linkGrp>
]]>
</eg>

<p>This map, of course, only aligns whole segments and image portions,
since these are the only parts of our encoding which bear identifiers
and can therefore be pointed to.  To add to it the alignment between the
typographically distinct words mentioned above, new elements must be
defined, either within the text itself or externally by using the
extended pointer mechanism.  Encoding these word pairs as <gi>term</gi>
and <gi>gloss</gi>, although intuitively obvious, requires a non-trivial
decision as to whether the Latin text is glossing the English, or
vice-versa.  Tagging all the marked words as <gi>term</gi> avoids the
difficult decision, but might be thought by some encoders to convey the
wrong information about the words in question.  Simply tagging them as
additional embedded <gi>seg</gi> elements with identifiers that can be
aligned like the others is also a possibility.  All of these require the
addition of further markup to the text.  This may pose no problems, or
it may be infeasible (e.g. if the text is held on a read-only medium).
If it is not feasible to add more markup to the original text, the
extended pointer mechanism is likely to be the best choice.  For
example, to indicate that the words <mentioned>Studies</mentioned> and
<mentioned>Studiis</mentioned> correspond, two external pointers might be
defined and aligned as follows:

<eg><![ CDATA [
        <xptr id=xt981  from='id (s E9806) token (4)'>
        <xptr id=xt982  from='id (s L9806) token (1)'>
        <link targets='xt981 xt982'>
]]>
</eg>











<!-- $Id: p2sasy.odd,v 1.7 1998/02/05 17:14:35 tei Exp $ -->
<!--*
    * $Log: p2sasy.odd,v $
    * Revision 1.7  1998/02/05 17:14:35  tei
    * make examples parse
    *
    * Revision 1.6  94/03/27  21:47:19  msmcq
    * Correction of typos found by SJ, DB et al.
    *
    * Revision 1.5  1994/03/16  03:29:41  msmcq
    * Changes as per JL, with some LB and TL.
    *
    * Revision 1.4  1994/02/12  10:22:43  lou
    * reviions for P3
    *
    * Revision 1.2  1993/09/16  19:01:31  msmcq
    * Minor SGML cleanup, add RCS log keyword
    * -->
<!-- Revisions:                                               -->
<!-- 94-03-27 : MSM : corrections from SJ                     -->
<!-- 94-03-26 : MSM : disambiguate TERM, Q (> code, ident...) -->
<!-- 7 feb: tidy up bnc example a bit; combine with sasymp   -->
<!-- 19 dec 93 : LB change name of classdoc ANA -> cllink -->
<!-- 93-09-15 : MSM : simple SGML cleanup                     -->
<!-- 93-07-22 : DTL : exceedingly minor changes               -->
<!-- 93-07-21 : DTL : change argTypes= to targFunc= passim    -->
<!--                  supply missing xref to TS chapter       -->
<!-- 93-07-13 : DTL : complete draft, use ex from LB's        -->
<!--                  TEI-TECH posting of a BNC spoken text   -->
<!--            define synch= for temporal correspondence     -->
<!--            use LINK and LINKGRP for temporal alignment   -->
<!--            recast old LOC and ALIGN tags as WHEN and     -->
<!--            WHENGRP tags, but remove pointing ability from -->
<!--            WHEN.  WHEN tags can only be pointed at or    -->
<!--            linked.  Mildly revise attributes from the    -->
<!--            ones given for LOC and ALIGN in TS chapter.   -->
<!--            See TAGDOC for details.                       -->

<div2 id=SAsy><head>Synchronization</head>

<p>In the previous section we discussed two particular kinds of
alignment:  alignment of parallel texts in different languages; and
alignment of texts and portions of an image.  In this section we address
another specialized form of alignment:  synchronization.  The need to
mark the relative positions of text components with respect to time
arises most naturally and frequently in transcribed spoken texts, but it
may arise in any text in which quoted speech occurs, or events are
described within a time frame.  The methods described here are also
generalizable for other kinds of alignment (for example, alignment of
text elements with respect to space), and may thus be regarded as
providing a simplified version of the HyTime system of <term>finite
space co-ordinates</term>.

<div3 id=SAsync><head>Aligning Synchronous Events

<p>To mark synchronous elements, the <att>synch</att> attribute, which
is one of the linking attributes that are available for all text
elements, may be used.

<list type=gloss>
<label><att>synch</att></label>
<item>points to elements that are synchronous with the current 
element.</item>
</list>

Alternatively, the <gi>link</gi> and <gi>linkGrp</gi> elements may be
used to make explicit the fact that the synchronous elements are
aligned.

<p>To illustrate the use of these mechanisms for marking synchrony,
consider the following representation of a spoken text:

<!-- From BNC, via LB, retranscribed without SGML markup -->
<eg><![ CDATA [
B:   The first time in twenty five years, we've cooked Christmas
     (unclear) for a blooming great load of people.
A: So you're [1] (unclear) [2]
B: [1] It will be [2] nice in a way, but, [3] be strange. [4]
A: [3] Yeah [4], yeah, cos it, it's [5] the [6]
B: [5] not [6]
]]> </eg>

<p>This representation uses numbers in brackets to mark the points at
which speakers overlap each other.  For example, the <mentioned>[1]</mentioned>
in A's first speech is to be understood as coinciding with the
<mentioned>[1]</mentioned> in B's second speech.<note>This sample is taken from
a conversation collected and transcribed for the British National
Corpus.</note>

<p>To encode this we use the base tag set for spoken texts, described in
chapter <ptr target=TS>, together with the additional tag set described
in the present chapter.  First, we transcribe this text, marking the
synchronous points with <gi>anchor</gi> elements, and providing a
<att>synch</att> attribute on one of each of the pairs of synchronous
anchors.  As noted in the example given above (section <ptr
target=SAcsal>), correspondence, and hence synchrony, is a symmetric
relation; therefore the attribute need only be specified on one of the
pairs of synchronous anchors.

<eg><![ CDATA [
<text><body>
<div id=d1>
<!-- ... -->
<u id=u3a who=A>So you're <anchor id=t1a synch=t1b><unclear>
          <anchor id=t2a synch=t2b></u>
<u id=u3b who=B> <anchor id=t1b>It will be <anchor id=t2b>
          nice in a way, but, <anchor id=t3b>
          be strange.<anchor id=t4b></u>
<u id=u4a who=A>
          <anchor id=t3a synch=t3b>Yeah
          <anchor id=t4a synch=t4b>, yeah, cos it, its
          <anchor id=t5a synch=t5b>the
          <anchor id=t6a synch=t6b></u>
<u id=u4b who=B>
          <anchor id=t5b>not<anchor id=t6b>
</u>
</body></text>]]>
</eg>

<p>Next, we encode the same example using <gi>link</gi> and
<gi>linkGrp</gi> elements to make the temporal alignment explicit; the
<att>id</att> attributes are provided for the <gi>link</gi> and
<gi>linkGrp</gi> elements for a reason that is given in the next
section, <ptr target=SAsymp>. In this example, a <gi>back</gi>
element has been used to enclose the <gi>linkGrp</gi> element, but the links
may be located anywhere the encoder finds convenient.

<eg><![ CDATA [
<text><body><div id=d1>
<u id=u2b who=B>The first time in twenty five years,
  we've cooked Christmas <unclear> for a blooming great
  load of people.</u>
<u id=u3a who=A>So you're
  <anchor id=t1a><unclear><anchor id=t2a></u>
<u id=u3b who=B>
  <anchor id=t1b>It will be <anchor id=t2b>nice in a way,
  but, <anchor id=t3b>be strange <anchor id=t4b></u>
<u id=u4a who=A>
  <anchor id=t3a>Yeah<anchor id=t4a>, yeah, cos it, it's
<anchor id=t5a>the<anchor id=t6a></u>
<u id=u4b who=B><anchor id=t5b>not<anchor id=t6b></u>
</div>
<!-- ... -->
</body><back>
<linkGrp id=lg1 type='synchronous alignment'
         domains='d1 d1'
         targFunc='speaker.A speaker.B'>
  <link id=l1 targets='t1a t1b'>
  <link id=l2 targets='t2a t2b'>
  <link id=l3 targets='t3a t3b'>
  <link id=l4 targets='t4a t4b'>
  <link id=l5 targets='t5a t5b'>
  <link id=l6 targets='t6a t6b'>
</linkGrp>
</back></text>]]>
</eg>

<p>As with other forms of alignment, synchronization may be expressed
between stretches of speech as well as between points.  When complete
utterances are synchronous, for example, if one person says
<mentioned>What?</mentioned> and another <mentioned>No!</mentioned> at the same time,
that can be represented without <gi>anchor</gi> elements as follows.

<eg><![ CDATA [
<u id=u1 who=A synch=u2>What?</u>
<u id=u2 who=B>No!</u>
]]>
</eg>

<p>A simple way of expressing <term>overlap</term> (where one speaker
starts speaking before another has finished) is thus to use the
<gi>seg</gi> element to encode the overlapping portions of speech.  For
example,

<eg><![ CDATA [
<u who=A> So you're <unclear synch=B1></u>
<u who=B><seg id=B1> It will be </seg> nice in a way, but,
         <seg synch=A3> be strange. </seg></u>
<u who=A><seg id=A3> Yeah </seg>, yeah, cos it,
         its <seg synch=B2> the </seg></u>
<u who=B id=B2> not </u>
]]>
</eg>

Note in this encoding how synchronization has been effected between an
empty <gi>unclear</gi> element and a <gi>seg</gi>, and between an entire
<gi>u</gi> element and another <gi>seg</gi>, using the <att>synch</att>
attribute.  Alternatively, a <gi>linkGrp</gi> could be used in the same
way as above.

<div3 id=SAsymp><head>Placing Synchronous Events in Time</head>

<p>A synchronous alignment specifies which points in a spoken text occur
at the same time, and the order in which they occur, but does not say at
what time those points actually occur.  If that information is available
to the encoder it can be represented by means of the <gi>when</gi> and
<gi>timeline</gi> elements, whose description and attributes are the
following:

<!-- WHEN = old LOC (but made empty, hence stripped of the    -->
<!-- ability to point; these elements only available to be    -->
<!-- pointed at or linked) TIMELINE = old ALIGN               -->

<list type=gloss>
<label><gi>when</gi></label>
<item>indicates a point in time either relative to other elements 
in the
same <gi>timeline</gi> tag, or absolutely.
Attributes include:
<list type=gloss>
<label><att>absolute</att></label>
<item>supplies an absolute value for the time.</item>
<label><att>interval</att></label>
<item>specifies the numeric portion of a time interval</item>
<label><att>unit</att></label>
<item>specifies the unit of time corresponding to the 
<att>interval</att> value.</item>
<label><att>since</att></label>
<item>identifies the reference point for determining the time of 
the current <gi>when</gi> element, which is obtained by 
adding the interval to the time of the reference point.</item>
<label><att>id</att></label>
<item>supplies an identifier, unique to the document, for each 
<gi>when</gi> element.</item>
</list>
</item>
<label><gi>timeline</gi></label>
<item>provides a set of ordered points in time which can be 
linked to
elements of a spoken text to create a temporal 
alignment of that text.
Attributes include:
<list type=gloss>
<label><att>origin</att></label>
<item>designates the origin of the timeline, i.e. the time at 
which it begins.</item>
<label><att>interval</att></label>
<item>specifies the numeric portion of a time interval</item>
<label><att>unit</att></label>
<item>specifies the unit of time corresponding to the 
<att>interval</att> value of the timeline or of its 
constituent points in time.</item>
</list>
</item>
</list>


<p>Each <gi>when</gi> element indicates a point in time, either directly
by means of the <att>absolute</att> attribute, whose value is a string
which specifies a particular time, or indirectly by means of the
<att>since</att> attribute, which points to another <gi>when</gi>.  If
the <att>since</att> is used, then the <att>interval</att> and
<att>unit</att> attributes should also be used to indicate the amount of
time that has elapsed since the time specified by the element pointed to
by the <att>since</att> attribute; the value <code type=val>-1</code>
can be given to indicate that the interval is unknown.

<p>If the <gi>when</gi> elements are uniformly spaced in time, then the
<att>interval</att> and <att>unit</att> values need be given once in the
<gi>timeline</gi>, and not repeated in any of the <gi>when</gi>
elements.  If the intervals vary, but the units are all the same, then
the <att>unit</att> attribute alone can be given in the
<gi>timeline</gi> element, and the <att>interval</att> attribute given
in the <gi>when</gi> element.

<p>The <att>origin</att> attribute in the <gi>timeline</gi> element
points to a <gi>when</gi> element which specifies the reference or
origin for the timings within the <gi>timeline</gi>; this must, of
course, specify its position in time absolutely.

<p>The following <gi>timeline</gi> might be used to accompany the marked
up conversation shown in the preceding section:

<eg><![ CDATA [
<timeline id=tl1 origin=w0 unit=centisecond>
  <when id=w0 absolute='sometime Monday morning before Christmas'
  <when id=w1 since=w0 interval="-1">
  <when id=w2 since=w1 interval="10">
  <when id=w3 since=w2 interval="20">
  <when id=w4 since=w3 interval="15">
  <when id=w5 since=w4 interval="25">
  <when id=w6 since=w5 interval="10">
  </timeline>
]]>
</eg>

The information in this <gi>timeline</gi> could now be linked to the
information in the <gi>linkGrp</gi> which provides the temporal
alignment (synchronization) for the text, as follows:

<eg><![ CDATA [
<linkGrp type='temporal specification'
         targType='link when'
         targFunc='synch.points when'
         domains='lg1 tl1'>
  <link targets='l1 w1'>
  <link targets='l2 w2'>
  <link targets='l3 w3'>
  <link targets='l4 w4'>
  <link targets='l5 w5'>
  <link targets='l6 w6'>
  </linkGrp>
]]>
</eg>

<p>To avoid the need for two distinct link groups (one marking the
synchronization of anchors with each other, and the other marking their
alignment with points on the time line) it would be better to link the
<gi>when</gi> elements with the synchronous points directly:

<eg><![ CDATA [
<linkGrp type='temporal specification'
         targType='anchor anchor when'
         targFunc='speaker.A speaker.B when'
         domains='d1 d1 tl1'>
  <link targets='t1a t1b w1'>
  <link targets='t2a t2b w2'>
  <link targets='t3a t3b w3'>
  <link targets='t4a t4b w4'>
  <link targets='t5a t5b w5'>
  <link targets='t6a t6b w6'>
  </linkGrp>
]]>
</eg>

<p>Finally, suppose that a digitized audio recording is also available.
The extended pointer syntax described in section <ptr target=SAxr>
could be used to address positions on or portions of this recording
directly.  Assuming that <gi>xptr</gi> elements with identifiers <code
type=val>X1</code>, <code type=val>X2</code>, etc., have been defined to
do this, these identifiers could also be included as a fourth component
in each of the above <gi>link</gi> elements, thus providing a
synchronized audio track to complement the transcribed text.

<!-- but this is left to the reader as an exercise because I'm -->
<!-- getting bored with this example -->

<p>For further discussion of this and related aspects of encoding
transcribed speech, refer to chapter <ptr target=TS>.

<!-- The <gi>when</gi> elements can also be pointed at by the -->
<!-- <att>start</att> and <att>end</att> attributes of the <term>timed -->
<!-- elements</term> described in section <ptr target=TSbati>. -->

<p>The <gi>when</gi> and <gi>timeline</gi> elements are defined as
follows:

<eg id=dsasymp>
<![ CDATA [
<!-- 14.5.2:  Temporal specification                          -->
<!ELEMENT when          - O  EMPTY                              >
<!ATTLIST when               %a.analysis;
                             %a.linking;
                             %a.terminology;
          lang               IDREF               %INHERITED
          rend               CDATA               #IMPLIED
          n                  CDATA               #IMPLIED
          absolute           CDATA               #IMPLIED
          interval           CDATA               %INHERITED;
          id                 ID                  #REQUIRED
          since              IDREF               #IMPLIED
          unit               NMTOKEN             %INHERITED;    >
<!ELEMENT timeline      - -  ((when)+)                          >
<!ATTLIST timeline           %a.global;
          interval           NUTOKEN             #IMPLIED
          origin             IDREF               #REQUIRED
          unit               NMTOKEN             #IMPLIED       >
<!-- This fragment is used in sec. 14                         -->
]]>
</eg>


<!-- $Id: p2saie.odd,v 1.6 1998/02/05 17:14:35 tei Exp $ -->
<!--*
    * $Log: p2saie.odd,v $
    * Revision 1.6  1998/02/05 17:14:35  tei
    * make examples parse
    *
    * Revision 1.5  94/03/27  21:47:19  msmcq
    * Correction of typos found by SJ, DB et al.
    *
    * Revision 1.4  1994/03/16  03:29:41  msmcq
    * Changes as per JL, with some LB and TL.
    *
    * Revision 1.3  1994/02/12  10:22:43  lou
    * reviions for P3
    *
    * Revision 1.2  1993/09/16  19:01:31  msmcq
    * Minor SGML cleanup, add RCS log keyword
    * -->
<!-- Revisions:                                               -->
<!-- 94-03-26 : MSM : typos from HG, DB, SJ                   -->
<!-- 94-03-26 : MSM : cosmetics (reformatting, white space)   -->
<!-- 7 feb: LB reinstated, revised                            -->
<!-- 93-09-15 : MSM : process TDL's changes                   -->
<!-- 93-07-08 : DTL : change intro to hide Orwell reference   -->
<!--                  add Gilbert ex                          -->
<!--                  move material on mobile div to SAat     -->
<!-- 93-07-06 : DTL : renumber to SAie; rename section        -->
<!--                  "Identical Elements and Virtual Copies" -->
<!--                  Eliminate < echo> tag. Add copyOf= att  -->
<!--                  change equiv= to sameAs=                -->
<!-- 30 Mar 93 : LB   : renumber to AI                        -->
<!-- 02 Aug 92 : DTL  : Change one cross reference.           -->
<!-- 24 Jul 92 : DTL  : Make minor changes.                   -->
<!-- 21 Jul 92 : DTL  : Add warning about use of < echo>.     -->
<!-- 19 Jul 92 : DTL  : Renumber sectn from p2.446 to p2.444. -->
<!--                    Complete first draft.                 -->
<!-- 16 Jul 92 : DTL  : Create tagList, dtdFrag, and TAGDOC.  -->

<div2 id=SAie><head>Identical Elements and Virtual Copies</head>

<p>This section introduces the notion of a <term>virtual element</term>,
that is, an element which is not explicitly present in a text, but the
presence of which an application can infer from the encoding supplied.
In this section, we are concerned with virtual elements made by simply
cloning existing elements.  In the next section (<ptr target=Saag>), we
discuss virtual elements made by aggregating existing elements.

<p>It is useful to be able to represent the fact that one element of
text is identical to others, for analytical purposes, or (especially if
the elements have lengthy content) to obviate the need to repeat the
content.  For example, consider the repetition of the <tag>date</tag>
element in the following material:

<!-- removed <s> and rend  to simplify;  align date not s -->
<!-- Orwell, Nineteen-Eighty-Four  -->
<!-- diary recoded as Q, per msm   -->
<eg>
<![ CDATA [
<p>In small clumsy letters he wrote:
<q rend='centered italic' id=d1>
<date id=D840404>April 4th, 1984</date>.
</q></p>
<p>He sat back. A sense of complete helplessness had
descended upon him.
<!-- ... -->
<p>His small but childish handwriting straggled up
and down the page, shedding first its capital letters
and finally even its full stops:
<!-- ... -->
<q rend=italic id=d2>
<date>April 4th, 1984</date>. Last night to the flicks.
<!-- ... -->
</q></p>
]]>
</eg>

Suppose now that we wish to encode the fact that the second
<gi>date</gi> element above has identical content to the first.  The
<att>sameAs</att> attribute is provided for this purpose.  Using it, we
can recode the last line of the above example as follows:

<!-- To encode the identity of the content of the S-units -->
<!-- identified as <tag>s id=d1.1</tag> and <tag>s id=d1.2</tag>, -->
<!-- each occurrence of the repeated S-unit may be provided with -->
<!-- an <att>sameAs</att> attribute which points to the other, as -->
<!-- follows. -->

<eg>
<![ CDATA [
<!-- ... -->
<date sameAs=D840404>April 4th, 1984</date>. Last night to the flicks.
<!-- ... -->
]]>
</eg>

<p>The <att>sameAs</att> attribute may be used to document the fact that
two elements have identical content.  It may be regarded as a special
kind of link.  It should only be attached to an element with identical
content to that it indicates, or to one the content of which clearly
designates it as a repetition, such as the word <mentioned>repeat</mentioned> or
<mentioned>bis</mentioned> in the representation of the chorus of a song, the
second time it is to be sung.

<!-- , as in the following example: -->
<!-- example needed, if this is really feasible -->

The relation specified by the <att>sameAs</att> attribute is symmetric:
if a chorus is repeated three times and each repetition bears a
<att>sameAs</att> attribute indicating the first occurrence of the
element concerned, it is implied that each chorus is identical, and
there is no need for the first occurrence to specify any of its copies.

<!-- all but one of -->
<!-- the <att>sameAs</att> attributes can be omitted without loss of -->
<!-- information. -->

<p>The <att>copyOf</att> attribute is used in a similar way to indicate
that the content of the element bearing it is identical to that of
another.  The difference is that the content is not itself repeated.
The effect of this attribute is thus to create a <term>virtual
copy</term> of the element indicated.

<!-- of an element that is an exact repetition of another, the -->
<!-- content of one of those elements can be omitted, and the tag -->
<!-- provided with a <att>copyOf</att> attribute which points to -->
<!-- the element for which the content is provided.  We call the -->
<!-- element bearing the <att>copyOf</att> attribute a -->
<!-- <term>virtual copy</term> of the tag being pointed at. -->

Using this attribute, the repeated date in the first example above could
be recoded as follows:

<eg>
<![ CDATA [
<!-- ... -->
<date copyOf=D840404></date>
]]>
</eg>

<p>An application program should replace whatever is the actual content
of an element bearing a <att>copyOf</att> attribute with the content of
the element specified by it.  If the content of the element specified
includes other elements, these will become embedded within the element
bearing the attribute.  Care must be taken to ensure that the document
is a legal SGML document both before and after this embedding takes
place.  If, for example, the element bearing a <att>copyOf</att>
attribute requires a mandatory sub-component, then this component must
be present (though possibly empty), even though it will be replaced by
the content of the targetted element.

<!-- killed this example. sorry, but it doesnt add anything -->
<!--    and kills trees -->
<!-- Samuel Beckett, Molloy, p125, 241 -->
<!-- The id= values are made up; I do not know the actual     -->
<!-- number of paragraphs and S-units in the second chapter   -->
<!-- of Molloy!  -DTL                                         -->
<!-- <eg> -->
<!-- <![ CDATA [ -->
<!-- <p id=c2p1> -->
<!-- <s id=c2p1s1 sameAs=c2p731s100>It is midnight.</s> -->
<!-- <s id=c2p1s2 sameAs=c2p731s101>The rain is beating on the
windows.</s> -->
<!-- <s id=c2p1s3>I am calm.</s> -->
<!-- ... -->
<!-- <s id=c2p731s99>Then I went back into the house and wrote,</s> -->
<!-- <q type=written who=moran> -->
<!-- <s id=c2p731s100 sameAs=c2p1s1>It is midnight.</s> -->
<!-- <s id=c2p731s101 sameAs=c2p1s2>The rain is beating on the
windows.</s> -->
<!-- </q> -->
<!-- <s id=c2p731s102>It was not midnight.</s> -->
<!-- <s id=c2p731s103>It was not raining.</s> -->
<!--   -->
<!-- <p id=c2p1> -->
<!-- <s id=c2p1s1>It is midnight.</s> -->
<!-- <s id=c2p1s2>The rain is beating on the windows.</s> -->
<!-- <s id=c2p1s3>I am calm.</s> -->
<!-- ... -->
<!-- <s id=c2p731s99>Then I went back into the house and wrote,</s> -->
<!-- <q type=written who=moran> -->
<!-- <s id=c2p731s100 copyOf=c2p1s1></s> -->
<!-- <s id=c2p731s101 copyOf=c2p1s2></s> -->
<!-- </q> -->
<!-- <s id=c2p731s102>It was not midnight.</s> -->
<!-- <s id=c2p71s103>It was not raining.</s> -->
<!-- ]]> -->
<!-- </eg> -->

<p>The following example demonstrates how the <att>copyOf</att>
attribute may be used in conjunction with the <gi>seg</gi> element to
highlight the differences between almost identical repetitions:

<!-- W.S. Gilbert, "A more humane Mikado", The Mikado  -->
<eg>
<![ CDATA [
<sp who=Mikado>
<l>My <seg id=L1s>object all sublime</seg></l>
<l>I shall <seg id=L2s>achieve in time</seg>&dash;</l>
<l id=L3>To let
  <seg id=L3s>the punishment fit the crime</seg>,</l>
<l id=L4><seg copyOf=L3s></seg>;</l>
<l id=L5>And make each pris'ner pent</l>
<l id=L6>Unwillingly represent</l>
<l id=L7>A source
  <seg id=L7s>of innocent merriment</seg>,</l>
<l id=L8><seg copyOf=L7s></seg>!</l>
</sp>
<sp who=chorus>
<l>His <seg copyOf=L1s></seg></l>
<l>He will <seg copyOf=L2s></seg></l>
<l copyOf=L3></l>
<l copyOf=L4></l>
<l copyOf=L5></l>
<l copyOf=L6></l>
<l copyOf=L7></l>
<l copyOf=L8></l>
</sp>
]]>
</eg>

<!-- <p>If a virtual copy has an SGML content model which forbids -->
<!-- it to have empty content, it should be provided with legal -->
<!-- <soCalled>dummy</soCalled> content (e.g., a blank character, -->
<!-- if that is legal).  Application software should be designed -->
<!-- to ignore the content of any tag with a legal -->
<!-- <att>copyOf</att> attribute value, and to assign it the -->
<!-- content of its source. -->

<p>For further examples of the use of this attribute, see chapters <ptr
target=GD> and <ptr target=FS>, where it is used to reduce the
complexity of formal analytic representations of structure.

<!-- $Id: p2saag.odd,v 1.10 1999/05/18 10:30:36 tei Exp $ -->
<!--*
    **
    * $Log: p2saag.odd,v $
    * Revision 1.10  1999/05/18 10:30:36  tei
    * mixed content gotcha in zuigan eg
    *
    * Revision 1.9  1998/02/05 17:14:35  tei
    * make examples parse
    *
    * Revision 1.8  98/02/01  16:52:05  tei
    * change system identifiers to public identifiers
    * fix log keyword
    * normalize SGML
    *
    * Revision 1.7  94/03/27  21:47:19  msmcq
    * Correction of typos found by SJ, DB et al.
    *
    * Revision 1.6  1994/03/16  03:29:41  msmcq
    * Changes as per JL, with some LB and TL.
    *
    * Revision 1.5  1994/02/12  10:22:43  lou
    * reviions for P3
    *
    * Revision 1.3  1993/09/16  19:01:31  msmcq
    * Minor SGML cleanup, add RCS log keyword
    * -->
<!-- Revisions:                                               -->
<!-- 94-03-26 : MSM : typos from HG, DB, SJ                   -->
<!-- 94-03-26 : MSM : disambiguate TERM, Q (> code, ident...) -->
<!-- 94-03-15 : MSM : revision of zuigan as per J Lavagnino   -->
<!-- 5 feb : LB: much tidying up and clarification; took      -->
<!--             attribs and e.g.s from tagdoc.               -->
<!-- 19 dec 93 : LB change name of classdoc ANA -> cllink     -->
<!-- 93-09-15 : MSM : process TDL's revisions                 -->
<!-- 93-07-21 : DTL : change argTypes= to targFunc= passim    -->
<!--                  change certain S to SEG in Orwell ex    -->
<!--                  remove type= from S-units in Fisher,    -->
<!--                      Orwell exx                          -->
<!-- 93-07-12 : DTL : make fixes based on new pointer and     -->
<!--                      grouper class defs                  -->
<!-- 93-07-08 : DTL : retitle "Aggregations"                  -->
<!--                  eliminate link= and partOf=             -->
<!--                  define JOIN as syntactic sugar for      -->
<!--                      LINK type=join                      -->
<!--                  add result= on JOIN                     -->
<!--                  add JOINGRP element                     -->
<!--                  include JOIN, JOINGRP as members of     -->
<!--                      class "pointer"                     -->
<!--                  use Milne ex in COpr                    -->
<!--                  replace with ex from MFK Fisher         -->
<!--                  restore Lessing ex in SAag1 subsection  -->
<!--                  retitle SAag1 "Three Examples"          -->
<!--                  change analysis of Salinger example,    -->
<!--                      per JL (?)                          -->
<!--                  modify S type= values in Orwell example -->
<!-- 93-01-26 : MSM : last chance revisions                   -->
<!-- 93-01-22 : MSM : revise for publication                  -->
<!-- 92-12-23 : MSM : strip header                            -->
<!-- Date: Wed, 23 Dec 1992 14:23:38 +0000                    -->
<!-- From: Lou Burnard <lou@vax.ox.ac.uk>                     -->
<!-- To: U35395@UICVM.UIC.EDU                                 -->
<!-- Subject: saag.odd (2 of 9)                               -->
<!-- 22 dec LB : introduced simple example at start and       -->
<!--             other minor changes for P2 conformity        -->
<!-- 21 dec: LB made from 443.odd                             -->
<!-- 24 Jul 92 : DTL  : Make other minor changes              -->
<!-- 21 Jul 92 : DTL  : Make additional minor changes.        -->
<!-- 18 Jul 92 : DTL  : Change "citn" to "text" in < ref>s    -->
<!-- in last markup of Salinger example.  Remove equiv=       -->
<!-- attribute in Orwell example, so that it can be           -->
<!-- introduced in section p2.444 on virtual copying.         -->
<!-- 15 Jul 92 : DTL  : Change example in TAGDOC for <        -->
<!-- join> to extract from Dillard, Black English used in     -->
<!-- section on < s>.  Add < analysis> tags around < join>s   -->
<!-- and < ref>s.                                             -->
<!-- 14 Jul 92 : DTL  : Correct ODD tagging.  Replace <       -->
<!-- extPtr> with < ref> in last markup of Salinger           -->
<!-- extract, as described in section on hypertext links      -->
<!-- and in my TEI-TECH comment of 14 July on that section    -->
<!-- (suggesting from= instead of target= attribute).         -->
<!-- 01 Jul 92 : DTL  : Include discussion of prev= and       -->
<!-- next=.  Rename section "Virtual Elements"; assign        -->
<!-- section number in accordance with preliminary outline    -->
<!-- of section; add type= to < join> with semantics as       -->
<!-- described in a note to CMSMcQ and LB.                    -->
<!-- 30 Jun 92 : DTL  : Add Lessing example                   -->
<!-- cross-referenced with section on orthographic            -->
<!-- sentences.                                               -->
<!-- 29 Jun 92 : DTL  : Eliminate material on < nonid.ptr>;   -->
<!-- rewrite discussion of indirect pointing.                 -->
<!-- 26 Jun 92 : DTL  : Replace link= by equiv= in Orwell     -->
<!-- example; other minor changes in that example.            -->


<div2 id="SAag"><head>Aggregation</head>

<p>Because of the strict hierarchical organization of an SGML document,
or for other reasons, it may not always be possible or desirable to
include all the parts of a possibly fragmented text segment within a
single element.  In section <ptr target="Saptip"> we introduced the
notion of an intermediate pointer as a way of pointing to discontinuous
segments of this kind.  In this section we first describe another way of
linking the parts of a discontinuous whole, using a set of linking
attributes, which are made available for any tag by following the
procedure described at the beginning of this chapter.

<!-- Using these attributes obviates the need -->
<!-- for introducing <tag>ptr</tag> tags into the text, as was -->
<!-- done in some of the illustrations in section <ptr target=SApt>.-->

We then describe how the <gi>link</gi> element may be used to aggregate
such segments, and finally introduce the <gi>join</gi> element, which is
a special-purpose linking element specifically for representing the
aggregation of parts, and the <gi>joinGrp</gi> for grouping
<tag>join</tag> tags.</p>

<p>The linking attributes for aggregation are <att>next</att> and
<att>prev</att>; each of these attributes has a single identifier as its
value:

<list type=gloss>
<label><att>next</att></label>
<item>points to the next element of a virtual aggregate of which 
the current element is part.</item>
<label><att>prev</att></label>
<item>points to the previous element of a virtual aggregate of 
which the current element is part.</item>
</list>
</p>

<p>The <gi>join</gi> element is also a member of the class of <ident
type="class">pointer</ident> elements, and so may carry any of the
attributes of that class; for the list, see section <ptr
target="SApt">.</p>

<p>Here is the material on which we base our first illustration of the
use of these mechanisms.  Our problem is to represent the S-units
identified below as qs3 and qs4 as a single (but discontinuous) whole:

<eg><![ CDATA [
<q who=waitress><s id=qs2>
  Monsieur Paul, after he has taken equal
  parts of goose breast and the finest pork, and
  broken a certain number of egg yolks into them,
  and ground them <emph>very</emph>, very fine,
  cooks all with seasoning for some three hours.
</s><s id=qs3><emph>But</emph>,</s>
</q>
<s id=ps2>she pushed her face nearer, and looked with
 ferocious gloating at the p&acirc;t&eacute;
 inside me, her eyes like X rays,
</s><q who=waitress><s id=qs4>
  he never stops stirring it!
</s><s id=qs5>Figure to yourself the work of it &mdash;
</s><s id=qs6>stir, stir, never stopping!
</s></q>
]]>
</eg>
<!-- M.F.K. Fisher, I was really very hungry, As They Were, p43  -->
<!-- removed some distracting atts; divided last s-unit at dash (LB)--></p>

<p>Using the <att>prev</att> and <att>next</att> attributes, we can link
the s-units with identifiers <code type="val">s1</code> and <code
type="val">s2</code>, either singly or doubly as follows:

<eg><![ CDATA [
<s id=qs3 next=qs4><emph>But</emph>,</s>
<!-- intervening material -->
<s id=qs4>he never stops stirring it!</s>

<s id=qs3><emph>But</emph>,</s>
<!-- intervening material -->
<s id=qs4 prev=qs3>he never stops stirring it!</s>

<s id=qs3 next=qs4><emph>But</emph>,</s>
<!-- intervening material -->
<s id=qs4 prev=qs3>he never stops stirring it!</s>
]]>
</eg>

Double linking of the two S-units, as illustrated by the last of these
encodings, is equivalent to specifying a <tag>link</tag> tag:

<eg><![ CDATA [
<link type=join targType='s s' targOrder=Y targets='qs3 qs4'>
]]>
</eg></p>

<p>Such a <tag>link</tag> element must carry <att>type=join</att>
attribute value to specify that the link is to be understood as joining
its targets into a single aggregate.</p>

<p>The <gi>join</gi> element is equivalent to a <gi>link</gi> element of
type <code type="val">join</code>; unlike a link, the default value for
the <att>targOrder</att> attribute which this element also inherits from
the pointer class is <code type="val">Y</code>.

<!-- LB added following, possibly contentious, clarification -->

Also unlike the <gi>link</gi> element, the <gi>join</gi> element can
additionally specify information about the virtual element which it
represents, by means of its <att>result</att> attribute.  And finally,
unlike the <gi>link</gi> element, the position of a <gi>join</gi>
element within a text is significant:  it must be supplied at a position
where the element indicated by its <att>result</att> attribute would be
contextually legal.


<!-- and removed following -->
<!--   We now define the following equivalence:<eg>           -->
<!-- <![ CDATA [                                              -->
<!-- <link type=join> = <join>                                -->
<!-- ]]>                                                      -->
<!-- </eg>                                                    -->
<!--                                                          -->
<!-- <p>By using the <gi>join</gi> tag for representing       -->
<!-- element aggregation, another attribute is made           -->
<!-- available to indicate the nature of the                  -->
<!-- <term>result</term> of the joining operation.            -->
<!-- Moreover, we specify the default value for the           -->
<!-- <att>targOrder</att> attribute to be <term>Y</term>.     -->


<list type=gloss>
<label><gi>join</gi></label>
<item>identifies a possibly fragmented segment of text, by 
pointing
at the possibly discontiguous elements which 
compose it.
Attributes include:
<list type=gloss>
<label><att>result</att></label>
<item>specifies the name of an element which this aggregation may 
be understood to represent.</item>
<label><att>targets</att></label>
<item>specifies the SGML identifiers of the elements or passages 
to be joined into a virtual element.</item>
<label><att>targOrder</att></label>
<item>specifies whether or not the order in which components of 
the join are listed on the <att>targets</att> attribute is 
significant.
Legal values are:
<list type=gloss>
<label><term>U</term></label>
<item>Unspecified: the order may or may not be significant.</item>
<label><term>Y</term></label>
<item>Yes: the order should be followed when combining the 
targeted elements.</item>
<label><term>N</term></label>
<item>No: the order has no significance when combining the 
targeted elements.</item>
</list></item>
</list>
</item>
<label><gi>joinGrp</gi></label>
<item>groups a collection of <gi>join</gi> elements and possibly

pointers.
Attributes include:
<list type=gloss>
<label><att>result</att></label>
<item>describes the result of the joins gathered in this 
collection.</item>
</list>
</item>
</list>


To conclude the above example, we now use a <gi>join</gi> element to
represent the virtual sentence formed by the aggregation of <code
type="val">s1</code> and <code type="val">s2</code>:

<eg>
<![ CDATA [
<join result=s targets='qs3 qs4' >
]]>
</eg>

As a further example, consider the following list of authors' names.
The object of the <gi>join</gi> element here is to provide another list,
composed of those authors from the larger list who happen to come from
Heidelberg:

<eg><![ CDATA [
 <list><head>Authors</head>
   <item id=uf>Figge, Udo
   <item id=ch>Heibach, Christiane
   <item id=gh>Heyer, Gerhard
   <item id=bp>Philipp, Bettina
   <item id=ms>Samiec, Monika
   <item id=ss>Schierholz, Stefan
 </list>

<join result=list targets='ch bp ss' >

]]>
</eg></p>

<p>The following example shows how <gi>join</gi> can be used to
reconstruct a text cited in fragments presented out of order.  The poem
being remembered (an unusual translation of a well known poem by Basho)
runs <q>When the old pond / gets a new frog, / it's a new pond.</q> </p>

<eg>
<![ CDATA [
 <sp who='Hughie'><p>How does it go?
   <q><l id=X1>da-da-da
      <l id=L2>gets a new frog
      <l>...
   </q></p>
 <sp who='Louie'><p><q><l id=L1>When the old pond</l> ...</q></p>
 <sp who='Dewey'><p>... <q><l id=L3>It's a new pond.</l></q></p>
 <!-- ... -->
 <join result=lg targets='L1 L2 L3' >
]]>
</eg>
<!-- Basho translation from memory, Hughie, Louie, and Dewey  -->
<!-- sequence and imaginary example.                          -->

<p>As with other forms of link, a grouping element <tag>joinGrp</tag> is
available for use when a number of <tag>join</tag> elements of the same
kind co-occur.  This avoids the need to specify the <att>result</att>
attribute for each <gi>join</gi> if they are all of the same type, and
also allows us to restrict the domain within which their target elements
are to be found, in the same way as for <gi>linkGrp</gi> elements (see
<ptr target="SAptlg">).  Like a <gi>join</gi>, a <gi>joinGrp</gi> may
appear only where the elements represented by its contents are legal.

<!-- attributes.  Moreover, we specify the default value for the -->
<!-- <att>targFunc</att> attribute to be <term>'first.part -->
<!-- next.part'</term>.  -->
<!-- Not much use if we are joining three things then is it? (LB) -->

Thus if we had created many <tag>join</tag> tags of the sort just
described, we could group them together, and require that their
components are all contained by an element with the identifier <code
type="val">MFKFhungry</code> as follows:

<eg><![ CDATA [
<joinGrp result=s
         targType=s
         domains=MFKFhungry>
<!-- ... -->
  <join targets='qs3 qs4'>
  <join targets='qs5 qs6'>
  </joinGrp>
<!-- ... -->
]]>
</eg>

<!-- If <tag>join</tag> tags appear with more than two targets, -->
<!-- when we would also specify the <att>extendTarg=2</att> -->
<!-- attribute value in the <tag>joinGrp</tag> tag. -->


<!-- <div3 id=SAag1><head>Three More Illustrations</head> --></p>

<p>The <gi>join</gi> element is useful as a means of representing
non-hierarchic structures (as further discussed in chapter <ptr
target="NH">).  It may also be used as a convenient way of representing a
variety of analytic units, like the <gi>span</gi> and <gi>interp</gi>
elements discussed in chapter <ptr target="AI">.  As an example, consider
the following passage:

<q rend="display"><p>
Zui-Gan called out to himself every day, <q>Master.</q>
</p><p>Then he answered himself, <q>Yes, sir.</q>
</p><p>And then he added, <q>Become sober.</q>
</p><p>Again he answered, <q>Yes, sir.</q>
</p><p><q>And after that,</q> he continued,
<q>do not be deceived by others.</q>
</p><p><q>Yes, sir; yes, sir,</q> he replied.
</p></q>

<!-- J.D. Salinger, Franny and Zooey p179, 1964 Bantam ed --></p>

<p>Suppose now that we wish to represent an interpretation of the above
passage in which we distinguish between the various
<socalled>voices</socalled> adopted by the character Zui-Gan.  In the
following encoding, the <att>who</att> attribute has been used for this
purpose; <att>id</att> attributes have also been added:

<eg>
<![ CDATA [
<text id=zuitxt>
<body>
<p>Zui-Gan called out to himself every day,
<q id=zuiq1 who=zuigan>Master.</q></p>
<p>Then he answered himself,
<q id=zuiq2 who=zuigan>Yes, sir.</q></p>
<p>And then he added,
<q id=zuiq3 who=master>Become sober.</q></p>
<p>Again he answered,
<q id=zuiq4 who=zuigan>Yes, sir.</q>
<p><q id=zuiq5 who=master>And after that,</q>
he continued,
<q id=zuiq6 who=master>do not be deceived by others.</q>
<p><q id=zuiq7 who=zuigan>Yes, sir; yes, sir,</q>
he replied.</p>
</body>
</text>
]]>
</eg></p>

<p>The <att>id</att> values specified now allow us to link the material
spoken by each voice:

<eg>
<![ CDATA [
<text id=zuitxt>
<body>
<p>Zui-Gan called out to himself every day,
<q id=zuiq1 who=zuigan next=zuiq2>Master.</q></p>
<p>Then he answered himself,
<q id=zuiq2 who=zuigan next=zuiq4>Yes, sir.</q></p>
<p>And then he added,
<q id=zuiq3 who=master next=zuiq5>Become sober.</q></p>
<p>Again he answered,
<q id=zuiq4 who=zuigan next=zuiq7>Yes, sir.</q>
<p><q id=zuiq5 who=master next=zuiq6>And after that,</q>
he continued,
<q id=zuiq6 who=master>do not be deceived by others.</q>
<p><q id=zuiq7 who=zuigan>Yes, sir; yes, sir,</q>
he replied.</p>
</body>
</text>
]]>
</eg></p>

<p>However, by using the <gi>join</gi> element, we can directly
represent the complete speech attributed to each voice:

<eg>
<![ CDATA [
<joinGrp targType='q' domains='zuitxt' result='q'>
  <join desc="what Zui-Gan said" targets='zuiq1 zuiq2 zuiq4 zuiq7'>
  <join desc="what Master said"  targets='zuiq3 zuiq5 zuiq6'>
  </joinGrp>
]]>
</eg></p>

<p>Note the use of the global <att>n</att> attribute to supply a
descriptive name to distinguish the two virtual <gi>q</gi> elements
represented by the <gi>join</gi> elements; this is necessary because the
current proposals do not allow for any way of specifying the attributes
to be associated with a virtual element, and hence we cannot specify a
<att>who</att> value for them.</p>

<p>Suppose now that <att>id</att> attributes, for whatever reasons, are
not available.  Then <gi>xptr</gi> elements may be created using any of
the methods described in section <ptr target="SAxr" type="div2">.  The
<att>id</att> attributes of <emph>these</emph> elements may now be
specified by the <att>targets</att> attribute on the <gi>join</gi>
elements.

<!-- comment on need for <att>evaluate=Y<att> ?  -->

<eg>
<![ CDATA [
<text><body>
<!-- ... -->
<!-- We are in the second DIV0, the sixth DIV1 ... -->
<p>Zui-Gan called out to himself every day,
   <q>Master.</q></p>
<p>Then he answered himself, <q>Yes, sir.</q></p>
<p>And then he added, <q>Become sober.</q></p>
<p>Again he answered, <q>Yes, sir.</q>
<p><q>And after that,</q> he continued,
<q>do not be deceived by others.</q></p>
<p><q>Yes, sir; yes, sir,</q> he replied.</p>
<!-- ... -->
</body></text>

<!-- ... -->

<xptr id=rzuiq1 from='DESCENDANT (2 div0) (6 div1) (1 p) (1 q)'>
<xptr id=rzuiq2 from='DESCENDANT (2 div0) (6 div1) (2 p) (1 q)'>
<xptr id=rzuiq3 from='DESCENDANT (2 div0) (6 div1) (3 p) (1 q)'>
<xptr id=rzuiq4 from='DESCENDANT (2 div0) (6 div1) (4 p) (1 q)'>
<xptr id=rzuiq5 from='DESCENDANT (2 div0) (6 div1) (5 p) (1 q)'>
<xptr id=rzuiq6 from='DESCENDANT (2 div0) (6 div1) (5 p) (2 q)'>
<xptr id=rzuiq7 from='DESCENDANT (2 div0) (6 div1) (6 p) (1 q)'>

<!-- ... -->

<joinGrp targType='xptr' result='q' evaluate=one>
  <join desc="what Zui-Gan said" targets='rzuiq1 rzuiq2 rzuiq4 rzuiq7'>
  <join desc="what Master said"  targets='rzuiq3 rzuiq5 rzuiq6'>
</joinGrp>

]]>
</eg></p>

<p>For a definition of the syntax used by the <gi>xptr</gi> element, see
section <ptr target="SAxrs"> above.  The extended pointer with identifier
<code type="val">rzuiq2</code> (for example) may be read as <q>the first
<gi>q</gi> in the first <gi>p</gi>, inside the sixth <gi>div1</gi>
within the second <gi>div0</gi> element of the current document.</q></p>

<p>As mentioned above, there is no need for the <gi>join</gi> and
<gi>xptr</gi> elements to be held in the same SGML document as the text;
indeed, if, for example, the text is held on a read-only medium, this
may not be possible.  The <att>doc</att> attribute of the <gi>xptr</gi>
element may be used to specify the name of the SGML entity within which
its target is to be found.

<eg>
<![ CDATA [
<!-- ... -->
<!ENTITY fazdoc SYSTEM 'C:\faz.doc'>
<!-- ... -->
<xptr id=rzuiq1
      doc=fazdoc
      from='DESCENDANT (2 div0) (6 div1) (1 p) (1 q)'>
<!-- ... -->
]]>
</eg>

<!-- deleted following example. nice though it is, it's too long -->
<!-- and adds nothing to preceding ones  -->

<!-- <p>The second example is a possible reconstruction of    -->
<!-- the fragment of the diary that the main character has    -->
<!-- been keeping throughout the first chapter of a           -->
<!-- well-known twentieth-century novel.                      -->

<!-- George Orwell, Nineteen-Eighty-Four, 1947 -->
<!-- empty head elements deleted, will be restored on demand. -->
<!-- diary excerpts retagged as Q not P (discussable).        -->
<!--  -msm -->
<!-- OK to both -dtl (93-07-08) -->
<!-- <eg> -->
<!-- <![ CDATA [ -->
<!-- <div1 id=c1><head rend='large caps centered'>one</head> -->
<!-- <div2 id=c1s1> -->
<!-- <p> -->
<!-- <s>It was a bright cold day in April, and the clocks were striking -->
<!-- thirteen.</s> -->
<!-- ... -->
<!-- <s>In small clumsy letters he wrote:</s> -->
<!-- <q rend='centered italic' id=d1> -->
<!-- <date id=d1.1 copyOf=d2.1></date> -->
<!-- </q> -->
<!-- <p><s>He sat back.</s> -->
<!-- <s>A sense of complete helplessness had descended upon him.</s> -->
<!-- ... -->
<!-- <p> -->
<!-- <s>Suddenly he began writing in sheer panic, only imperfectly -->
<!-- aware of what he was setting down.</s> -->
<!-- <s>His small but childish handwriting straggled up and down the page, -->
<!-- shedding first its capital letters and finally even its full -->
<!-- stops:</s> -->
<!-- <q rend=italic id=d2> -->
<!-- <date id=d2.1>April 4th, 1984.</date> -->
<!-- <s id=d2.2>Last night to the flicks.</s> -->
<!-- ... -->
<!-- <seg type=sentence id=d2.11.1>then there was a wonderful shot of -->
<!-- a childs arm going up up up right up into the air</seg> -->
<!-- ... -->
<!-- <seg type=phrase id=d2.11.9>typical prole reaction</seg> -->
<!-- <seg type=fragment id=d2.11.10>they never&mdash;</seg> -->
<!-- </q> -->
<!-- <p> -->
<!-- <s>Winston stopped writing, partly because he was suffering from -->
<!-- cramp.</s> -->
<!-- ... -->
<!-- <p><s>For a moment he was seized by a kind of hysteria.</s> -->
<!-- <s>He began writing in a hurried untidy scrawl:</s> -->
<!-- <q rend=italic id=d3> -->
<!-- <seg type=sentence id=d3.1>theyll shoot me</seg> -->
<!-- <seg type=sentence id=d3.2>i dont care</seg> -->
<!-- <seg type=sentence id=d3.3>theyll shoot me in the back of the neck</seg> -->
<!-- <seg type=sentence id=d3.4>i dont care </seg> -->
<!-- <seg type=phrase id=d3.5>down with big brother</seg> -->
<!-- <seg type=sentence id=d3.6>they always shoot you in the back of the -->
<!-- neck</seg> -->
<!-- <seg type=sentence id=d3.7>i dont care</seg> -->
<!-- <seg type=phrase id=d3.8>down with big brother&mdash;</seg> -->
<!-- </q> -->
<!-- <p> -->
<!-- <s>He sat back in his chair, slightly ashamed of himself, and -->
<!-- laid down the pen.</s> -->
<!-- ... -->
<!-- <s>With the feeling that he was speaking to O'Brien, and also -->
<!-- that he was setting forth an important axiom, he wrote:</s> -->
<!-- <q rend=italic id=d15> -->
<!-- <s id=d15.1>Freedom is the freedom to say that two plus two make -->
<!-- four.</s> -->
<!-- <s id=d15.2>If that is granted, all else follows.</s> -->
<!-- </q> -->
<!-- <div2 id=c1s8><head rend='large caps centered'>viii -->
<!-- ... -->
<!-- <div1 id=c2><head rend='large caps centered'>two</head> -->
<!-- ... -->
<!-- <joinGrp targType='q q' -->
<!--          domains='c1 c1' -->
<!--          extendTarg=2> -->
<!--   <join  result="Winston Smith's diary" -->
<!--          targets='d2 d3 d4 d5 d6 d7 d8 d9 d10 d11 d12 d13 d14 d15'> -->
<!--   </joinGrp> -->
<!-- ]]> -->
<!-- </eg> -->
<!--   -->

<!-- Also dropped this example because I dont understand it.  -->
<!-- There's no relevant discussion at end of COse any more   -->
<!-- either                                                   -->
<!-- Well, if you wouldn't axe things quite so liberally,     -->
<!-- you wouldn't find yourself left with no explanations of  -->
<!-- things, would you?                                       -->

<!-- <p>Finally, here is a solution to the markup problem     -->
<!-- discussed at the end of section <ptr type=div3          -->
<!-- target=COse>, concerning a quotation that is shared      -->
<!-- between two identification ments.                        -->

<!-- Doris Lessing, The Four-Gated City, 1976, p257  -->
<!-- <eg><![ CDATA [ -->
<!-- <s id=s89235>Martha said, -->
<!-- <q id=q89240><s id=s89240>Mark.</s> -->
<!-- <s id=s89245>He's my employer, after all.</s></q></s> -->
<!-- <s id=s89250<q id=q89250><s id=s89255>I suppose,</s></q> she -->
<!-- added, with a sort of desperation of her own which at least -->
<!-- hinted at the possibility of a return of the dry, cool, -->
<!-- irony where Mrs. Quest had never thought she might be able -->
<!-- to meet her daughter.</s> -->
<!-- <join rend='PRE ldquo POST rdquo' -->
<!--       result='full quote' -->
<!--       targType='q q' -->
<!--       targets='q89240 q89250'> -->
<!-- ]]> -->
<!-- </eg> --></p>


<p>Here are the formal declarations of the <gi>join</gi> and
<gi>joinGrp</gi> elements.

<eg id=dsaag>
<![ CDATA [
<!-- 14.7:  Aggregation                                       -->
<!ELEMENT join          - O  EMPTY                              >
<!ATTLIST join               %a.global;
          crdate             CDATA               #IMPLIED
          evaluate           (all | one | none)  #IMPLIED
          resp               CDATA               #IMPLIED
          type               CDATA               #IMPLIED
          targType           NAMES               #IMPLIED
          targets            IDREFS              #REQUIRED
          scope              (root | branches)   root
          desc               CDATA               %INHERITED
          result             NAME                %INHERITED
          targOrder          (Y | N | U)         Y              >
<!ELEMENT joinGrp       - -  ((join | ptr | xptr)*)             >
<!ATTLIST joinGrp            %a.global;
                             %a.pointerGroup;
          desc               CDATA               #IMPLIED
          result             CDATA               #IMPLIED       >
<!-- This fragment is used in sec. 14                         -->
]]>
</eg>

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

<!-- $Id: p2saat.odd,v 1.6 1998/02/05 17:14:35 tei Exp $ -->
<!--*
    * $Log: p2saat.odd,v $
    * Revision 1.6  1998/02/05 17:14:35  tei
    * make examples parse
    *
    * Revision 1.5  94/03/27  21:47:19  msmcq
    * Correction of typos found by SJ, DB et al.
    *
    * Revision 1.4  1994/03/16  03:29:41  msmcq
    * Changes as per JL, with some LB and TL.
    *
    * Revision 1.3  1994/02/12  10:22:43  lou
    * reviions for P3
    *
    * Revision 1.2  1993/09/16  19:01:31  msmcq
    * Minor SGML cleanup, add RCS log keyword
    * -->
<!-- Revisions:                                               -->
<!-- 94-03-26 : MSM : typos from HG, DB, SJ                   -->
<!-- 94-03-26 : MSM : disambiguate TERM, Q (> code, ident...) -->
<!-- 94-03-15 : MSM : clean up garbage data                   -->
<!-- 7 feb: LB: sorry, no time to give this the full once-over; -->
<!-- just deleted refs to copyOf and did some perfunctory tidying. -->
<!-- I still think it should be axed for now. -->
<!-- Also had to change attrib names on alt and altGrp to get dtd -->
<!-- to compile: perc -> wScale, excl->mode               -->
<!-- 19 dec 93 : LB change name of classdoc ANA -> cllink -->
<!-- 93-09-15 : MSM : correct typo (SGML detected)            -->
<!-- 93-07-22 : DTL : correct typos                           -->
<!--                  remove percent= from ALTgRP tag         -->
<!-- 93-07-21 : DTL : change argTypes= to targFunc=           -->
<!-- 93-07-12 : DTL : complete draft, fix to conform with new -->
<!--                  tag class definitions                   -->
<!-- 93-07-08 : DTL : start draft                             -->
<!--                  revise material from SAie on movable div2 -->
<!--                  revise "Bloody Mary" TEI-TECH posting,  -->
<!--                  using inclusive alternation, and eliminating -->
<!--                  need for JOIN tags                      -->

<div2 id=SAat><head>Alternation</head>

<p>This section proposes elements for the representation of alternation.
We say that two or more elements are in <term>exclusive
alternation</term> if any of those elements could be present in a text,
but one and only one of them is; in addition, we say that those elements
are <term>mutually exclusive</term>.  We say that the elements are in
<term>inclusive alternation</term> if at least one (and possibly more)
of them is present.  The elements that are in alternation may also be
called <term>alternants</term>.

<p>The need to mark exclusive alternation arises frequently in text
encoding.  A common situation is one in which it can determined that
exactly one of several different words appears in a given location, but
it cannot be determined which one.  One way to mark such an exclusive
alternation is to use the linking attribute <att>exclude</att>.  Having
marked an exclusive alternation, it can sometimes later be determined
which of the alternants actually appears in the given location.  To
preserve the fact that an alternation was posited, one can add the
linking attribute <att>select</att> to a tag which hierarchically
encompasses the alternants, which points to the one which actually
appears.  To assign responsibility and degree of certainty to the
choice, one can use the <gi>certainty</gi> tag described in chapter
<ptr target=CE>.  Also see that chapter for further discussion of
certainty in general.

<p>The <att>exclude</att> and <att>select</att> attributes may be used
with any element assuming that they have been declared following the
procedure discussed in the introduction to this chapter.

<list type=gloss>
<label><att>exclude</att></label>
<item>points to elements that are in exclusive alternation with 
the current element.</item>
<label><att>select</att></label>
<item>selects one or more alternants; if one alternant is 
selected, the ambiguity or uncertainty is marked as 
resolved. If more than one alternant is selected, the 
degree of ambiguity or uncertainty is marked as reduced by 
the number of alternants not selected.</item>
</list>

<p>A more general way to mark alternation, encompassing both exclusive
and inclusive alternation, is to use the linking element <gi>alt</gi>.
The description and attributes of this tag and of the associated
grouping tag <gi>altGrp</gi> are as follows.  These elements are also
members of the <ident type=class>pointer</ident> class and therefore
have all the attributes associated with that class.

<!-- except that targFunc and targOrder are pretty meaningless -->

<list type=gloss>
<label><gi>alt</gi></label>
<item>identifies an alternation or a set of choices among 
elements or
passages.
Attributes include:
<list type=gloss>
<label><att>targets</att></label>
<item>specifies the SGML identifiers of the alternative elements 
or passages.</item>
<label><att>weights</att></label>
<item>If <att>mode=excl</att>, each weight states the probability 
that the corresponding alternative occurs. If 
<att>mode=incl</att> each weight states the probability 
that the corresponding alternative occurs given that at 
least one of the other alternatives occurs.</item>
</list>
</item>
<label><gi>altGrp</gi></label>
<item>groups a collection of <gi>alt</gi> elements and possibly

pointers.</item>
</list>


<!-- suppressed ref to mode, and wscale, which don't seem to  -->
<!-- be in the tagdoc (msm)                                   -->

<p>To take a simple hypothetical example, suppose in transcribing a
spoken text, we encounter an utterance that we can understand either as
<mentioned>We had fun at the beach today.</mentioned> or as <mentioned>We had sun at
the beach today.</mentioned> We can represent the exclusive alternation of
these two possibilities by means of the <att>exclude</att> attribute as
follows.

<eg><![ CDATA [
<div>
<!-- ... -->
<u id=we.fun exclude=we.sun>We had fun at the beach today.</u>
<u id=we.sun exclude=we.fun>We had sun at the beach today.</u>
<!-- ... -->
</div>
]]>
</eg>

<p>If it is then determined that the speaker said <mentioned>fun</mentioned>,
not <mentioned>sun</mentioned>, the encoder could amend the text by deleting the
alternant containing <mentioned>sun</mentioned> and the <att>exclude</att>
attribute on the remaining alternant.  Alternatively, the encoder could
preserve the fact that there was uncertainty in the original
transcription by retaining the alternants, and assigning the
<att>select=we.fun</att> attribute value to the <tag>div</tag> tag that
encompasses the alternants, as in:

<eg><![ CDATA [
<div select=we.fun>
<!-- ... -->
<u id=we.fun exclude=we.sun>We had fun at the beach today.</u>
<u id=we.sun exclude=we.fun>We had sun at the beach today.</u>
<!-- ... -->
</div>
]]>
</eg>

<p>The above alternation (including the <att>select</att> attribute)
could be recoded by assigning the <att>exclude</att> attributes to tags
that enclose just the words or even the characters that are mutually
exclusive, as in:

<note place=foot>See section <ptr target=AIlc> for discussion of the
<tag>w</tag> and <tag>c</tag> tags that can be used in the following
examples instead of the <tag>seg type=word</tag> and <tag>seg
type=character</tag> tags.</note>

<eg><![ CDATA [
<div>
<!-- ... -->
<u select=fun>We had
<seg type=word id=fun exclude=sun>fun</seg>
<seg type=word id=sun exclude=fun>sun</seg>
at the beach today.</u>
<!-- ... -->
</div>

<div>
<!-- ... -->
<u>We had
<seg type=word select=f>
<seg type=character id=f exclude=s>f</seg>
<seg type=character id=s exclude=f>s</seg>
un</seg>
at the beach today.
</u>
<!-- ... -->
</div>
]]>
</eg>

<p>Now suppose that the transcriber is uncertain whether the first word
in the utterance is <mentioned>We</mentioned> or <mentioned>Lee</mentioned>, but is
certain that if it is <mentioned>Lee</mentioned>, then the other uncertain word
is definitely <mentioned>fun</mentioned> and not <mentioned>sun</mentioned>.  The three
utterances that are in mutual exclusion can be encoded as follows.

<eg><![ CDATA [
<div>
<!-- ... -->
<u id=we.fun exclude='we.sun lee.fun'>
We had fun at the beach today.</u>
<u id=we.sun exclude='we.fun lee.fun'>
We had sun at the beach today.</u>
<u id=lee.fun exclude='we.fun we.sun'>
Lee had fun at the beach today.</u>
<!-- ... -->
</div>
]]>
</eg>

<p>The preceding example can also be encoded with <att>exclude</att>
attributes on the word segments <mentioned>We</mentioned>, <mentioned>Lee</mentioned>,
<mentioned>fun</mentioned> and <mentioned>sun</mentioned>:

<eg><![ CDATA [
<u>
<seg type=word id=we exclude=lee>We</seg>
<seg type=word id=lee exclude='we sun'>Lee</seg>
had
<seg type=word id=fun exclude=sun>fun</seg>
<seg type=word id=sun exclude='fun lee'>sun</seg>
at the beach today.</u>
]]>
</eg>

<p>The value of the <att>select</att> attribute is defined as a list of
identifiers (<code type=kw>IDREFS</code>); hence it can also be used to
narrow down the range of alternants, as in:

<eg><![ CDATA [
<div select='we.fun lee.fun'>
<!-- ... -->
<u id=we.fun exclude='we.sun lee.fun'>
We had fun at the beach today.</u>
<u id=we.sun exclude='we.fun lee.fun'>
We had sun at the beach today.</u>
<u id=lee.fun exclude='we.fun we.sun'>
Lee had fun at the beach today.</u>
<!-- ... -->
</div>
]]>
</eg>

This is interpreted to mean that either the first or the third
<tag>u</tag> tag appears, and is thus equivalent to just the alternation
of those two tags:

<eg><![ CDATA [
<div>
<!-- ... -->
<u id=we.fun exclude=lee.fun>We had fun at the beach today.</u>
<u id=lee.fun exclude=we.fun>Lee had fun at the beach today.</u>
<!-- ... -->
</div>
]]>
</eg>

<p>The <att>exclude</att> attribute can also be used in case there is
uncertainty about the tag that appears in a certain position.  For
example, the occurrence of the word <mentioned>May</mentioned> in the S-unit
<mentioned>Let's go to May</mentioned> can be interpreted, in the absence of
other information, either as a person's name or as a date.  The
uncertainty can be rendered as follows, using the <att>exclude </att>
attribute.

<eg><![ CDATA [
<s>Let's go to
<name id=mayd exclude=mayn>May</name>
<date id=mayn exclude=mayd copyOf=mayd></date>.</s>
]]>
</eg>

<p>Note the use of the <att>copyOf</att> attribute discussed in section
<ptr target=SAie>; this avoids having to repeat the content of the
element whose correct tagging is in doubt.

<p>The <att>copyOf</att> and the <att>exclude</att> attributes also
provide for a simple way of indicating uncertainty about exactly where a
particular element occurs in a document.<note>An alternative way of
representing this problem is discussed in chapter <ptr
target=CE>.</note> For example suppose that a particular <gi>div2</gi>
element appears either as the third and last of the <gi>div2</gi>
elements within the first <tag>div1</tag> element in the body of a
document, or as the first <gi>div2</gi> of the second <gi>div1</gi>.
One solution would be to record the <gi>div2</gi> in its entirety in the
first of these positions, and a virtual copy of it in the second, and
mark them as excluding each other as follows:

<eg rend=skeletal><![ CDATA [
<body>
<div1 id=c1>

 <div2 id=c1s3 exclude=c2s1>
  <!-- Text of the "movable" div2 appears here.  -->
 </div2>

</div1>

<div1 id=c2>

 <div2 id=c2s1 copyOf=c1s3 exclude=c1s3></div2>

</div1>

</body>
]]>
</eg>

In this case, the <att>select</att> attribute, if used, would appear on
the <tag>body</tag> tag.

<p>Mutual exclusion can also be expressed using a <tag>link</tag>; the
first example in this section can be recoded by removing the
<att>exclude</att> attributes from the <tag>u</tag> tags, and adding a
<tag>link</tag> as follows:  <note place=foot>In this example, we have
placed the <tag>link</tag> next to the tags that represent the
alternants.  It could also have been placed elsewhere in the document,
perhaps within a <tag>linkGrp</tag>.  </note>

<eg><![ CDATA [
<div>
<!-- ... -->
<u id=we.fun>We had fun at the beach today.</u>
<u id=we.sun>We had sun at the beach today.</u>
<link type='exclusive alternation'
      targType='u u'
      targOrder=N
      targets='we.fun we.sun'>
<!-- ... -->
</div>
]]>
</eg>

<p>Now we define the specialized linking element <gi>alt</gi>,making it
a member of the pointer class of elements, and assigning it a
<att>excl</att> (for <mentioned>mutually exclusive</mentioned>) attribute, which
can have either of the values <code type=value>Y</code> or <code
type=value>N</code>.  Then the following equivalence holds:

<eg rend=formula><![ CDATA [
 <alt mode=excl> = <link type='exclusive alternation'>
]]>
</eg>

<p>It is in the nature of alternation that the order of the targets is
irrelevant; hence the <att>targOrder</att> attribute of the
<tag>alt</tag> defaults to the value <code type=value>N</code>.  The
preceding <tag>link</tag> may therefore be recoded as the following
<tag>alt</tag> tag.

<eg><![ CDATA [
<alt mode=excl targType='u u' targets='we.fun we.sun'>
]]>
</eg>

<p>Other attributes that are defined specifically for the <gi>alt</gi>
element are <att>weights</att> and <att>percent</att>.  The
<att>weights</att> attribute is to be used if one wishes to assign
<term>probabilistic weights</term> to the targets (alternants).  Its
value is a list of numbers, corresponding to the targets, expressing the
probability that each target appears.  The <att>percent</att> attribute
is used to indicate whether the weights are stated as percentages
(<att>percent=Y</att>, the default) or as the actual probabilities
(<att>percent=N</att>).  If the alternants are mutually exclusive, then
the weights must sum to 100% (or 1, if <att>percent=N</att> is
specified).

<p>Suppose in the preceding example that it is equiprobable whether
<mentioned>fun</mentioned> or <mentioned>sun</mentioned> appears.  Then the
<tag>alt</tag> that represents the alternation may be stated as follows:

<eg><![ CDATA [
<alt mode=excl
     targType='u u'
     targets='we.fun we.sun'
     weights='50 50'>
]]>
</eg>

<p>The assignment of a weight of 100% to one target (and weights of 0%
to all the others) is equivalent to selecting that target.  Thus the
following encoding is equivalent to the second example at the beginning
of this section.

<eg><![ CDATA [
<!-- ... -->
<u id=we.fun>We had fun at the beach today.</u>
<u id=we.sun>We had sun at the beach today.</u>
<alt mode=excl
     targType='u u'
     targets='we.fun we.sun'
     weights='100 0'>
<!-- ... -->
]]>
</eg>

<!-- <p>Inclusive alternation can only be expressed by the    -->
<!-- use of a linking element, either a <tag>link             -->
<!-- type='inclusive alternation'</tag> tag, or an <tag>alt   -->
<!-- excl=N</tag> tag.  For example, suppose in the example   -->
<!-- concerning the <tag>div2</tag> tag that can appear in    -->
<!-- two different places, that it is also possible that it   -->
<!-- appears in both plases.  This situation can be encoded   -->
<!-- as follows.                                              -->

<!-- <eg><![ CDATA [ -->
<!-- <body> -->
<!-- <div1 id=c1> -->
<!-- ... -->
<!-- <div2 id=c1s3> -->
<!-- Text of the "copyable" div2 appears here. -->
<!-- </div2> -->
<!-- <div1 id=c2> -->
<!-- <div2 id=c2s1 copyOf=c1s3></div2> -->
<!-- ... -->
<!-- </div1> -->
<!-- ... -->
<!-- </body> -->
<!-- ... -->
<!-- <alt excl=N targType='div2 div2' targets='c1s3 c2s1'> -->
<!-- ]]> -->
<!-- </eg> -->

<!-- <p>For inclusive alternation, the <att>weights</att>     -->
<!-- attribute works as follows:  each weight states the      -->
<!-- probability that the target appears given that one or    -->
<!-- more of the other targets appear.  For the current       -->
<!-- example, suppose that the probability that the           -->
<!-- <tag>div2</tag> appears in the first position given      -->
<!-- that it appears in the second position is 20%, but that  -->
<!-- the probability that it appears in the second position   -->
<!-- given that it appears in the first position is 0%.       -->
<!-- Then the preceding <tag>alt</tag> tag can be revised to  -->
<!-- read:                                                    -->

<!-- <eg><![ CDATA [ -->
<!-- <alt excl=N targType='div2 div2' targets='c1s3 c2s1' weights='20 0'> -->
<!-- ]]> -->
<!-- </eg> -->

The sum of the weights for <tag>alt excl=N</tag> tags ranges from 0% to
(100 x k)%, where k is the number of targets.  If the sum is 0%, then
the alternation is equivalent to exclusive alternation; if the sum is
(100 x k)%, then all of the alternants must appear, and the situation is
better encoded without an <tag>alt</tag> tag.

<p>If it is desired, <gi>alt</gi> tags may be grouped together in an
<gi>altGrp</gi> tag, and attribute values shared by the individual
<tag>alt</tag> tags may be identified on the <tag>altGrp</tag> tag.  The
<att>targFunc</att> attribute defaults to the value <code
type=value>'first.alternant next.alternant'</code>.  Thus, specifying
the <att>extendTarg=2</att> attribute value permits the alternants to be
extended indefinitely.

<p>To illustrate, consider again the example of a transcribed utterance,
in which it is uncertain whether the first word is <mentioned>We</mentioned> or
<mentioned>Lee</mentioned>, whether the third word is <mentioned>fun</mentioned> or
<mentioned>sun</mentioned>, but that if the first word is <mentioned>Lee</mentioned>,
then the third word is <mentioned>fun</mentioned>.  Now suppose we have the
following additional information:  if <mentioned>we</mentioned> occurs, then the
probability that <mentioned>fun</mentioned> occurs is 50% and that
<mentioned>sun</mentioned> occurs is 50%; if <mentioned>fun</mentioned> occurs, then the
probability that <mentioned>we</mentioned> occurs is 40% and that
<mentioned>Lee</mentioned> occurs is 60%.  This situation can be encoded as
follows.

<eg><![ CDATA [
<u>
<seg type=word id=we exclude=lee>We</seg>
<seg type=word id=lee exclude=we>Lee</seg>
had
<seg type=word id=fun exclude=sun>fun</seg>
<seg type=word id=sun exclude=fun>sun</seg>
at the beach today.</u>
<!-- ... -->
<altGrp targType='seg seg'>
  <alt targets='we lee'>
  <alt targets='fun sun'>
  <alt mode=incl targets='we fun'  weights='50  50'>
  <alt mode=incl targets='Lee fun' weights='100 60'>
  </altGrp>
]]>
</eg>

<p>From the information in this encoding, we can determine that the
probability is about 28.5% that the utterance is <q>We had fun at the
beach today</q>, 28.5% that it is <mentioned>We had sun at the beach
today</mentioned>, and 43% that it is <mentioned>Lee had fun at the beach
today</mentioned>.

<!-- MSM:  correct details, please!-- >

<p>Another very similar example is the following regarding the text of a
Broadway song.  In three different versions of the song, the same line
reads <q>Her skin is tender as a leather glove,</q> <q>Her skin is
tender as a baseball glove,</q> and <q>Her skin is tender as Dimaggio's
glove.</q><note>The variant readings are found in the commercial sheet
music, the performance score, and the Broadway cast recording.</note>

<p>If we wish to express this textual variation using the <gi>alt</gi>
element, we can record our relative confidence in the readings
<mentioned>Dimaggio's</mentioned> (with probability 50%), <mentioned>a
leather</mentioned> (25%), and <mentioned>a baseball</mentioned> (25%).

<p>Let us extend the example with a further (imaginary) variation,
supposing for the sake of the argument that the next line is variously
given as <mentioned>and she bats from right to left</mentioned> (with
probability 50%) or <mentioned>now ain't that too damn bad</mentioned> (with
probability 50%).  Using the <gi>alt</gi> element, we can express the
conviction that if the first choice for the second line is correct, then
the probability that the first line contains <mentioned>Dimaggio's</mentioned>
is 90%, and each of the others 5%; whereas if the second choice for the
second line is correct, then the probability that the first line
contains <mentioned>Dimaggio's</mentioned> is 10%, and each of the others is
45%.  This can be encoded, with an <tag>altGrp</tag> tag containing a
combination of exclusive and inclusive <tag>alt</tag> tags, as follows.

<!-- Bloody Mary, from Rogers & Hammerstein, South Pacific -->
<eg><![ CDATA [
<div id=bm>
<!-- ... -->
<l>Her skin is tender as
<seg id=dm>Dimaggio's</seg>
<seg id=lt>a leather</seg>
<seg id=bb>a baseball</seg>
glove,</l>
<l id=rl>and she bats from right to left.</l>
<l id=db>now ain't that too damn bad.</l>
<!-- ... -->
</div>
<!-- ... -->
<altGrp>
  <alt mode=excl targType='seg seg'
       targets='dm lt bb' weights='50 25 25'>
  <alt mode=Excl targType='l l'
       targets='rl db' weights='50 50'>
  </altGrp>
<altGrp mode=incl targType='seg l'>
  <alt targets='dm rl' weights='90 90'>
  <alt targets='lt rl' weights='5 5'>
  <alt targets='bb rl' weights='5 5'>
  <alt targets='dm db' weights='10 10'>
  <alt targets='lt db' weights='45 90'>
  <alt targets='bb db' weights='45 90'>
  </altGrp>
]]>
</eg>

<p>Here are the formal declarations of the <gi>alt</gi> and
<gi>altGrp</gi> elements.

<eg id=dsaat>
<![ CDATA [
<!-- 14.8:  Alternation                                       -->
<!ELEMENT alt           - O  EMPTY                              >
<!ATTLIST alt                %a.global;
          crdate             CDATA               #IMPLIED
          evaluate           (all | one | none)  #IMPLIED
          resp               CDATA               #IMPLIED
          type               CDATA               #IMPLIED
          targType           NAMES               #IMPLIED
          targets            IDREFS              #REQUIRED
          weights            NUMBERS             #IMPLIED
          wScale             (perc | real)       %INHERITED
          mode               (excl | incl)       %INHERITED
          targOrder          (Y | N)             N              >
<!ELEMENT altGrp        - -  ((alt | ptr | xptr)*)              >
<!ATTLIST altGrp             %a.global;
                             %a.pointerGroup;
          wScale             (perc | real)       perc
          mode               (excl | incl)       excl           >
<!-- This fragment is used in sec. 14                         -->
]]>
</eg>


<!-- $Id: p2saan.odd,v 1.3 1994/03/27 21:47:19 msmcq Exp $ -->
<!-- $Log: p2saan.odd,v $
# Revision 1.3  1994/03/27  21:47:19  msmcq
# Correction of typos found by SJ, DB et al.
#
# Revision 1.2  1993/09/16  19:01:31  msmcq
# Minor SGML cleanup, add RCS log keyword
# -->
<!-- Revisions:                                               -->
<!-- 94-03-27 : MSM : typo from SJ                            -->
<!-- 94-03-26 : MSM : disambiguate TERM, Q (> code, ident...) -->
<!-- 93-09-15 : MSM : process TDL's changes                   -->
<!-- 93-07-16 : DTL : complete draft                          -->

<div2 id=SAan><head>Connecting Analytic and Textual Markup</head>

<p>In chapters <ptr target=AI> and <ptr target=FS> and elsewhere,
provision is made for analytic and interpretive markup to be represented
outside of textual markup, either in the same document or in a different
document.  The elements in these separate domains can be connected,
either with the pointing attributes <att>ana</att> (for
<mentioned>analysis</mentioned>) and <att>inst</att> (for
<mentioned>instance</mentioned>), or by means of <gi>link</gi> and
<gi>linkGrp</gi> elements.  Numerous examples are given in these
chapters, particularly in sections <ptr target=AIla>, <ptr
target=FSfl> and <ptr target=FSil>.


</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:
-->
             <!-- 14 Segmentation and Alignmt -->
