<?xml version="1.0" encoding="utf-8"?>
<!--
Copyright TEI Consortium. 
Dual-licensed under CC-by and BSD2 licences 
See the file COPYING.txt for details.
$Date$
$Id$
-->


<?xml-model href="http://tei.oucs.ox.ac.uk/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/P5/release/xml/tei/odd/p5.nvdl" type="application/xml" schematypens="http://purl.oclc.org/dsdl/nvdl/ns/structure/1.0"?>

<div xmlns="http://www.tei-c.org/ns/1.0" type="div1" xml:id="PH" n="18">
   <head>Representation of Primary Sources</head>

   <p>This chapter defines a module intended for use in the representation of primary sources, such
      as manuscripts or other written materials. Section <ptr target="#PHFAX"/> provides elements
      for the encoding of digital facsimiles or images of such materials, while the remainder of the
      chapter discusses ways of encoding detailed transcriptions of such materials. This module may
      also be useful in the preparation of critical editions, but the module defined here is
      distinct from that defined in chapter <ptr target="#TC"/>, and may be used independently of
      it. Detailed metadata relating to primary sources of any kind may be recorded using the
      elements defined by the manuscript description module discussed in chapter <ptr target="#MS"
      />, but again the present module may be used independently if such data is not required. </p>
   <!-- following para may need revision? -->
   <!-- p>It should be noted that, as elsewhere in these Guidelines,  this
chapter places more emphasis on the problems of representing the
textual components of a document than on those relating to the
description of the document's physical characteristics such as the
carrier medium or physical construction. These aspects, of particular
importance in codicology and the bibliographic study of incunables,
are touched on in the chapter on Manuscript Description (<ptr target="#MS"/>) and also form the subject of ongoing work in the TEI
Physical Bibliography workgroup.</p-->

   <p>Although this chapter discusses manuscript materials more frequently than other forms of
      written text, most of the recommendations presented are equally applicable <foreign>mutatis
         mutandis</foreign> to the encoding of printed matter or indeed any form of written source,
      including monumental inscriptions. Similarly, where in the following descriptions terms such
      as <soCalled>scribe</soCalled>, <soCalled>author</soCalled>, <soCalled>editor</soCalled>,
         <soCalled>annotator</soCalled> or <soCalled>corrector</soCalled> are used, these may be
      re-interpreted in terms more appropriate to the medium being transcribed. In printed material,
      for example, the <soCalled>compositor</soCalled> plays a role analogous to the
         <soCalled>scribe</soCalled>, while in an authorial manuscript, the author and the scribe
      are the same person. </p>

   <div xml:id="PHFAX">

      <head>Digital Facsimiles</head>

      <p>These Guidelines are mostly concerned with the preparation of digital texts in which
         pre-existing sources are transcribed or otherwise converted into character form, and marked
         up in XML. However, it is also very common practice to make a different form of
            <soCalled>digital text</soCalled>, which is instead composed of digital images of the
         original source, typically one per page, or other written surface. We call such a resource
         a <term>digital facsimile</term>. A digital facsimile may, in the simplest case, just
         consist of a collection of images, with some metadata to identify them and the source
         materials portrayed. It may sometimes contain a variety of images of the same source pages,
         perhaps of different resolutions, or of different kinds. Such a collection may form part of
         any kind of document, for example a commentary of a codicological or paleographic nature,
         where there is a need to align explanatory text with image data. It may also be
         complemented by a transcribed or encoded version of the original source, which may be
         linked to the page images. In this section we present elements designed to support these
         various possibilities and discuss the associated mechanisms provided by these
         Guidelines.</p>


      <p>When this module is included in a schema, the class <ident type="class">att.global</ident>
         is extended to include two new pointer attributes, <att>facs</att> and <att>change</att>: <specList>
            <specDesc key="att.global.facs" atts="facs"/>
            <specDesc key="att.global.change" atts="change"/>
         </specList> The <att>change</att> attribute is discussed further below in section <ptr
            target="#PH-changes"/>. The <att>facs</att> attribute is used to associate any element
         in a transcription with an image of the corresponding part of the source, by means of the
         usual URI pointing mechanism. <!-- i.e. URI reference? -->
      </p>

      <p>In the simple case where a digital text is composed of page images, the <att>facs</att>
         attribute on the <gi>pb</gi> element may be used to associate each image with an
         appropriate point in the text: <egXML xmlns="http://www.tei-c.org/ns/Examples"
            valid="feasible">
            <TEI>
               <teiHeader>
                  <!--...--></teiHeader>
               <text>
                  <pb facs="page1.png"/>
                  <!-- text contained on page 1 is encoded here -->
                  <pb facs="page2.png"/>
                  <!-- text contained on page 2 is encoded here -->
               </text>
            </TEI>
         </egXML> By convention, this encoding indicates that the image indicated by the
            <att>facs</att> attribute represents the whole of the text following the <gi>pb</gi>
         (pagebreak) element, up to the next <gi>pb</gi> element. Any convenient milestone element
         (see further <ptr target="#CORS5"/>) could be used in the same way; for example if the
         images represent individual columns, the <gi>cb</gi> element might be used. Though simple,
         this method has some drawbacks. It does not scale well to more complex cases where, for
         example, the images do not correspond exactly with transcribed pages, or where the
         intention is to align specific marked up elements with detailed images, or parts of images.
         The management of information about the images may become more difficult if references to
         them are scattered through many files rather than being concentrated in a single
         identifiable location. Nevertheless, this solution may be adequate for many straightforward
            <soCalled>digital library</soCalled> applications. </p>

      <p>The recommended approach to encoding facsimiles is instead to use the <att>facs</att>
         attribute in conjunction with the elements <gi>facsimile</gi> or <gi>sourceDoc</gi>, and
         the elements <gi>surface</gi>, <gi>surfaceGrp</gi>, and <gi>zone</gi>, which are also
         provided by this module. These elements make it possible to accommodate multiple images of
         each page, as well as to record the position and relative size of elements identified on any
         kind of written surface and to link such elements with digital facsimile images of them.
         Typical applications include the provision of full text search in <soCalled>digital
            facsimile editions</soCalled>, and ways of annotating graphics, for example so as to
         identify individuals appearing in group portraits and link them to data about the people
         represented. </p>

      <p>The following elements are available to represent components of a digital facsimile: <specList>
            <specDesc key="facsimile"/>
            <specDesc key="sourceDoc"/>
            <specDesc key="surface"/>
            <specDesc key="surfaceGrp"/>
            <specDesc key="zone" atts="points"/>
         </specList>
      </p>

      <p>Either of the <gi>facsimile</gi> or <gi>sourceDoc</gi> elements may be used to represent a
         digital facsimile. Either may appear within a TEI document along with, or instead of, the
            <gi>text</gi> element introduced in section <ptr target="#DS"/>. The <gi>facsimile</gi>
         element is designed for the case where the digital facsimile contains only images, whereas
         the <gi>sourceDoc</gi> element is for use in the case where such images are complemented by
         a documentary transcription. In this section, we first discuss the simpler case, returning
         to the use of the <gi>sourceDoc</gi> element in section <ptr target="#PH-transcr"/> below.
         When this module is selected therefore, a legal TEI document may thus comprise any of the
         following: <list rend="bulleted">
            <item>a TEI header and a text element</item>
            <item>a TEI header and a facsimile element</item>
            <item>a TEI header and a sourceDoc element</item>
            <item>a TEI header, a facsimile element, and a text element</item>
            <item>a TEI header, one or more sourceDoc or facsimile elements, and a text
               element</item>
         </list>
      </p>
      <p>Like the <gi>text</gi> element, a <gi>facsimile</gi> element may also contain an optional
            <gi>front</gi> or <gi>back</gi> element, used in the same way as described in sections
            <ptr target="#DSFRONT"/> and <ptr target="#DSBACK"/>. </p>

      <p>In the simplest case, a facsimile just contains a series of <gi>graphic</gi> elements, each
         of which identifies an image file: <egXML xml:lang="und"
            xmlns="http://www.tei-c.org/ns/Examples">
            <facsimile>
               <graphic url="page1.png"/>
               <graphic url="page2.png"/>
               <graphic url="page3.png"/>
               <graphic url="page4.png"/>
            </facsimile>
         </egXML> If desired, the <gi>binaryObject</gi> element described in <ptr target="#COGR"/>
         (or any other element from the <ident type="class">model.graphicLike</ident> class) can be
         used instead of a <gi>graphic</gi>.</p>

      <p>In this simple case, the four page images are understood to represent the complete
         facsimile, and are to be read in the sequence given. Suppose, however, that the second page
         of this particular work is available both as an ordinary photograph and as an infra-red
         image, or in two different resolutions. The <gi>surface</gi> element may be used to group
         the two image files, since these correspond with the same area of the work: <egXML
            xml:lang="und" xmlns="http://www.tei-c.org/ns/Examples">
            <facsimile>
               <graphic url="page1.png"/>
               <surface>
                  <graphic url="page2-highRes.png"/>
                  <graphic url="page2-lowRes.png"/>
               </surface>
               <graphic url="page3.png"/>
               <graphic url="page4.png"/>
            </facsimile>
         </egXML>
      </p>

      <p>The <gi>surface</gi> element provides a way of indicating that the two images of page2
         represent the same surface within the source material. A <term>surface</term> might be one
         side of a piece of paper or parchment, an opening in a codex treated as a single surface by
         the writer, a face of a monument, a billboard, a membrane of a scroll, or indeed any
         two-dimensional surface, of any size. </p>

      <p>The <gi>surfaceGrp</gi> element may be used to indicate that two (or more) surfaces are
         associated in some way, for example because they represent the recto and verso of the same
         leaf, as in this example: <egXML xml:lang="und" xmlns="http://www.tei-c.org/ns/Examples">
            <facsimile>
               <surfaceGrp n="leaf1">
                  <surface>
                     <graphic url="page1.png"/>
                  </surface>
                  <surface>
                     <graphic url="page2-highRes.png"/>
                     <graphic url="page2-lowRes.png"/>
                  </surface>
               </surfaceGrp>
            </facsimile>
         </egXML> The <gi>surfaceGrp</gi> element may also be useful as a means of identifying other
         groups of written surfaces, such as adjacent faces of a monument, or gatherings of leaves. </p>

      <p>Simply grouping related graphics is not however the main purpose of the <gi>surface</gi>
         element: rather it is to help identify the location and size of the various two-dimensional
         spaces constituting the digital facsimile. Note that the actual dimensions of the object
         represented are not provided by the <gi>surface</gi> element ; rather, the <gi>surface</gi>
         element defines an abstract coordinate space which may be used to address parts of the
         image. Four attributes supplied by the <ident type="class">att.coordinated</ident> class
         are used to define this space. <!-- A fifth attribute <att>points</att> may be
used to define a polygon of any shape using this coordinate system:-->
         <specList>
            <specDesc key="att.coordinated" atts="ulx uly lrx lry"/>
         </specList>
      </p>
      <p> By default, the same coordinate space is used for a <gi>surface</gi> and for all of its
         child elements.<note place="bottom">The coordinate space may be thought of as a grid
            superimposed on a rectangular space. Rectangular areas of the grid are defined as four
            numbers <hi rend="math">a b c d</hi>: the first two identify the grid point which is at
            the upper left corner of the rectangle; the second two give the grid point located at
            the lower right corner of the rectangle. The grid point <hi rend="math">a b</hi> is
            understood to be the point which is located <hi rend="math">a</hi> points from the
            origin along the <hi rend="math">x</hi> (horizontal) axis, and <hi rend="math">b</hi>
            points from the origin along the <hi rend="math">y</hi> (vertical) axis.</note> It may
         be most convenient to derive a coordinate space from a digital image of the surface in
         question such that each pixel in the image corresponds with a whole number of units
         (typically 1) in the coordinate space. In other cases it may be more convenient to use
         units such as millimetres. Neither practice implies any specific mapping between the
         coordinate system used and the actual dimensions of the physical object represented. </p>

      <p>A <gi>surface</gi> element can contain one or more <gi>zone</gi> elements, each of which
         represents a region or <term>bounding box</term> defined in terms of the same coordinate
         space as that of its parent <gi>surface</gi> element. A zone may be rectangular or
         non-rectangular: a rectangular zone is defined by a sequence of four coordinates in the
         same way as a surface; a non-rectangular zone is defined using the attribute
            <att>points</att>, which provides a sequence of coordinates, each of which specifies a
         point on the perimeter of the zone.<note place="foot">The <att>points</att> attribute
            supplies a <soCalled>points specification</soCalled> in the same form as that required
            by the <gi>polyline</gi> or <gi>polygon</gi> elements in the SVG standard. See <ptr
               target="http://www.w3.org/TR/SVG/shapes.html#PointsBNF"/>
         </note></p>
      <p>A zone may be used to define any region of interest, such as a detail or illustration, or
         some part of the surface which is to be aligned with a particular text element, or
         otherwise distinguished from the rest of the surface. A surface establishes a coordinate
         system which may be used to address parts or the whole of some digital representation of a
         written surface. A zone, by contrast, defines any arbitrary area of interest relative to
         that surface, using the same coordinate system. It might be bigger or smaller than its
         parent surface, or might overlap its boundaries. The only constraint is that it must be
         defined using the same coordinate system. </p>

      <p>When an image of some kind is supplied within either a zone or a surface, the implication
         is that the image represents the whole of the zone or surface concerned. In the simple case
         therefore, we might imagine a surface defining a page, within which there is a graphic
         representing the whole of that page, and a number of zones defining parts of the page, each
         with its own graphic, each representing a part of the page. If however one of those
         graphics actually represents an area larger than the page (for example to include a binding
         or the surface of a desk on which the page rests), then it will be enclosed by a zone with
         coordinates larger than those of the parent surface. </p>


      <p>For example, consider the following figure: <figure xml:id="durlach">
            <!--head>Relation between Page, Surface, and Zone</head-->
            <graphic url="Images/facs-fig2.jpg"/>
            <head>Badische Landesbibliothek, Manuscript Durlach 1, Fols. 95v-96r </head>
         </figure> This is an image of a two page spread from a manuscript in the Badische
         Landesbibliothek, Karlsruhe. We have no information as to the dimensions of the original
         object, but the low resolution image displayed here contains 500 pixels horizontally and
         321 pixels vertically. For convenience, we might map each pixel to one cell of the
         coordinate space.<note place="bottom">The coordinate space used here is based on pixels,
            but the mapping between pixels and units in the coordinate space need not be one-to-one;
            it might be convenient to define a more delicate grid, to enable us to address much
            smaller parts of the image. This can be done simply by supplying appropriate values for
            the attributes which define the coordinate space; for example doubling them all would
            map each pixel to two grid points in the coordinate space.</note>
      </p>

      <p>We therefore define a <gi>surface</gi> element corresponding with the area of the image
         which represents the whole of the two page spread and embed the graphic within it: <egXML
            xml:lang="und" xmlns="http://www.tei-c.org/ns/Examples"><facsimile>
               <surface ulx="0" uly="0" lrx="500" lry="321">
                  <graphic
                     url="http://upload.wikimedia.org/wikipedia/commons/5/50/Handschrift.karlsruhe.blb.jpg"
                  />
               </surface>
            </facsimile></egXML></p>



      <p>If desired, the <gi>binaryObject</gi> element described in <ptr target="#COGR"/> (or any
         other element from the <ident type="class">model.graphicLike</ident> class) may be used
         instead of a <gi>graphic</gi> element.</p>

      <p>Since the image in this example is of a two page opening, we will probably wish to define
         at least two nested zones, one for each page: <egXML
            xmlns="http://www.tei-c.org/ns/Examples"><facsimile>
               <surface ulx="50" uly="20" lrx="400" lry="280">
                  <zone ulx="0" uly="0" lrx="500" lry="321">
                     <graphic
                        url="http://upload.wikimedia.org/wikipedia/commons/5/50/Handschrift.karlsruhe.blb.jpg"
                     />
                  </zone>
                  <zone ulx="50" uly="20" lrx="210" lry="280">
                     <!-- left hand page -->
                  </zone>
                  <zone ulx="240" uly="25" lrx="400" lry="280">
                     <!-- right hand page -->
                  </zone>
                  <zone ulx="90" uly="40" lrx="200" lry="225">
                     <!--- written part of left hand page -->
                  </zone>
               </surface>
            </facsimile></egXML></p>
      <p>As this example shows, in addition to acting as a container for <gi>graphic</gi> elements,
            <gi>zone</gi> elements may be used to identify parts of a surface for analytical
         purposes. </p>
      <p>The relationship between zone and surface can be quite complex: for example, it may be
         appropriate to treat the whole of a two page spread as a single written surface, perhaps
         because particular written zones span both pages. A zone may contain a nested surface, if
         for example a page has an additional scrap of paper attached to it. A zone may be of any
         shape, not simply rectangular. Discussion of these and other cases are provided in section
            <ptr target="#PH-surfzone"/> below. </p>


      <p>In the following extended example, we discuss a hypothetical digital edition of an early
         16th century French work, Charles de Bovelles' <title>Géometrie Pratique</title>.<note
            place="bottom">The image is taken from the collection at <ptr
               target="http://ancilla.unice.fr/Illustr.html"/>, and was digitized from a copy in the
            Bibliothèque Municipale de Lyon, by whose kind permission it is included here.</note> In
         this edition, each page has been digitized as a separate file: for example, recto page 49
         is stored in a file called <ident type="file">Bovelles-49r.png</ident>. In the
            <gi>facsimile</gi> element used to contain the whole set of pages, we define a
            <gi>surface</gi> element for this page, which we situate within a coordinate scale
         running from 0 to 200 in the x (horizontal) axis, and 0 to 300 in the y (vertical) axis.
         The <gi>surface</gi> element contains a <gi>graphic</gi> element which represents the whole
         of this surface: <egXML xml:lang="und" xmlns="http://www.tei-c.org/ns/Examples"><facsimile>
               <surface ulx="0" uly="0" lrx="200" lry="300">
                  <graphic url="Bovelles-49r.png"/>
               </surface>
            </facsimile></egXML> We can now identify distinct zones within the page image using the
         coordinate scale defined for the surface. In the following figure <ptr target="#facs-fig1"
         /> we show the upper part of the page, with boxes indicating four such zones. Each of these
         will be represented by a <gi>zone</gi> element, given within the <gi>surface</gi> element
         already defined, and specified in terms of the same coordinate system. Some zones of
         interest are indicated by red lines in the following image. <figure xml:id="facs-fig1">
            <graphic url="Images/facs-fig1.png"/>
            <head>Detail of p 49r from Bovelles <title>Géometrie Pratique</title></head>
         </figure> The following encoding defines each of the four zones identified in the figure
         above. <egXML xmlns="http://www.tei-c.org/ns/Examples"><facsimile>
               <surface ulx="0" uly="0" lrx="200" lry="300">
                  <graphic url="Bovelles-49r.png"/>
                  <zone ulx="25" uly="25" lrx="180" lry="60">
                     <!-- contains the title -->
                  </zone>
                  <zone ulx="28" uly="75" lrx="175" lry="178"/>
                  <!--  contains the paragraph in italics -->
                  <zone ulx="105" uly="76" lrx="175" lry="160"/>
                  <!-- contains the figure -->
                  <zone ulx="45" uly="125" lrx="60" lry="130"/>
                  <!-- contains the word "pendans" -->
               </surface>
            </facsimile></egXML> Note that the location of each zone is defined independently but
         using the same coordinate system.</p>

      <p>A non rectangular-zone, for example that containing the word <mentioned>cloche.</mentioned>
         at bottom left of the page, could also be defined, using the <att>points</att> attribute:
            <egXML xmlns="http://www.tei-c.org/ns/Examples"><facsimile>
               <surface ulx="0" uly="0" lrx="200" lry="300">
                  <graphic url="Bovelles-49r.png"/>
                  <zone
                     points="4.8,31.0 5.4,30.7 5.5,32.2
		5.8,32.8 6.1,33.4 5.5,33.7 5.1,33.3 4.6,32.2"
                  />
               </surface>
            </facsimile></egXML>
      </p>

      <p>In this example a single <gi>graphic</gi> element has been associated directly with the
         surface of the page rather than nesting it within a zone. However, it is also possible to
         include multiple <gi>zone</gi> elements which contain a <gi>graphic</gi> element, if for
         example a detailed image is available. Since all <gi>zone</gi> elements use the same
         coordinate system (that defined by their parent <gi>surface</gi>), there is no need to
         demonstrate enclosure of one zone within another by means of nesting. To continue the
         current example, supposing that we have an additional image called <ident type="file"
            >Bovelles49r-detail.png</ident> containing an additional image of the figure in the
         third zone above, we might encode that zone as follows: <egXML xml:lang="und"
            xmlns="http://www.tei-c.org/ns/Examples">
            <zone ulx="105" uly="76" lrx="175" lry="160">
               <graphic url="Bovelles49r-detail.png"/>
            </zone>
         </egXML>
      </p>

   </div>
   <div xml:id="PH-transcr">
      <head>Combining Transcription with Facsimile</head>

      <p>A digitized source document may contain nothing more than page images and a small amount of
         metadata. It may also contain an encoded transcription of the pages represented, which may
         either be <q>embedded</q> within a <gi>sourceDoc</gi> element, or supplied in parallel with
         a <gi>facsimile</gi> as defined above.</p>
      <p>If the transcription is regarded as a text in its own right, organized and structured
         independently of its physical realization in the document or documents represented by the
         facsimile, then the recommended practice is to use the <gi>text</gi> element to contain
         such a structured representation, and to present it in parallel. The <gi>text</gi> element
         is a sibling of the <gi>facsimile</gi> and <gi>sourceDoc</gi> elements. This approach is
         illustrated in section <ptr target="#PH-bov"/> below. Alternatively, if the transcription
         is intended not to prioritize representation of the final text so much as the process by
         which the document came to take its present form, or the physical disposition of its
         component parts, it may be preferable to present it as an embedding transcription, as
         further described in section <ptr target="#PHZLAB"/> below.</p>
      <div xml:id="PH-bov">
         <head>Parallel Transcription</head>

         <p>Suppose now that we wish to align a transcription of the page discussed in the preceding
            section with particular zones. We begin by giving each relevant part of the facsimile an
            identifier: <egXML xmlns="http://www.tei-c.org/ns/Examples"><facsimile>
                  <surface ulx="0" uly="0" lrx="200" lry="300">
                     <zone xml:id="B49r" ulx="0" uly="0" lrx="200" lry="300">
                        <graphic url="Bovelles-49r.png"/>
                     </zone>
                     <zone ulx="105" uly="76" lrx="175" lry="160">
                        <graphic url="Bovelles49r-detail.png"/>
                     </zone>
                     <zone xml:id="B49rHead" ulx="25" uly="25" lrx="180" lry="60"/>
                     <!-- contains the title -->
                     <zone xml:id="B49rPara2" ulx="28" uly="75" lrx="175" lry="178"/>
                     <!-- contains the first paragraph in italics -->
                     <zone xml:id="B49rFig1" ulx="105" uly="76" lrx="175" lry="160"/>
                     <!-- contains the figure -->
                     <zone xml:id="B49rW457" ulx="45" uly="125" lrx="60" lry="130"/>
                     <!-- contains the word "pendans" -->
                  </surface>
               </facsimile></egXML> The alignment between transcription and image is made, as usual,
            by means of the <att>facs</att> attribute: <egXML
               xmlns="http://www.tei-c.org/ns/Examples" xml:lang="fr">
               <pb facs="#B49r"/>
               <fw>De Geometrie 49</fw>
               <head facs="#B49rHead"> DU SON ET ACCORD DES CLOCHES ET <lb/> des alleures des
                  chevaulx, chariotz &amp; charges, des fontaines:&amp; <lb/> encyclie du monde,
                  &amp; de la dimension du corps humain.<lb/> Chapitre septiesme</head>
               <div n="1">
                  <p>Le son &amp; accord des cloches pendans en ung mesme <lb/> axe, est faict en
                     contraires parties.</p>
                  <p rend="it" facs="#B49rPara2">LEs cloches ont quasi fi<lb/>gures de rondes
                     pyra<lb/>mides imperfaictes &amp; <lb/> irregulieres: &amp; leur accord se
                     <lb/> fait par reigle geometrique. Com<lb/>me si les deux cloches C &amp; D
                     <lb/> sont <w facs="#B49rW457">pendans</w> à ung mesme axe <lb/> ou essieu A B:
                     je dis que leur ac<lb/>cord se fera en co<ex>n</ex>traires parties<lb/>
                        co<ex>m</ex>me voyez icy figuré. Car qua<ex>n</ex>d <lb/> lune sera en
                     hault, laultre declinera embas. Aultrement si elles decli<lb/>nent toutes deux
                     ensembles en une mesme partie, elles seront discord, <lb/> &amp; sera leur
                     sonnerie mal plaisante à oyr.<figure facs="#B49rFig1">
                        <graphic url="Bovelles49r-detail.png"/>
                     </figure></p>
               </div>
            </egXML>
         </p>

         <p>It is also possible to point in the other direction, from a <gi>surface</gi> or
               <gi>zone</gi> to the corresponding text. This is the function of the <att>start</att>
            attribute, which supplies the identifier of the element containing at least the start of
            the transcribed text found within the surface or zone concerned. Thus, another way of
            linking this page with its transcription would be simply <egXML xml:lang="und"
               xmlns="http://www.tei-c.org/ns/Examples"><facsimile>
                  <surface start="#PB49R">
                     <graphic url="Bovelles-49r.png"/>
                  </surface>
               </facsimile>
               <text>
                  <body>
                     <div>
                        <!-- ... -->
                        <pb xml:id="PB49R"/>
                        <fw>De Geometrie 49</fw>
                        <!-- ... -->
                     </div>
                  </body>
               </text>
            </egXML></p>


         <specGrp xml:id="DPFACS">
            <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/facsimile.xml"/>
            <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/sourceDoc.xml"/>
            <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/att.global.facs.xml"/>
            <include xmlns="http://www.w3.org/2001/XInclude"
               href="../../Specs/att.global.change.xml"/>
            <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/surface.xml"/>
            <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/surfaceGrp.xml"/>
            <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/att.coordinated.xml"/>
            <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/zone.xml"/>
            <include xmlns="http://www.w3.org/2001/XInclude"
               href="../../Specs/model.resourceLike.xml"/>
         </specGrp>

      </div>





      <div xml:id="PHZLAB">
         <head>Embedded Transcription</head>
         <p>An <term>embedded transcription</term> is one in which words and other written traces
            are encoded as subcomponents of elements representing the physical surfaces carrying
            them rather than independently of them. </p>
         <p>The following elements are available for this purpose: <specList>
               <specDesc key="sourceDoc"/>
               <specDesc key="surface"/>
               <specDesc key="zone"/>
               <!--specDesc key="patch" atts="binder height width flipping"/-->
               <specDesc key="line"/>
               <specDesc key="seg"/>
            </specList>
         </p>

         <p>The elements <gi>surface</gi>, <gi>surfaceGrp</gi>, and <gi>zone</gi> were introduced
            above in section <ptr target="#PHFAX"/> When supplied within a <gi>sourceDoc</gi>
            element, these elements may contain transcriptions of the written content of a source in
            addition to or as an alternative to digital images of them. Such transcription may be
            placed directly within the <gi>zone</gi> element, or within one or more <gi>line</gi>
            elements, for cases where the writing is linear, in the sense that it is composed of
            discrete tokens organized physically into groups, typically organized in a sequence
            corresponding with the way they are intended to be read. Depending on the directionality
            of the writing system used, this might be any combination of top-down and left to right,
            or vice versa. The element <gi>line</gi> may be used to hold a complete group of such
            tokens. Where, however, the lineation is not considered significant, any group of tokens
            may be indicated using the <gi>zone</gi> element. The <gi>seg</gi> element described in
            section <ptr target="#SASE"/> may also be used to indicate smaller sequences of tokens
            within <gi>zone</gi>, or <gi>line</gi> as appropriate. </p>

         <p>Returning to the preceding example, we might transcribe the content of the zone to which
            we gave the identifier <ident>B49rPara2</ident> within a <gi>sourceDoc</gi> element as
            follows: </p>
         <egXML xmlns="http://www.tei-c.org/ns/Examples">
            <sourceDoc>
               <surface ulx="0" uly="0" lrx="200" lry="300">
                  <zone ulx="0" uly="0" lrx="200" lry="300">
                     <graphic url="Bovelles-49r.png"/>
                  </zone>
                  <!-- ... -->
                  <zone ulx="28" uly="75" lrx="175" lry="178"><line>LEs cloches ont quasi
                        fi</line><line>gures de rondes pyra</line><line>mides imperfaictes &amp;
                        </line><line> irregulieres: &amp; leur accord se</line>
                     <line> fait par reigle geometrique. Com</line><line>me si les deux cloches C
                        &amp; D </line><line> sont <zone ulx="45" uly="125" lrx="60" lry="130"
                           >pendans</zone> à ung mesme axe</line><line> ou essieu A B: je dis que
                        leur ac</line><line>cord se fera en cõtraires parties</line><line> cõme
                        voyez icy figuré. Car quãd </line><line> lune sera en hault, laultre
                        declinera embas. Aultrement si elles declinent toutes deux ensembles en une
                        mesme partie, elles seront discord,</line><line> &amp; sera leur sonnerie
                        mal plaisante à oyr.</line></zone>
                  <zone ulx="105" uly="76" lrx="175" lry="160">
                     <graphic url="Bovelles49r-detail.png"/>
                  </zone>
               </surface></sourceDoc></egXML>
         <p>As mentioned above, some or all of the written surfaces being transcribed may be
            composed of physically distinct scraps. In the following example, taken from the Walt
            Whitman Archive, two pieces of newsprint have been glued to a piece of blue paper on
            which a poem is being drafted: <figure xml:id="sleeprs">
               <graphic url="Images/whitman01.jpg" width="400px"/>
               <head rend="it">Single leaf of notes possibly related to the poem eventually titled
                  Sleepers. From the Walt Whitman Archive (Duke 258). </head>
            </figure> The two pieces of newsprint might simply be regarded as special kinds of zone,
            but they are also new surfaces, since they might contain additional written zones
            themselves (such as the numbers in this case). </p>

         <p>Using these elements, the Whitman draft above might be encoded as follows: <egXML
               xmlns="http://www.tei-c.org/ns/Examples" source="#WHITMS2">
               <surface>
                  <zone>
                     <line>Poem</line>
                     <line>As in Visions of — at</line>
                     <line>night —</line>
                     <line>All sorts of fancies running through</line>
                     <line>the head</line>
                  </zone>
                  <zone>
                     <surface type="newsprint" attachment="glue" flipping="false">
                        <zone>Spring has just set in here, and the weather.... a steamer </zone>
                        <metamark function="sequence">2</metamark>
                     </surface>
                  </zone>
                  <zone>
                     <surface type="newsprint" attachment="glue" flipping="false">
                        <zone>"The shores on either side of the Sound are... The In- </zone>
                        <metamark function="sequence">3</metamark>
                     </surface>
                  </zone>
               </surface>
            </egXML>
         </p>

         <p>The <gi>metamark</gi> element used in this example is further discussed below (<ptr
               target="#PH-meta"/>)</p>

         <p>Note that in this example we have not included any <gi>graphic</gi> element
            corresponding with the <gi>zone</gi> or <gi>surface</gi> elements identified in the
            transcription. The encoder may choose to complement a transcription with graphic
            representations of its source at whatever level is considered effective, or not at all.
            Equally, the encoder may choose to provide only graphics without any transcription, to
            provide only a structured (non-embedded) transcription, or to provide any combination of
            the three. </p>
         <p>This example also lacks any coordinate information to specify either the size of the two
            newspaper fragments or whereabouts on the parent <gi>surface</gi> element they are to be
            found, other than the reading order implicit in their sequence. Such information could
            be added if desired by specifying a coordinate system on the outermost <gi>surface</gi>
            element, and then indicating values within that system for each of the two fragments, as
            was discussed above. We discuss this in further detail in section <ptr
               target="#PH-surfzone"/> below. </p>
      </div>

   </div>

   <div xml:id="PHST">
      <head>Scope of Transcriptions</head>

      <p>When transcribing a primary source, scholars may wish to record information concerning
         individual readings of letters, words, or larger units, whether the object is simply a
            <soCalled>neutral</soCalled> transcription or a critical edition. In either case they
         may also wish to include other editorial material, such as comments on the status or
         possible origin of particular readings, corrections, or text supplied to fill lacunae. </p>

      <p>Such elements may also be used for digital transcriptions in which the object is not to
         represent a finished text, but rather to represent the creative process, as evidenced by
         different <q>layers</q> or <q>traces</q> of writing in one or more documents.
         Transcriptions of this kind are closely focussed on the physical appearance of specific
         documents, needing to distinguish the traces of different writing activities on them, such
         as additions and deletions but also other indications of how the writing is to be read,
         such as indications of transposition, re-affirmation of writing which has been deleted, and
         so on. Such distinctions are considered of particular importance when dealing with
         authorial manuscripts, but are also relevant in the case of historical sources such as
         charters or other legal documents.</p>

      <p>In either case, it is customary in transcriptions to register certain features of the
         source, such as ornamentation, underlining, deletion, areas of damage and lacunae. This
         chapter provides ways of encoding such information: <list rend="bulleted">
            <item>methods of recording editorial or other alterations to the text, such as expansion
               of abbreviations, corrections, conjectures, etc. (section <ptr target="#PHCH"
               />)</item>
            <item>methods of describing important extra-linguistic phenomena in the source: unusual
               spaces, lines, page and line breaks, changes of manuscript hand, etc. (section <ptr
                  target="#PHPH"/>)</item>
            <item>methods of representing complex organizations of surfaces and zones (section <ptr
                  target="#PH-surfzone"/>) </item>
            <item>methods of representing aspects of layout such as spacing or lines <ptr
                  target="#PHLAY"/>
            </item>
            <item>methods of representing material such as running heads, catch-words, and the like
               (section <ptr target="#PHSK"/>)</item>
         </list></p>


      <p>The remainder of this chapter describes a model for encoding such transcriptions, in which
         elements such as <gi>mod</gi>, <gi>del</gi>, etc. are used to mark writing traces and their
         functions within the document. Each such element can be assigned to one or more
         editorially-defined modification groups, termed a <term>change</term>, by means of a global
            <att>change</att> attribute, which references a definition for the modification group
         concerned, typically provided within the TEI header <gi>creation</gi> element; see further
            <ptr target="#PH-changes"/>. The transcription itself may be embedded within the
         elements <gi>surface</gi> and <gi>zone</gi> described in section <ptr target="#PHFAX"/>, or
         provided in parallel within a <gi>text</gi> element. Within a <gi>zone</gi>, the
         transcription may be organized topographically in terms of lines of writing, using the
            <gi>line</gi> element, or in terms of further nested zones, or as a combination of the
         two; see further <ptr target="#PHZLAB"/>. </p>



      <p>These recommendations are not intended to meet every transcriptional circumstance likely to
         be faced by any scholar. Rather, they should be regarded as a base which can be elaborated
         if necessary by different scholars in different disciplines </p>
      <!-- , with
distinct scholarly domains eventually developing their own document
types.  In time, the feature structure notation developed in chapter
<ptr target="#FS"/>, may also permit scholars to tailor the encoding
of complex transcriptional information in ways not here anticipated.
 We are conscious that a great deal of work remains to done in
these areas, and that the encoder will need to take even more
individual responsibility than usual in applying the recommendations
of this chapter in such contexts, but believe that these
recommendations form a good basis for such future work.-->

      <p>As a rule, all elements which may be used in the course of a transcription of a single
         witness may also be used in a critical apparatus, i.e. within the elements proposed in
         chapter <ptr target="#TC"/>. This can generally be achieved by nesting a particular reading
         containing tagged elements from a particular witness within the <gi>rdg</gi> element in an
            <gi>app</gi> structure. </p>
      <p>Just as a critical apparatus may contain transcriptional elements within its record of
         variant readings in various witnesses, one may record variant readings in an individual
         witness by use of the apparatus mechanisms <gi>app</gi> and <gi>rdg</gi>. This is discussed
         in section <ptr target="#TCTR"/>. </p>

      <div type="div2" xml:id="PHCH">
         <head>Altered, Corrected, and Erroneous Texts</head>

         <p>In the detailed transcription of any source, it may prove necessary to record various
            types of actual or potential alteration of the text: expansion of abbreviations,
            correction of the text (either by author, scribe, or later hand, or by previous or
            current editors or scholars), addition, deletion, or substitution of material, and
            similar matters. The sections below describe how such phenomena may be encoded using
            either elements defined in the core module (defined in chapter <ptr target="#CO"/>) or
            specialized elements available only when the module described in this chapter is
            available.</p>

         <div type="div3" xml:id="PHCO">
            <head>Core Elements for Transcriptional Work</head>
            <p>In transcribing individual sources of any type, encoders may record corrections,
               normalizations, additions, and omissions using the elements described in section <ptr
                  target="#COED"/>. Representation of abbreviations and their expansions may also
               involve use of elements described in section <ptr target="#CONA"/>. Elements
               particularly relevant to this chapter include: <specList>
                  <specDesc key="abbr"/>
                  <specDesc key="add"/>
                  <specDesc key="choice"/>
                  <specDesc key="corr"/>
                  <specDesc key="del"/>
                  <specDesc key="expan"/>
                  <specDesc key="gap"/>
                  <specDesc key="sic"/>
               </specList>
            </p>
           <p>All of these elements bear additional attributes 
             for specifying who is responsible for the interpretation 
             represented by the markup, and the associated certainty. 
             In addition, some of them bear an attribute allowing the markup
               to be categorized by type and source. <specList>
                  <specDesc key="att.editLike" atts="evidence"/>
                  <specDesc key="att.source" atts="source"/>
                  <specDesc key="att.global.responsibility" atts="cert resp"/>
                  <specDesc key="att.typed" atts="type subtype"/>
               </specList> The specific aspect of the markup described by these attributes differs
               on different elements; for further discussion, see the relevant sections below,
               especially section <ptr target="#PHHR"/>.</p>
            <p>The following sections describe how the core elements just named may be used in the
               transcription of primary source materials. </p>
         </div>

         <div type="div3" xml:id="PHAB">
            <head>Abbreviation and Expansion</head>

            <p>The writing of manuscripts by hand lends itself to the use of abbreviation to shorten
               scribal labour. Commonly occurring letters, groups of letters, words, or even whole
               phrases, may be represented by significant marks. This phenomenon of manuscript
               abbreviation is so widespread and so various that no taxonomy of it is here
               attempted. Instead, methods are shown which allow abbreviations to be encoded using
               the core elements mentioned above.</p>
            <p>A manuscript abbreviation may be viewed in two ways. One may transcribe it as a
               particular sequence of letters or marks upon the page: thus, a <q>p with a bar
                  through the descender</q>, a <q>superscript hook</q>, a <q>macron</q>. One may
               also interpret the abbreviation in terms of the letter or letters it is seen as
               standing for: thus, <q>per</q>, <q>re</q>, <q>n</q>. Both of these views are
               supported by these Guidelines. </p>

            <p>In many cases the glyph found in the manuscript source also exists in the Unicode
               character set: for example the common Latin brevigraph ⁊, standing for
                  <mentioned>et</mentioned> and often known as the <soCalled>Tironian et</soCalled>
               can be directly represented in any XML document as the Unicode character with code
               point <val>U+204A</val> (see further <ptr target="#SG-er"/> and <ptr target="#CHSH"
               />). In cases where it does not, these Guidelines recommend use of the <gi>g</gi>
               element provided by the <ident type="module">gaiji</ident> module described in
               chapter <ptr target="#WD"/>. This module allows the encoder great flexibility both in
               processing and in documenting non-standard characters or glyphs, including the
               ability to provide detailed documentation and images for them. </p>

            <p>These two methods of coding abbreviation may also be combined. An encoder may record,
               for any abbreviation, both the sequence of letters or marks which constitutes it, and
               its sense, that is, the letter or letters for which it is believed to stand. For
               example, in the following fragment the phrase <mentioned>euery persone</mentioned> is
               represented by a sequence of abbreviated characters: <figure>
                  <graphic url="Images/euerypersone.png"/>
                  <head>Detail from fol. 126v of Bodleian MS Laud Misc 517</head>
               </figure> These lines may be transcribed directly, using the <gi>g</gi> element to
               indicate the two brevigraphs as follows: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples" source="#PH-BIBL-1">eu<g ref="#b-er"
                     >er</g>y <g ref="#b-per">per</g>sone that loketh after heuen hath a place in
                  this ladder <!-- elsewhere -->
                  <charDecl>
                     <char xml:id="b-er">
                        <!-- definition for the er brevigraph -->
                     </char>
                     <char xml:id="b-per">
                        <!-- definition for the per brevigraph -->
                     </char>
                  </charDecl></egXML> Note that in each case the <gi>g</gi> element may contain a
               suggested replacement for the referenced brevigraph; this is purely advisory however,
               and may not be appropriate in all cases. The referenced character definitions may be
               located elsewhere in this or some other document, typically forming part of a
                  <gi>charDecl</gi> element, as described in <ptr target="#D25-20"/>. </p>

            <p>The transcriber may also wish to indicate that, because of the presence of these
               particular characters, the two words are actually abbreviations, by using the
                  <gi>abbr</gi> element: <egXML xmlns="http://www.tei-c.org/ns/Examples"><abbr>eu<g
                        ref="#b-er">er</g>y</abbr>
                  <abbr><g ref="#b-per">per</g>sone</abbr> ... </egXML> Alternatively, the
               transcriber may choose silently to expand these abbreviations, using the
                  <gi>expan</gi> element: <egXML xmlns="http://www.tei-c.org/ns/Examples"
                     ><expan>euery</expan>
                  <expan>persone</expan> ... </egXML> And, of course, the <gi>choice</gi> element
               can be used to show that one encoding is an alternative for the other: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples"><choice><abbr>eu<g ref="#b-er"
                        >er</g>y</abbr><expan>euery</expan></choice></egXML>
            </p>
            <p>When abbreviated forms such as these are expanded, two processes are carried out:
               some characters not present in the abbreviation are added (always), and some
               characters or glyphs present in the abbreviation are omitted or replaced (often). For
               example, when the abbreviation <mentioned>Dr.</mentioned> is expanded to
                  <mentioned>Doctor</mentioned>, the dot in the abbreviation is removed, and the
               letters <mentioned>octo</mentioned> are added. Where detailed markup of abbreviated
               words is required, these two aspects may be marked up explicitly, using the following
               elements: <specList>
                  <specDesc key="ex"/>
                  <specDesc key="am"/>
               </specList> Using these elements, a transcriber may indicate the status of the
               individual letters or signs within both the abbreviation and the expansion. The
                  <gi>am</gi> element surrounds characters or signs such as tittles or tildes, used
               to indicate the presence of an abbreviation, which are typically removed or replaced
               by other characters in the expanded form of the abbreviation: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples"><abbr>eu<am><g ref="#b-er"/></am>y</abbr>
                  <abbr><am><g ref="#b-per"/></am>sone</abbr> ... </egXML> while the <gi>ex</gi>
               element may be used to indicate those characters within the expansion which are not
               present in the abbreviated form. <egXML xmlns="http://www.tei-c.org/ns/Examples"
                        ><expan>eu<ex>er</ex>y</expan>
                  <expan><ex>per</ex>sone</expan> ... </egXML> The content of the <gi>abbr</gi>
               element should usually include the whole of the abbreviated word, while the
                  <gi>expan</gi> element should include the whole of its expansion. If this is not
               considered necessary, the <gi>am</gi> and <gi>ex</gi> elements may be used within a
                  <gi>choice</gi> element, as in this example: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples">eu<choice><am><g ref="#b-er"
                        /></am><ex>er</ex></choice>y <choice><am><g ref="#b-per"
                     /></am><ex>per</ex></choice>sone ... </egXML>
            </p>
            <p>As implied in the preceding discussion, making decisions about which of these various
               methods of representing abbreviation to use will form an important part of an
               encoder's practice. As a rule, the <gi>abbr</gi> and <gi>am</gi> elements should be
               preferred where it is wished to signify that the content of the element is an
               abbreviation, without necessarily indicating what the abbreviation may stand for. The
                  <gi>ex</gi> and <gi>expan</gi> elements should be used where it is wished to
               signify that the content of the element is not present in the source but has been
               supplied by the transcriber, without necessarily indicating the abbreviation used in
               the original. The decision as to which course of action is appropriate may vary from
               abbreviation to abbreviation; there is no requirement that the same system be used
               throughout a transcription, although doing so will generally simplify processing. The
               choice is likely to be a matter of editorial policy. If the highest priority is to
               transcribe the text <foreign>literatim</foreign> (letter by letter), while indicating
               the presence of abbreviations, the choice will be to use <gi>abbr</gi> or <gi>am</gi>
               throughout. If the highest priority is to present a reading transcription, while
               indicating that some letters or words are not actually present in the original, the
               choice will be to use <gi>ex</gi> or <gi>expan</gi> throughout.</p>
            <p>Further information may be attached to instances of these elements by the
                  <gi>note</gi> element, on which see section <ptr target="#CONO"/>, and by use of
               the <att>resp</att> and <att>cert</att> attributes. In this instance from the English
                  <title>Brut</title>, a note is attached to an editorial expansion of the tail on
               the final d of <mentioned>good</mentioned> to <mentioned>goode</mentioned>: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples" source="#PH-eg-01">For alle the while
                  that I had good<ex xml:id="exp01">e</ex> I was welbeloued</egXML>
               <!--  abbr="&#x027d;" --> Then the note: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples"><note target="#exp01">The stroke added to
                     the final d could signify the plural ending (-es, -is, -ys&gt;) but the
                     singular <hi rend="it">goode</hi> was used with the meaning <q>property</q>,
                        <q>wealth</q>, at this time (v. examples quoted in OED, sb. Good, C. 7, b,
                     c, d and 8 spec.)</note></egXML> The editor might declare a degree of certainty
               for this expansion, based on the OED examples, and state the responsibility for the
               expansion: <egXML xmlns="http://www.tei-c.org/ns/Examples">For alle the while that I
                  had good<ex resp="#mp" cert="high">e</ex> I was welbeloued</egXML> The value
               supplied for the <att>resp</att> attribute should point to the name of the editor
               responsible for this and possibly other interventions; an appropriate element
               therefore might be a <gi>respStmt</gi> element in the header like the following:
                  <egXML xmlns="http://www.tei-c.org/ns/Examples">
                  <respStmt xml:id="mp">
                     <resp>Editorial emendations</resp>
                     <name>Malcom Parkes</name>
                  </respStmt></egXML> Observe that the <att>cert</att> and <att>resp</att>
               attributes are used with the <gi>ex</gi> element only to indicate confidence in the
               content of the element (i.e. the expansion), and responsibility for suggesting this
               expansion respectively. </p>
            <p>The <gi>choice</gi> element may be used to indicate that the proposed expansion is
               one way of encoding what might equally well be represented as an abbreviation,
               represented by the hooked D, as follows: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples">For alle the while that I had
                           <choice><sic>goo<abbr>&#x0257;</abbr></sic>
                     <expan resp="#mp" cert="high">good<ex>e</ex></expan></choice> I was
                  welbeloued</egXML> If it is desired to express aspects of certainty and
               responsibility for some other aspect of the use of these elements, then the
               mechanisms discussed in chapter <ptr target="#CE"/> should be used. See also <ptr
                  target="#PHHR"/> for discussion of the issues of certainty and responsibility in
               the context of transcription.</p>

            <p>If more than one expansion for the same abbreviation is to be recorded, multiple
               notes may be supplied. It may also be appropriate to use the markup for critical
               apparatus; an example is given in section <ptr target="#TCTR"/>.</p>
         </div>


         <div type="div3" xml:id="PHCC">
            <head>Correction and Conjecture</head>

            <p>The <gi>sic</gi>, <gi>corr</gi>, and <gi>choice</gi> elements, defined in the <ident
                  type="module">core</ident> module should be used to indicate passages deemed in
               need of correction, or actually corrected, during the transcription of a source. For
               example, in the manuscript of William James's <title>A Pluralistic Universe</title>
               as edited by Fredson Bowers (Cambridge: Harvard University Press, 1977), a sentence
               first written <q rend="display">One must have lived longer with this system, to
                  appreciate its advantages.</q> has been modified by James to begin <q>But One must
                  ...</q>, without the initial capital O having been reduced to lowercase. This
               non-standard orthography could be recorded thus: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples">But <sic>One</sic> must have lived
                  ...</egXML> or corrected: <egXML xmlns="http://www.tei-c.org/ns/Examples">But
                     <corr>one</corr> must have lived ...</egXML> or the two possibilities might be
               represented as a choice: <egXML xmlns="http://www.tei-c.org/ns/Examples">But
                        <choice><sic>One</sic><corr>one</corr></choice> must have lived
               ...</egXML></p>
            <p>Similarly, in this example from Albertus Magnus, both a manuscript error
                  <mentioned>angues</mentioned> and its correction <mentioned>augens</mentioned> are
               registered within a <gi>choice</gi> element: <egXML xml:lang="la"
                  xmlns="http://www.tei-c.org/ns/Examples" source="#PH-eg-02">Nos autem iam
                  ostendimus quod nutrimentum et
                     <choice><sic>angues</sic><corr>augens</corr></choice>.</egXML>
            </p>
            <p>Note that the <gi>corr</gi> element is used to provide a corrected form which is
                  <emph>not</emph> present in the source; in the case of a correction made in the
               source itself, whether scribal, authorial, or by some other hand, the <gi>add</gi>,
                  <gi>del</gi>, and <gi>subst</gi> elements described in <ptr target="#PHAD"/>
               should be used.</p>
            <p>The <gi>sic</gi> element is used to mark passages considered by the transcriber to be
               erroneous; in such cases, the <gi>corr</gi> element indicates the transcriber's
               correction of them. Where the transcriber considers that one or more words have been
               erroneously omitted in the original source and corrects this omission, the
                  <gi>supplied</gi> element discussed in <ptr target="#PHOM"/> should be used in
               preference to <gi>corr</gi>. Thus, in the following example, from George Moore's
               draft of additional materials for <title>Memoirs of My Dead Life</title>, the
               transcriber supplies the word <mentioned>we</mentioned> omitted by the author: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples" source="#PH-eg-03">You see that I avoid
                  the word create for we create nothing <supplied>we</supplied> develope.</egXML>
            </p>
            <p>As with <gi>expan</gi> and <gi>abbr</gi>, the choice as to whether to record simply
               that there is an apparent error, or simply that a correction has been applied, or to
               record both possible readings within a <gi>choice</gi> element is left to the
               encoder. The decision is likely to be a matter of editorial policy, which might be
               applied consistently throughout or decided case by case. If the highest priority is
               to present an uncorrected transcription while noting perceived errors in the
               original, the choice will typically be to use only <gi>sic</gi> throughout. If the
               highest priority is to present a reading transcription, while indicating that
               perceived errors in the original have been corrected, the choice will be to use only
                  <gi>corr</gi> throughout.</p>

            <p>Further information may be attached to instances of these elements by the
                  <gi>note</gi> element and <att>resp</att> and <att>cert</att> attributes.
               Instances of these elements may also be classified according to any convenient
               typology using the <att>type</att> attribute. </p>
            <p>For example, consider the following encoding of an emendation in the Hengwrt
               manuscript proposed by E. Talbot Donaldson: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples">Telle me also, to what conclusioun Were
                  membres maad, of generacioun And of so parfit wis a <choice xml:id="corr117"
                        ><sic>wight</sic><corr>wright</corr></choice> ywroght? <!-- ... -->
                  <note target="#corr117">This emendation of the Hengwrt copy text, based on a Latin
                     source and on the reading of three late and usually unauthoritative
                     manuscripts, was proposed by E. Talbot Donaldson in
                           <bibl><title>Speculum</title> 40 (1965) 626–33.</bibl></note>
               </egXML> The <gi>note</gi> element discussed in <ptr target="#CONO"/> may be used to
               give a more detailed discussion of the motivation for or scope of a correction. If
               linked by means of a pointer (as in this example) it may be located anywhere
               convenient within the transcription; typically all detailed notes will be collected
               together in a separate <gi>div</gi> element in the <gi>back</gi>. Alternatively, the
               pointer may be omitted, and the <gi>note</gi> placed immediately adjacent to the
               element being annotated. The advantage of the former solution is that it permits the
               same annotation to refer to several corrections, by supplying more than one pointer
               in the <att>target</att> attribute of the <gi>note</gi>, as shown in the example
               below. </p>
            <p>The attribute <att>cert</att> may be used to indicate the degree of confidence
               ascribed by the encoder to the proposed emendation on a broad scale: high, medium, or
               low. The attribute <att>resp</att> is used to indicate who is responsible for the
               proposed emendation. Its value is a pointer, which will typically indicate a
                  <gi>respStmt</gi> or <gi>name</gi> element in the header of the transcribed
               document, but can point anywhere, for example to some online authority file. Using
               these two attributes, the <gi>corr</gi> element presented above might usefully be
               enhanced as follows: <egXML xmlns="http://www.tei-c.org/ns/Examples">
                  <!-- somewhere in the header ... -->
                  <name xml:id="ETD">E Talbot Donaldson</name>
                  <!-- ... --> And of so parfit wis a <choice><sic>wight</sic><corr resp="#ETD"
                        cert="medium">wright</corr></choice> ywroght? </egXML></p>

            <p>As remarked above, where the same annotation applies to several corrections, this may
               be represented by supplying multiple pointers on the note. Consider for example such
               corrections as the following, in Dudo of S. Quentin. Parkes cites two cases in this
               manuscript of the same phenomenon: <egXML xml:lang="la"
                  xmlns="http://www.tei-c.org/ns/Examples" source="#PH-eg-04">quamuis <choice
                     xml:id="sic-1"><sic>mens</sic><corr>iners</corr></choice> que nutu dei gesta
                  sunt ... unde esset uiriliter <choice xml:id="sic-2"
                        ><corr>uegetata</corr><sic>negata</sic></choice></egXML> which may be
               described as follows: <egXML xmlns="http://www.tei-c.org/ns/Examples"><note
                     target="#sic-1 #sic-2">Substitution of a more familiar word which resembles
                     graphically what the scribe should be copying but which does not make sense in
                     the context.</note></egXML>
            </p>
            <p>The <att>target</att> attribute on the <gi>note</gi> element indicates the
                  <gi>choice</gi> elements which exemplify this kind of scribal error. This
               necessitates the addition of an identifier to each <gi>choice</gi> element. However,
               if the number of corrections is large and the number of notes is small, it may well
               be both more practical and more appropriate to regard the collection of annotations
               as constituting a typology and then use the <att>type</att> attribute. Suppose that
               the note given above is one of half a dozen possible kinds of corrected phenomena
               identified in a given text; others might include, say, <q>repetition of a word from
                  the preceding line</q>, etc. The <att>type</att> attribute on the <gi>corr</gi>
               element can be used to specify an arbitrary code for the particular kind of
               correction (or other editorial intervention) identified within it. This code can be
               chosen freely and is not treated as a pointer. <egXML xml:lang="la"
                  xmlns="http://www.tei-c.org/ns/Examples">quamuis <choice><sic>mens</sic><corr
                        type="graphSubs">iners</corr></choice> que nutu dei gesta sunt ... unde
                  esset uiriliter <choice><corr type="graphSubs"
                     >uegetata</corr><sic>negata</sic></choice></egXML> Note that this encoding
               might be extended to include a range of possible corrections: <egXML xml:lang="la"
                  xmlns="http://www.tei-c.org/ns/Examples">quamuis <choice><sic>mens</sic><corr
                        type="graphSubs">iners</corr><corr type="reversal">inres</corr></choice> que
                  nutu dei gesta sunt ...</egXML> In addition, the conscientious encoder will
               provide documentation explaining the circumstances in which particular codes are
               judged appropriate. A suitable location for this might be within the
                  <gi>correction</gi> element of the <gi>encodingDesc</gi> of the header, which
               might include a <gi>list</gi> such as the following: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples">
                  <correction>
                     <p>The following codes are used to categorize corrections identified in this
                        transcription: <list type="gloss">
                           <label>graphSubs</label>
                           <item>Substitution of a more familiar word which resembles graphically
                              what the scribe should be copying but which does not make sense in the
                              context.</item>
                           <!-- ... -->
                        </list></p></correction></egXML> A <att>subtype</att> attribute may be used
               in conjunction with the <att>type</att> for subclassification purposes: the above
               examples might thus be represented as <tag>choice type="substitution"
                  subtype="graphicResemblance"</tag> for example. </p>
            <p>For a given project, it may well be desirable to limit the possible values for the
                  <att>type</att> or <att>subtype</att> attributes automatically. This is easily
               done but requires customization of the TEI system using techniques described in <ptr
                  target="#MD"/>, in particular <ptr target="#MDMDAL"/>, which should be consulted
               for further information on this topic.</p>
            <p>When making a correction in a source which forms part of a textual tradition attested
               by many witnesses, a textual editor will sometimes use a reading from one witness to
               correct the reading of the source text. In the general case, such encoding is best
               achieved with the mechanisms provided by the module for textual criticism described
               in chapter <ptr target="#TC"/>. However, for simple cases, the <att>source</att>
               attribute of the <gi>corr</gi> element may suffice. In the passage from Chaucer's
                  <title>Wife of Bath's Tale</title> mentioned above, Parkes proposes to emend the
               problematic word <mentioned>wight</mentioned> to <mentioned>wyf</mentioned> which is
               the reading found in the Cambridge manuscript Gg.1. 27. This may be simply
               represented as follows: <egXML xmlns="http://www.tei-c.org/ns/Examples"> And of so
                  parfit wis a <choice><sic>wight</sic><corr resp="#mp" source="#Gg"
                     >wyf</corr></choice> ywroght?</egXML> The value of the <att>source</att>
               attribute here is, like the value of the <att>resp</att> attribute, a pointer, in
               this case indicating the manuscript used as a witness. Elsewhere in the transcribed
               text, a list of witnesses used in this text will be given, one of which has an
               identifier <code>Gg</code>. Each witness will be represented either by a
                  <gi>witness</gi> element (see <ptr target="#TCAPLL"/>) or more fully by a
                  <gi>msDesc</gi> element (see <ptr target="#MS"/>): <egXML
                  xmlns="http://www.tei-c.org/ns/Examples">
                  <msDesc xml:id="Gg">
                     <msIdentifier>
                        <settlement>Cambridge</settlement>
                        <repository>University Library</repository>
                        <idno>Gg.1. 27</idno>
                     </msIdentifier>
                     <!-- further description of the manuscript here -->
                  </msDesc></egXML>
            </p>

            <p>The <gi>app</gi> element described in chapter <ptr target="#TC"/> provides a more
               powerful way of representing all three possible readings in parallel: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples">And of so parfit wis a <app>
                     <rdg wit="#Hg">wight</rdg>
                     <rdg wit="#Ln #Ry2 #Ld">wright</rdg>
                     <rdg wit="#Gg">wyf</rdg>
                  </app></egXML></p>
            <p>This encoding simply records the three readings found in the various traditions, and
               gives (by means of the <att>wit</att> attribute) an indication of the witnesses
               supporting each. If the <att>resp</att> attribute were supplied on the <gi>rdg</gi>
               element, it would indicate the person responsible for asserting that the manuscript
               indicated has this reading, who is not necessarily the same as the person responsible
               for asserting that this reading should be used to correct the others. Editorial
               intervention elements such as <gi>corr</gi> can however be nested within a
                  <gi>rdg</gi> to provide this additional information: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples">And of so parfit wis a <app>
                     <rdg wit="#Hg">wight</rdg>
                     <rdg wit="#Ln #Ry2 #Ld"><corr resp="#ETD">wright</corr></rdg>
                     <rdg wit="#Gg"><corr resp="#mp">wyf</corr></rdg>
                  </app></egXML> This encoding asserts that the reading <mentioned>wyf</mentioned>
               found in Gg is regarded as a correction by Parkes. </p>

            <p>Like the <att>resp</att> attribute, the <att>cert</att> attribute may be used with
               both <gi>corr</gi> and <gi>rdg</gi> elements. When used on the <gi>rdg</gi> element,
               these attributes indicate confidence in and responsibility for identifying the
               reading within the sources specified; when used on the <gi>corr</gi> element they
               indicate confidence in and responsibility for the use of the reading to correct the
               base text. If no other source is indicated (either by the <att>source</att>
               attribute, or by the <att>wit</att> attribute of a parent <gi>rdg</gi>), the reading
               supplied within a <gi>corr</gi> has been provided by the person indicated by the
                  <att>resp</att> attribute. </p>

            <p>If it is desired to express certainty of or responsibility for some other aspect of
               the use of these elements, then the mechanisms discussed in chapter <ptr target="#CE"
               /> may be found useful. See also <ptr target="#PHHR"/> for further discussion of the
               issues of certainty and responsibility in the context of transcription.</p>
         </div>

         <div type="div3" xml:id="PHAD">
            <head>Additions and Deletions</head>

            <p>Additions and deletions observed in a source text may be described using the
               following elements: <specList>
                  <specDesc key="add"/>
                  <specDesc key="addSpan"/>
                  <specDesc key="del"/>
                  <specDesc key="delSpan"/>
               </specList> Of these, <gi>add</gi> and <gi>del</gi> are included in the core module,
               while <gi>addSpan</gi> and <gi>delSpan</gi> are available only when using the module
               defined in this chapter. These particular elements are members of the <ident
                  type="class">att.spanning</ident> class, from which they inherit the following
               attribute: <specList>
                  <specDesc key="att.spanning" atts="spanTo"/>
               </specList>
            </p>

            <p>Further characteristics of each addition and deletion, such as the hand used, its
               effect (complete or incomplete, for example), or its position in a sequence of such
               operations may conveniently be recorded as attributes of these elements, all of which
               are members of the <ident type="class">att.transcriptional</ident> class: <specList>
                  <specDesc key="att.transcriptional" atts="seq status hand"/>
               </specList>
            </p>


            <p>As described in section <ptr target="#COED"/>, the <gi>add</gi> element is used to
               record any manuscript addition observed in the text, whether it is considered to be
               authorial or scribal. In the autograph manuscript of Max Beerbohm's <title>The Golden
                  Drugget</title>, the author's addition of <mentioned>do ever</mentioned> may be
               recorded as follows, with the <att>hand</att> attribute indicating that the addition
               was Beerbohm's by referencing a <gi>handNote</gi> element defined elsewhere in the
               document (see further <ptr target="#PHDH"/>): <egXML
                  xmlns="http://www.tei-c.org/ns/Examples" source="#PH-eg-05">Some things are best
                  at first sight. Others — and here is one of them — <add hand="#mb">do ever</add>
                  improve by recognition .... <handNote xml:id="mb">Max Beerbohm
                     holograph</handNote>
               </egXML>
            </p>

            <p>The <gi>del</gi> element is used to record manuscript deletions in a similar way. In
               the autograph manuscript of D. H. Lawrence's <title>Eloi, Eloi, lama
                  sabachthani</title> the author's deletion of <mentioned>my</mentioned> may be
               recorded as follows. In this case, the <att>hand</att> attribute indicating that the
               deletion was Lawrence's is complemented by a <att>rend</att> attribute indicating
               that the deletion was by strike-through: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples" source="#PH-eg-06">For I hate this <del
                     rend="strikethrough" hand="#dhl">my</del> body, which is so dear to me ...
                     <handNote xml:id="dhl">D H Lawrence holograph</handNote>
               </egXML></p>


            <p>If deletions are classified systematically, the <att>type</att> attribute may be
               useful to indicate the classification; when they are classified by the manner in
               which they were effected, or by their appearance, however, this will lead to a
               certain arbitrariness in deciding whether to use the <att>type</att> or the
                  <att>rend</att> attribute to hold the information. In general, it is recommended
               that the <att>rend</att> attribute be used for description of the appearance or
               method of deletion, and that the <att>type</att> attribute be reserved for higher
               level or more abstract classifications.</p>

            <p>The <att>place</att> attribute is also available to indicate the location of an
               addition. For example, consider the following passage from a draft letter by Robert
               Graves: <figure>
                  <graphic url="Images/PHgraves2.png" width="500px"/>
                  <head>Draft letter from Robert Graves to Desmond Flower, 17 Dec 1938 (detail).
                  </head>
               </figure> At the end of this extract, the writer inserts the word <q>cant,</q> above
               the line, with a stroke to indicate insertion. Assuming that we have previously
               defined the identifier <code>RG</code> somewhere: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples">
                  <listPerson>
                     <person xml:id="RG">
                        <!-- information about Robert Graves here -->
                     </person>
                  </listPerson>
               </egXML>, this extract might now be encoded as follows: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples" source="#PH-eg-07"> The O.E.D. is not a
                  dictionary so much as a corpus of precedents <del hand="#RG">in the</del>:
                  current, obsolete, <add hand="#RG" place="above">cant,</add> cataphretic and
                  nonce-words are all included. </egXML> A little earlier in the same extract,
               Graves writes <q>for an abridgement</q> above the line, and then deletes it. This may
               be encoded similarly: <egXML xmlns="http://www.tei-c.org/ns/Examples"
                  source="#PH-eg-07"> As for 'significant artist.' You quote the O.E.D <del><add
                        hand="#RG" place="above">for an abridgement</add></del> in explanation...
               </egXML> Similarly, in the margin, the word <q>Norton</q> has been added and then
               deleted: <egXML xmlns="http://www.tei-c.org/ns/Examples" source="#PH-eg-07"> You
                  quote the <del><add hand="#RG" place="margin">Norton</add></del> O.E.D...</egXML>
               The word <q>O.E.D.</q> in this first sentence has also clearly been the result of
               some redrafting: it may be that Graves started to write <q>Oxford</q>, and then
               changed it; it may be that he inserted other punctuation marks between the letters
               before replacing them with the centre dots used elsewhere to represent this acronym.
               We do not deal with these possibilities here, and mention them only to indicate that
               any encoding of manuscript material of this complexity will need to make decisions
               about what is and is not worth mentioning. </p>

            <!-- line from the typescript of Eliot's
<title>The Waste Land</title> the word
<mentioned>foe</mentioned> is crossed out, and the word
<mentioned>friend</mentioned> is written in the right margin,
together with an insertion mark. <figure>
<graphic url="Images/PHfigEliot-1.png" width="600px"/></figure>
This line might be encoded as follows:
<egXML xmlns="http://www.tei-c.org/ns/Examples" source="#PH-eg-07">
"Oh keep the Dog far hence, that's <del>foe</del> to men, 
<add place="margin">friend</add></egXML>
The deletion and the addition in this example are in the same hand,
presumably Eliot's. Other deletions in the typescript are in different
hands and done in different ways: for example, at the start of the same
passage: <figure><graphic url="Images/PHfigEliot-2.png" width="600px"/></figure>
The first two lines of this passage might be
encoded as follows:
<egXML xmlns="http://www.tei-c.org/ns/Examples" source="#PH-eg-07">
<l><add place="above">Unreal</add><del rend="overtyped">Terrible</del> City<del resp="#EP">,</del> I have sometimes seen
and see</l>
<l>Under the brown fog of <del resp="#EP" rend="box">your</del> winter
dawn...</l></egXML>
The typescript originally read <q>Terrible City</q>: the first word
was then overtyped with xs to delete it, and the word
<mentioned>Unreal</mentioned> typed above the deletion. Two further
deletions here are attributed to Pound (EP): the comma following
<mentioned>City</mentioned>, and the word <mentioned>your</mentioned>;
the latter deletion being marked by a box drawn around it rather than by
a line through it. </p>
-->
            <!--
"Oh keep the Dog far hence, that's 
<subst><del>foe</del><add place="margin">friend</add></subst> to men, 
</egXML>-->


            <p>An encoder may also wish to indicate that an addition replaces a specific deletion,
               that is to encode a substitution as a single intervention in the text. This may be
               achieved by grouping the addition and deletion together within a <gi>subst</gi>
               element. At the end of the passage illustrated above, Graves first writes <q>It is
                  the expressed...</q>, then deletes <q>It is</q>, and substitutes an uppercase T at
               the start of <q>the</q>. <egXML xmlns="http://www.tei-c.org/ns/Examples"
                  source="#PH-eg-07"> ... are all included. <del hand="#RG">It is</del>
                  <subst><add>T</add><del>t</del></subst>he expressed </egXML> The use of this
               element and of the <att>seq</att> attribute to indicate the order in which
               interventions such as deletions are believed to have occurred are further discussed
               in section <ptr target="#PHSU"/> below. </p>

            <p>The <gi>add</gi> and <gi>del</gi> elements defined in the core module suffice only
               for the description of additions and deletions which fit within the structure of the
               text being transcribed, that is, which each deletion or addition is completely
               contained by the structural element (paragraph, line, division) within which it
               occurs. Where this is not the case, for example because an individual addition or
               deletion involves several distinct structural subdivisions, such as poems or prose
               items, or otherwise crosses a structural boundary in the text being encoded, special
               treatment is needed. The <gi>addSpan</gi> and <gi>delSpan</gi> elements are provided
               by this module for that purpose. (For a general discussion of the issue see further
                  <ptr target="#NH"/>).</p>

            <p>In this example of the use of <gi>addSpan</gi>, the insertion by Helgi Ólafsson of a
               gathering containing four neo-Eddic poems into <title>Lbs 1562 4to</title> is
               recorded as follows. <!-- added clarificatory sentence --> A <gi>handNote</gi>
               element is first declared, within the header of the document, to associate the
               identifier <val>heol</val> with Helgi. Each of the added poems is encoded as a
               distinct <gi>div</gi> element. In the body of the text, an <gi>addSpan</gi> element
               is placed to mark the beginning of the span of added text, and an <gi>anchor</gi> is
               used to mark its end. The <att>hand</att> attribute on the <gi>addSpan</gi> element
               ascribes responsibility for the addition to the manuscript to Helgi, and the
                  <att>spanTo</att> attribute points to the end of the added text: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples" source="#PH-eg-08"><handNote
                     xml:id="heol" scribe="HelgiÓlafsson"/>
                  <!-- ... -->
                  <body>
                     <div><!-- text here --></div>
                     <addSpan n="added gathering" hand="#heol" spanTo="#p025"/>
                     <div><!-- text of first added poem here --></div>
                     <div><!-- text of second added poem here --></div>
                     <div><!-- text of third added poem here --></div>
                     <div><!-- text of fourth added poem here --></div>
                     <anchor xml:id="p025"/>
                     <div><!-- more text here --></div></body>
               </egXML></p>
            <p>The <gi>delSpan</gi> element is used in the same way. An authorial manuscript will
               often contain
               <!-- For example,
in the Eliot typescript mentioned above, there are --> several
               occasions where sequences of whole lines are marked for deletion, either by boxes or
               by being struck out. If the encoder is marking up individual verse lines with the
                  <gi>l</gi> element, such deletions are problematic: deletion of two consecutive
               lines should be regarded as a single deletion, but the <gi>del</gi> element must be
               properly nested within a single <gi>l</gi> element. The <gi>delSpan</gi> element
               solves this problem: <egXML xmlns="http://www.tei-c.org/ns/Examples">
                  <l>Flowed up the hill and down King William Street,</l>
                  <delSpan spanTo="#EPdelEnd" resp="#EP" rend="strikethrough"/>
                  <l>To where Saint Mary Woolnoth kept the time,</l>
                  <l>With a dead sound on the final stroke of nine.</l>
                  <anchor xml:id="EPdelEnd"/>
                  <l>There I saw one I knew, and stopped him, crying "Stetson!</l>... </egXML>
            </p>
            <p>It is also often the case that deletions and additions may themselves contain other
               deletions and additions. For example, in Thomas Moore's autograph of the second
               version of <title>Lalla Rookh</title> two lines are marked for omission by vertical
               strike-through. Within the first of the two lines, the word
                  <mentioned>upon</mentioned> has also been struck out, and the word
                  <mentioned>over</mentioned> has been added: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples" source="#PH-eg-09"><l>
                     <delSpan rend="verticalStrike" spanTo="#delend01"/> Tis moonlight
                        <del>upon</del>
                     <add>over</add> Oman's sky</l>
                  <l>Her isles of pearl look lovelily<anchor xml:id="delend01"/></l></egXML> In this
               case the <gi>anchor</gi> and <gi>delSpan</gi> have been placed within the structural
               elements (the <gi>l</gi>s) rather than between, as in the previous example. This is
               to indicate that placement of these empty elements is arbitrary. </p>
            <p>The text deleted must be at least partially legible, in order for the encoder to be
               able to transcribe it. If all of part of it is not legible, the <gi>gap</gi> element
               should be used to indicate where text has not been transcribed, because it could not
               be. The <gi>unclear</gi> element described in section <ptr target="#PHDA"/> may be
               used to indicate areas of text which cannot be read with confidence. See further
               section <ptr target="#PHOM"/> and section <ptr target="#PHDA"/>.</p>
         </div>

         <div type="div3" xml:id="PHSU">
            <head>Substitutions</head>

            <p>Substitution of one word or phrase for another is perhaps the most common of all
               phenomena requiring special treatment in transcription of primary textual sources. It
               may be simply one word written over the top of another, or deletion of one word and
               its replacement by another written above it by the same hand on the same occasion;
               the deletion and replacement may be done by different hands at different times; there
               may be a long chain of substitutions on the same stretch of text, with uncertainty as
               to the order of substitution and as to which of many possible readings should be
               preferred.</p>
            <p>As we have shown, the simplest method of recording a substitution is simply to record
               both the addition and the deletion. However, when the module defined by this chapter
               is in use, additional elements are available to indicate that the encoder believes
               the addition and the deletion to be part of the same intervention: a substitution. <specList>
                  <specDesc key="subst"/>
                  <specDesc key="substJoin"/>
               </specList> Using the <gi>subst</gi> element, the example at the end of the last
               section might be encoded as follows: <egXML xmlns="http://www.tei-c.org/ns/Examples"><l>
                     <delSpan rend="verticalStrike" spanTo="#delend02"/> Tis moonlight
                           <subst><del>upon</del><add>over</add></subst> Oman's sky</l>
                  <l>Her isles of pearl look lovelily<anchor xml:id="delend02"/></l></egXML> Since
               the purpose of this element is solely to group its child elements together, the order
               in which they are presented is not significant. When both deletion and addition are
               present, it may not always be clear which occurs first: using the <att>seq</att>
               attribute is a simple way of resolving any such ambiguities.</p>

            <p>For example, returning to the example from William James, in a passage first written
               out by James as <q>One must have lived longer with this system, to appreciate its
                  advantages</q>, the word <mentioned>this</mentioned> is first replaced by
                  <mentioned>such a</mentioned> and this is then replaced by
                  <mentioned>a</mentioned>.<note place="bottom">The manuscript contains several
                  other substitutions, ignored here for the sake of clarity.</note> This may be
               encoded as follows, representing the two changes as a sequence of additions and
               deletions: <egXML xmlns="http://www.tei-c.org/ns/Examples">One must have lived longer
                  with <subst><del seq="1">this</del>
                     <del seq="2"><add seq="1">such a</add></del>
                     <add seq="2">a</add></subst> system, to appreciate its advantages.</egXML> Note
               the nesting of an <gi>add</gi> element within a <gi>del</gi> to record text first
               added, then deleted in the source. The numbers assigned by the <att>seq</att>
               attribute may be used to identify the order in which the various additions and
               deletions are believed by the encoder to have been carried out, and thus provide a
               simple method of supporting the kind of <soCalled>genetic</soCalled> textual
               criticism typified by (for example) Hans Walter Gabler's work on the reconstruction
               of the <soCalled>overlay</soCalled> levels implicit in the manuscripts of James
               Joyce's <title>Ulysses</title>. A fuller and more complex way of supporting such an
               approach is discussed in <ptr target="#PH-changes"/>. </p>

            <p> The case of a single substitution or scribal correction that involves non-contiguous
               addition and deletion can be handled by using the <gi>substJoin</gi> element to make
               an explicit connection between one or more <gi>add</gi> and <gi>del</gi> elements. In
               the following example from Thomas Moore's Lalla Rookh, the deletion and addition are
               not contiguous: they are separated by the word <q>thus</q>, which is not part of the
               scribal intervention being marked. Because of this intervening text, it would be
               inappropriate to use <gi>subst</gi> to group this <gi>add</gi> and <gi>del</gi>.
                  <gi>substJoin</gi> allows the encoder to indicate that additions and deletions
               separated in this way are part of a single scribal intervention: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples"> While <del xml:id="change1"
                     >pondering</del> thus <add xml:id="change2">she mus'd</add>, her pinions
                     fann'd<substJoin target="#change1 #change2"/>
               </egXML>
               Note that, unlike <gi>subst</gi>, the placement of the <gi>substJoin</gi> is arbitrary. It may occur before or after the relevant <gi>add</gi> and <gi>del</gi> elements.
            </p>

            <p>As a more complex example, consider the following passage:<!-- in one of the manuscripts
               of Wilfred Owen's <title>Dulce et decorum est</title>:-->
               <figure>
                  <graphic width="450px" url="Images/PHowen.png"/>
                  <head>Detail from <title>Dulce et decorum est</title> autograph manuscript in the
                     English Faculty Library, Oxford University. </head>
               </figure> This passage might be encoded as follows: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples" source="#PH-eg-16">
                  <l>And towards our distant rest began to trudge,</l>
                  <l><subst><del>Helping the worst amongst us</del><add>Dragging the worst amongt
                           us</add></subst>, who'd no boots</l>
                  <l>But limped on, blood-shod. All went lame; <subst><del status="shortEnd"
                           >half-</del><add>all</add></subst> blind;</l>
                  <l>Drunk with fatigue ; deaf even to the hoots</l>
                  <l>Of tired, outstripped <del>fif</del> five-nines that dropped
                  behind.</l></egXML> In this representation, <list rend="bulleted">
                  <item>the authorial slip (<mentioned>amongt</mentioned> for
                        <mentioned>amongst</mentioned>) is retained without comment.</item>
                  <item>the other two authorial corrections are marked as substitutions, each
                     combining a deletion and an addition. </item>
                  <item>the false start <mentioned>fif</mentioned> in the last line is simply marked
                     as a deletion; </item>
               </list>
            </p>
            <p>The <gi>app</gi> element presented in chapter <ptr target="#TC"/> provides similar
               facilities, by treating each state of the text as a distinct reading. The
                  <gi>rdg</gi> element has a <att>varSeq</att> attribute which may be used in the
               same way as the <att>seq</att> attribute to indicate the preferred sequence. The
               James example above might thus be represented as follows: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples">One must have lived longer with <app>
                     <rdg varSeq="1"><del>this</del></rdg>
                     <rdg varSeq="2"><del><add>such a</add></del></rdg>
                     <rdg varSeq="3"><add>a</add></rdg>
                  </app> system, to appreciate its advantages.</egXML>
            </p>
         </div>

         <div type="div3" xml:id="PHCD">
            <head>Cancellation of Deletions and Other Markings</head>
            <p>An author or scribe may mark a word or phrase in some way, and then on reflection
               decide to cancel the marking. For example, text may be marked for deletion and the
               deletion then cancelled, thus restoring the deleted text. Such cancellation may be
               indicated by the <gi>restore</gi> element: <specList>
                  <specDesc key="restore"/>
               </specList></p>
            <p>This element bears the same attributes as the other transcriptional elements. These
               may be used to supply further information such as the hand in which the restoration
               is carried out, the type of restoration, and the person responsible for identifying
               the restoration as such, in the same way as elsewhere. </p>
            <p>Presume that Lawrence decided to restore <mentioned>my</mentioned> to the phrase of
                  <title>Eloi, Eloi, lama sabachthani</title> first written <q>For I hate this my
                  body</q>, with the <mentioned>my</mentioned> first deleted then restored by
               writing <q>stet</q> in the margin. This may be encoded: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples">For I hate this <restore hand="#dhl"
                     type="marginalStetNote"><del>my</del></restore> body</egXML></p>
            <p>Another feature commonly encountered in manuscripts is the use of circles, lines, or
               arrows to indicate transposition of material from one point in the text to another.
               No specific markup for this phenomenon is proposed at this time. Such cases are most
               simply encoded as additions at the point of insertion and deletions at the point of
               encirclement or other marking. </p>
         </div>

         <div type="div3" xml:id="PHOM">
            <head>Text Omitted from or Supplied in the Transcription</head>
            <p>Where text is not transcribed, whether because of damage to the original, or because
               it is illegible, or for some other reason such as editorial policy, the <gi>gap</gi>
               core element may be used to register the omission; where such text is transcribed,
               but the editor wishes to indicate that they consider it to be superfluous, for
               example because it is an inadvertent scribal repetition or an interpolation from another 
               source, the <gi>surplus</gi> element may be used in preference. Where the editor believes 
               text to be interpolated but genuine, the <gi>secl</gi> element may be used instead. 
               Where text not present in the source is supplied (whether
               conjecturally or from other witnesses) to fill an apparent gap in the text, the
                  <gi>supplied</gi> element may be used. <specList>
                  <specDesc key="gap" atts="reason hand agent"/>
                  <specDesc key="surplus" atts="reason"/>
                  <specDesc key="secl" atts="reason"/>
                  <specDesc key="supplied" atts="reason"/>
               </specList></p>
            <p>By its nature, the <gi>gap</gi> element has no content. It marks a point in the text
               where nothing at all can be read, whether because of authorial or scribal erasure,
               physical damage, or any other form of illegibility. Its attributes allow the encoder
               to specify the amount of text which is illegible in this way at this point, using any
               convenient units, where this can be determined. For example, in the Beerbohm
               manuscript of <title>The Golden Drugget</title> cited above, the author has erased a
               passage amounting about 10 cm in length by inking over it completely: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples" source="#PH-eg-05">Others <gap
                     reason="cancelled" hand="#mb" quantity="10" unit="cm"/>—and here is one of
                  them...</egXML></p>
            <p>In an autograph letter of Sydney Smith now in the Pierpont Morgan library three words
               in the signature are quite illegible: <egXML xmlns="http://www.tei-c.org/ns/Examples"
                  source="#PH-eg-10">I am dr Sr yr <gap reason="illegible" quantity="3" unit="word"
                  />Sydney Smith</egXML> The degree of precision attempted when measuring the size
               of a gap will vary with the purpose of the encoding and the nature of the material:
               no particular recommendation is made here.</p>

            <p>As noted above, the <gi>gap</gi> element should only be used where text has not been
               transcribed. If partially legible text has been transcribed, one of the elements
                  <gi>damage</gi> and <gi>unclear</gi> should be used instead (these elements are
               described in section <ptr target="#PHDA"/>); if the text is legible and has been
               transcribed, but the editor wishes to indicate that they regard it is superfluous or
               redundant, then the element <gi>surplus</gi> may be used in preference to the core
               element <gi>sic</gi> used to indicate text regarded as erroneous. </p>

            <p>Amongst the many examples cited in Hans Krummrey &amp; Silvio Panciera's classic text
               on the editing of epigraphic inscriptions is the following. In a late classical
               inscription, the form <soCalled>dedikararunt</soCalled> is encountered. The editor
               may choose any of the following three possibilities:
	    </p>
	    <list>
                  <item>mark this as an erroneous form <egXML
                        xmlns="http://www.tei-c.org/ns/Examples" source="#PHegsurp">
                        <sic>dedikararunt</sic>
                     </egXML></item>
                  <item>additionally supply a corrected form <egXML
                        xmlns="http://www.tei-c.org/ns/Examples" source="#PHegsurp">
                        <choice><sic>dedikararunt</sic>
                           <corr>dedikarunt</corr>
                        </choice>
                     </egXML></item>
                  <item>indicate that the erroneous form contains surplus characters which the
                     editor wishes to suppress <egXML xmlns="http://www.tei-c.org/ns/Examples"
                        source="#PHegsurp"> dedika<surplus>ra</surplus>runt </egXML></item>
               </list>

            <p>The <gi>surplus</gi> element may also be used to mark up interpolations, as in the
               following example taken from a 13th century Italian source: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples" source="#PHegsurp2">
                  <l n="4">a darmi morte, poi m'avete preso <surplus reason="interpolated">a
                        tradimento</surplus></l>
                  <l n="5">sì com' l'uccellator prende l'uccello</l>
                  <gap/>
                  <l n="43">e lettere dintorno che diriano <surplus reason="interpolated">in questa
                        guisa</surplus></l>
                  <l n="44">Più v'amo, dëa, che non faccio Deo</l>
               </egXML> The words marked as <gi>surplus</gi> here are metrically inconsistent with
               the rest and have been marked by the editor as such. </p>
           
           <p>In the case of an interpolation which the editor regards as genuine (i.e. written by 
             the author in question), but out of its original place, the <gi>secl</gi> element should 
             be used instead of <gi>surplus</gi>. For example:
             <egXML xmlns="http://www.tei-c.org/ns/Examples" source="#PHOM-eg-secl" xml:space="preserve">
<sp>
  <ab>
    <lb n="545"/>Great praise and thanks be to Perfidy as she
    <lb n="546"/>deserves, since by our swindles, tricks, and clever moves, relying 
    <lb n="547"/>on the daring of our shoulder blades and the excellence of our 
    <lb n="548"/>forearms who went against cattle-prods, hot iron-blades, 
    <lb n="549-550"/>crosses and shackles, neck-irons, chains, prisons, collars, fetters, 
    <lb n="551"/>and yokes, the fiercest painters fully acquainted with our backs 
    <lb n="552"/><secl>who have often before put scars on our shoulder blades</secl>
    ...
  </ab>
</sp>
           </egXML> The final line is bracketed in the Loeb edition, with a note: <q>versum secl. Bothe</q>,
             meaning Bothe regarded this line as Plautine, but probably interpolated. It is easy to see how 
             the line might have crept in as a gloss on the metaphor in the previous line.
           </p>

            <p>If some part of the source text is completely illegible or missing, an encoder may
               sometimes wish to supply new (conjectural) material to replace it. This conjectural
               reading is analogous to a correction in that it contains text provided by the encoder
               and not attested in the source. This is not however a correction, since no error is
               necessarily present in the original; for that reason a different element
                  <gi>supplied</gi> should be used. If another (imaginary) copy of the letter above
               preserved the signature as reading <q>I am dear Sir your very humble Servt Sydney
                  Smith</q>, the text illegible in the autograph might be supplied in the
               transcription: <egXML xmlns="http://www.tei-c.org/ns/Examples">I am dr Sr yr
                     <supplied reason="illegible" resp="#msm" source="#Ry2">very humble
                     Servt</supplied> Sydney Smith</egXML> Here the <att>source</att> and
                  <att>resp</att> attributes are used, as elsewhere, to indicate respectively the
               sigil of a manuscript from which the supplied reading has been taken, and the
               identifier of the person responsible for deciding to supply the text. If the
                  <att>source</att> attribute is not supplied, the implication is that the encoder
               (or whoever is indicated by the value of the <att>resp</att> attribute) has supplied
               the missing reading. Both <gi>gap</gi> and <gi>supplied</gi> may be used in
               combination with <gi>unclear</gi>, <gi>damage</gi>, and other elements; for
               discussion, see section <ptr target="#PHCOMB"/>.</p>
         </div>
      </div>

      <div type="div2" xml:id="PHPH">
         <head>Hands and Responsibility</head>
         <p>This section discusses in more detail the representation of aspects of responsibility
            perceived or to be recorded for the writing of a primary source. These include points at
            which one scribe takes over from another, or at which ink, pen, or other characteristics
            of the writing change. A discussion of the usage of the <att>hand</att>,
            <att>resp</att>, and <att>cert</att> attributes is also included. </p>
         <div type="div3" xml:id="PHDH">
            <head>Document Hands</head>

            <p>For many text-critical purposes it is important to signal the person responsible (the
                  <term>hand</term>) for the writing of a whole document, a stretch of text within a
               document, or a particular feature within the document. A hand, as the name suggests,
               need not necessarily be identified with a particular known (or unknown) scribe or
               author; it may simply indicate a particular combination of writing features
               recognized within one or more documents. The examples given above of the use of the
                  <att>hand</att> attribute with coding of additions and deletions illustrate this. </p>

            <p>The <gi>handNote</gi> element is used to provide information about each hand
               distinguished within the encoded document. <specList>
                  <specDesc key="handNote"/>
               </specList>
            </p>

            <p>A <gi>handNote</gi> element, with an identifier given by its <att>xml:id</att>
               attribute, may appear in either of two places in the TEI header, depending on which
               modules are included in a schema. When the <ident type="module">transcr</ident>
               module defined by the present chapter is used, the element <gi>handNotes</gi> is
               available, within the <gi>profileDesc</gi> element of the TEI header, to hold one or
               more <gi>handNote</gi> elements. When the <ident type="module">msdescription</ident>
               module defined in chapter <ptr target="#MS"/> is included, the <gi>handDesc</gi>
               element described in <ptr target="#msph2"/> also becomes available as part of a
               structured manuscript description. The encoder may choose to place <gi>handNote</gi>
               elements identifying individual hands in either location without affecting their
               accessibility since the element is always addressed by means of its <att>xml:id</att>
               attribute. The <gi>handDesc</gi> element may be more appropriate when a full
               cataloguing of each manuscript is required; the <gi>handNotes</gi> element if only a
               brief characterization of each hand is needed. It is also possible to use the two
               elements together if, for example, the <gi>handDesc</gi> element contains a single
               summary describing all the hands discursively, while the <gi>handNotes</gi> element
               gives specific details of each. The choice will depend on individual encoders'
               priorities.</p>

            <p>As shown above, the <att>hand</att> attribute is available on several elements to
               indicate the hand in which the content of the element (usually a deletion or
               addition) is carried out. The <gi>handShift</gi> element may also be used within the
               body of a transcription to indicate where a change of hand is detected for whatever
               reason. <specList>
                  <specDesc key="handShift"/>
               </specList>
            </p>
            <p>Both <gi>handShift</gi> and <gi>handNote</gi> are members of the <ident type="class"
                  >att.handFeatures</ident> class, and thus share the following attributes: <specList>
                  <specDesc key="att.handFeatures"
                     atts="scribe script scribeRef
				       scriptRef medium scope"/>
               </specList>
            </p>

            <p>A single hand may employ different writing styles and inks within a document, or may
               change character. For example, the writing style might shift from <q>anglicana</q> to
                  <q>secretary</q>, or the ink from blue to brown, or the character of the hand may
               change. Simple changes of this kind may be indicated by assigning a new value to the
               appropriate attribute within the <gi>handShift</gi> element. It is for the encoder to
               decide whether a change in these properties of the writing style is so marked as to
               require treatment as a distinct hand.</p>
            <p>Where such a change is to be identified, the <att>new</att> attribute indicates the
               hand applicable to the material following the <gi>handShift</gi>. The sequence of
               such <gi>handShift</gi> elements will often, but not necessarily, correspond with the
               order in which the material was originally written. Where this is not the case, the
               facilities described in section <ptr target="#PH-changes"/> may be found helpful. </p>

            <p> As might be expected, a single hand may also vary renditions within the same writing
               style, for example medieval scribes often indicate a structural division by
               emboldening all the words within a line. Such changes should be indicated by use of
               the <att>rend</att> attribute, in the same manner as underlining, emboldening, font
               shifts, etc. are represented in transcription of a printed text, rather than by
               introducing a new <gi>handShift</gi> element.</p>

            <p>In the following example there is a change of ink within a single hand. This is
               simply indicated by a new value for the <att>medium</att> attribute on the
                  <gi>handShift</gi> element: <egXML xmlns="http://www.tei-c.org/ns/Examples"
                  source="#PH-eg-11"><l>When wolde the cat dwelle in his ynne</l>
                  <handShift medium="greenish-ink"/>
                  <l>And if the cattes skynne be slyk <handShift medium="black-ink"/> and
                  gaye</l></egXML></p>

            <p>In the following example, the encoder has identified two distinct hands within the
               document and given them identifiers <val>h1</val> and <val>h2</val>, by means of the
               following declarations included in the document's TEI header: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples">
                  <handNotes>
                     <handNote xml:id="h1" script="copperplate" medium="brown-ink">Carefully written
                        with regular descenders</handNote>
                     <handNote xml:id="h2" script="print" medium="pencil">Unschooled
                        scrawl</handNote>
                  </handNotes>
               </egXML>
            </p>
            <p>Then the change of hand is indicated in the text: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples" source="#PH-eg-12"><handShift new="#h1"
                     resp="#das"/>... and that good Order Decency and regular worship may be once
                  more introduced and Established in this Parish according to the Rules and
                  Ceremonies of the Church of England and as under a good Consciencious and sober
                  Curate there would and ought to be <handShift new="#h2" resp="#das"/> and for that
                  purpose the parishioners pray</egXML></p>

            <p>When a more precise or nuanced discussion of the writing in a manuscript is required,
               the <gi>handNote</gi> and <gi>scriptNote</gi> elements discussed in <ptr
                  target="#msph2"/> should be used. Either element may serve as the target for a
                  <gi>handShift</gi>. </p>

         </div>

         <div type="div3" xml:id="PHHR">
            <head>Hand, Responsibility, and Certainty Attributes</head>

            <p>The <att>hand</att> and <att>resp</att> attributes have similar, but not identical,
               meanings. Observe their distinctive uses in the following encoding of the William
               James passage mentioned above in section <ptr target="#PHCC"/>. In this example, the
                  <mentioned>But</mentioned> inserted by James is tagged as an <gi>add</gi>, and the
               consequent editorial correction of <mentioned>One</mentioned> to
                  <mentioned>one</mentioned> treated separately: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples"><add place="above" resp="#FB" hand="#WJ"
                     >But</add>
                  <choice><sic>One</sic><corr resp="#FB">one</corr></choice> must have lived ... <!-- elsewhere -->
                  <respStmt xml:id="FB">
                     <resp>editorial changes</resp>
                     <name>Fredson Bowers</name>
                  </respStmt>
                  <respStmt xml:id="WJ">
                     <resp>authorial changes</resp>
                     <name>William James</name>
                  </respStmt>
               </egXML> As in this example, <att>hand</att> should be reserved for indicating the
               hand of any form of marking—here, addition but also deletion, correction, annotation,
               underlining, etc.—within the primary text being transcribed. The scribal or authorial
               responsibility for this marking may be inferred from the value of the <att>hand</att>
               attribute. The value of the <att>hand</att> attribute should be a pointer to a hand
               identifiers typically declared in the document header but potentially in another
               document or repository (see section <ptr target="#PHDH"/>).</p>
            <p>The <att>resp</att> attribute, by contrast, indicates the person responsible for
               deciding to mark up this part of the text with this particular element. In the case
               of the <gi>add</gi> element, for example, the <att>resp</att> attribute will indicate
               the responsibility for identifying that the addition is indeed an addition, and also
               (if the <att>hand</att> attribute is supplied) to which hand it should be attributed.
               In this case, Bowers is credited with identifying the hand as that of William James.
               In the case of the <gi>corr</gi> element, the <att>resp</att> attribute indicates who
               is responsible for supplying the intellectual content of the correction reported in
               the transcription: here, Bowers' correction of <q>One</q> to <q>one</q>. In the case
               of a deletion, the <att>resp</att> attribute will similarly indicate who bears
               responsibility for identifying or categorizing the deletion itself, while other
               attributes (<att>hand</att> most obviously) attribute responsibility for the deletion
               itself.</p>

            <p><!--As these examples show, the field of application of the
<att>resp</att> attributes varies from element to element.  In some
cases, it applies to the content of the element (<gi>corr</gi>, 
<gi>ex</gi>, and <gi>supplied</gi>); in others it applies to the value of a particular
attribute (<gi>sic</gi>, <gi>abbr</gi>, <gi>del</gi>, etc.).  In all-->
               In cases where both the <att>resp</att> and <att>cert</att> attributes are defined
               for a particular element, the two attributes refer to the same aspect of the markup.
               The one indicates who is intellectually responsible for some item of information, the
               other indicates the degree of confidence in the information. Thus, for a correction,
               the <att>resp</att> attribute signifies the person responsible for supplying the
               correction, while the <att>cert</att> attribute signifies the degree of editorial
               confidence felt in that correction. For the expansion of an abbreviation, the
                  <att>resp</att> attribute signifies the person responsible for supplying the
               expansion and the <att>cert</att> attribute signifies the degree of editorial
               confidence felt in the expansion.</p>
            <p>This close definition of the use of the <att>resp</att> and <att>cert</att>
               attributes with each element is intended to provide for the most frequent
               circumstances in which encoders might wish to make unambiguous statements regarding
               the responsibility for and certainty of aspects of their encoding. The
                  <att>resp</att> and <att>cert</att> attributes, as so defined, give a convenient
               mechanism for this. However, there will be cases where it is desirable to state
               responsibility for and certainty concerning other aspects of the encoding. For
               example, one may wish in the case of an apparent addition to state the responsibility
               for the use of the <gi>add</gi> element, rather than the responsibility for
               identifying the hand of the addition. It may also be that one editor may make an
               electronic transcription of another editor's printed transcription of a manuscript
               text—here, one will wish to assign layers of responsibility, so as to allow the
               reader to determine exactly what in the final transcription was the responsibility of
               each editor. In these complex cases of divided editorial responsibility for and
               certainty concerning the content, attributes, and application of a particular
               element, the more general mechanisms for representing certainty and responsibility
               described in chapter <ptr target="#CE"/> should be used.</p>
            <!--
<p>The fields of reference of the <att>resp</att> and <att>cert</att>
attributes for each element have been chosen to enable what are felt as
the most frequent likely statements an encoder may wish to make
concerning the areas of responsibility and certainty related to that
element.  It is open to each local transcription scheme to vary the use
of the <att>resp</att> and <att>cert</att> attributes on particular
elements where it is felt convenient.  This practice should be
documented in the <gi>encodingDesc</gi> element in the file header.
Further, it is recommended that before interchange any such local usage
of these attributes be converted to conformancy with the definitions of
the <att>resp</att> and <att>cert</att> attributes given in these
<title>Guidelines</title>.  Use of the <att>resp</att> and
<att>cert</att> in interchange documents in ways not here defined may
lead to unpredictable results.</p>
-->
            <p>It should be noted that the certainty and responsibility mechanisms described in
               chapter <ptr target="#CE"/> replicate all the functions of the <att>resp</att> and
                  <att>cert</att> attributes on particular elements. For example, the encoding of
               Donaldson's conjectured emendation of <mentioned>wight</mentioned> to
                  <mentioned>wright</mentioned> in line 117 of Chaucer's <title>Wife of Bath's
                  Prologue</title> (see <ptr target="#PHCC"/>) may be encoded as follows using the
                  <att>resp</att> and <att>cert</att> attributes on the <gi>corr</gi> element:
                  <egXML xmlns="http://www.tei-c.org/ns/Examples">
                  <choice><sic>wight</sic><corr resp="#ETD" cert="medium"
                  >wright</corr></choice></egXML> Exactly the same information could be conveyed
               using the certainty and responsibility mechanisms, as follows: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples">
                  <choice><corr xml:id="c117">wright</corr><sic>wight</sic></choice>
                  <certainty target="#c117" locus="value" degree="0.7"/>
                  <respons target="#c117" locus="value" resp="#ETD"/></egXML> The choice of which
               mechanism to use is left to the encoder. In transcriptions where only such statements
               of responsibility and certainty are made as can be accommodated within the
                  <att>resp</att> and <att>cert</att> attributes of particular elements, it will be
               economical to use the <att>resp</att> and <att>cert</att> attributes of those
               elements. Where many statements of responsibility and certainty are made which cannot
               be so accommodated, it may be economical to use the <gi>respons</gi> and
                  <gi>certainty</gi> elements throughout.</p>
            <p>The above discussion supposes that in each case an encoder is able to specify exactly
               what it is that one wishes to state responsibility for and certainty about.
               Situations may arise when an encoder wishes to make a statement concerning certainty
               or responsibility but is unable or unwilling to specify so precisely the domain of
               the certainty or responsibility. In these cases, the <gi>note</gi> element may be
               used with the <att>type</att> attribute set to <q>cert</q> or <q>resp</q> and the
               content of the note giving a prose description of the state of affairs.</p>
         </div>
      </div>

      <div xml:id="PHDAMCON">
         <head>Damage and Conjecture</head>
         <p>The carrier medium of a primary source may often sustain physical damage which makes
            parts of it hard or impossible to read. In this section we discuss elements which may be
            used to represent such situations and give recommendations about how these should be
            used in conjunction with the other related elements introduced previously in this
            chapter. </p>


         <div type="div3" xml:id="PHDA">
            <head>Damage, Illegibility, and Supplied Text</head>
            <p>The <gi>gap</gi> and <gi>supplied</gi> elements described above (section <ptr
                  target="#PHOM"/>) should be used with appropriate attributes where the degree of
               damage or illegibility in a text is such that nothing can be read and the text must
               be either omitted or supplied conjecturally or from one or more other sources. In
               many cases, however, despite damage or illegibility, the text may yet be read with
               reasonable confidence. In these cases, the following elements should be used: <specList>
                  <specDesc key="damage"/>
                  <specDesc key="damageSpan"/>
               </specList> As members of the class <ident type="class">att.damaged</ident>, these
               elements bear the following attributes: <specList>
                  <specDesc key="att.damaged" atts="hand agent degree group"/>
               </specList> The class <ident type="class">att.damaged</ident> is a subclass of the
               class <ident type="class">att.dimensions</ident>, itself a subclass of the class
                  <ident type="class">att.ranging</ident>. Consequently these elements also
               therefore bear at least the following attributes: <specList>
                  <specDesc key="att.dimensions" atts="extent unit quantity"/>
                  <specDesc key="att.ranging" atts="min max atLeast atMost"/>
               </specList> From the <ident type="class">att.spanning</ident> class,
                  <gi>damageSpan</gi> inherits the following additional attribute: <specList>
                  <specDesc key="att.spanning" atts="spanTo"/>
               </specList>
            </p>
            <p>The following examples all refer to the recto of folio 5 of the unique manuscript of
               the Elder Edda. Here, the manuscript of <title>Vóluspá</title> has been damaged
               through irregular rubbing so that letters in various places are obscured and in some
               cases cannot be read at all. </p>
            <p>In the first line of this leaf, the transcriber may believe that the last three
               letters of <mentioned>daga</mentioned> can be read clearly despite the damage: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples" source="#PH-eg-13" xml:lang="non">um aldr
                     d<damage>aga</damage> yndisniota</egXML>
            </p>
            <p>If, as is often the case, the damage crosses structural divisions, so that the
                  <gi>damage</gi> element cannot be nested properly within the containing
                  <gi>div</gi> elements, the <gi>damageSpan</gi> element may be used, in the same
               way as the <gi>delSpan</gi> and <gi>addSpan</gi> elements discussed in section <ptr
                  target="#PHAD"/>. <egXML xmlns="http://www.tei-c.org/ns/Examples"
                  source="#PH-eg-13"><p>
                     <!-- ... -->
                     <pb n="5r"/>
                     <damageSpan agent="rubbing" extent="whole leaf" spanTo="#damageEnd"/>
                  </p>
                  <p> .... </p>
                  <p> .... <pb n="5v" xml:id="damageEnd"/>
                  </p></egXML> Note that in this example the <att>spanTo</att> element points to the
               next <gi>pb</gi> element rather than to an inserted <gi>anchor</gi> element, since it
               is the whole of the leaf (the text between the two <gi>pb</gi> elements) which has
               sustained damage. For other techniques of handling non-nesting information, see
               chapter <ptr target="#NH"/>.</p>
            <p>If, as is also likely, the damage affects several disjoint parts of the text, each
               such part must be marked with a separate <gi>damage</gi> or <gi>damageSpan</gi>
               element. To indicate that each of these is to be regarded as forming part of the same
               damaged area, the <att>group</att> attribute may be used as in the following example.
               In this (imaginary) text of Fitzgerald's translation from Omar Khayam, water damage
               has affected an area covering parts of several lines: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples"><l> The Moving Finger wri<damage
                        agent="water" group="1">es; and</damage> having writ,</l>
                  <l>Moves <damage agent="water" group="1">on: nor all your</damage> Piety nor
                     Wit</l>
                  <l><damageSpan agent="water" group="1" spanTo="#washOut"/>Shall lure it back to
                     cancel half a Line,</l>
                  <l>Nor all your Tears wash <anchor xml:id="washOut"/> out a Word of it</l>
               </egXML>
            </p>
            <p>A more general solution to this problem is provided by the <gi>join</gi> element
               discussed in <ptr target="#SAAG"/> which may be used to link together arbitrary
               elements of any kind in the transcription. Here, several phenomena of illegibility
               and conjecture all result from a single cause: an area of damage to the text caused
               by rubbing at various points. The damage is not continuous, and affects the text at
               irregular points. In cases such as this, the join element may be used to indicate
               which tagged features are part of the same physical phenomenon. </p>

            <p>If the damage has been so severe as to render parts of the text only imperfectly
               legible, the <gi>unclear</gi> element should be used to mark the fact. Returning to
               the Eddic example above, an encoder less confident in the <mentioned>daga</mentioned>
               reading might indicate this as follows: <egXML xml:lang="mul"
                  xmlns="http://www.tei-c.org/ns/Examples">um aldr d<unclear reason="damage"
                     >aga</unclear> yndisniota</egXML></p>
            <p>If it is desired to supply more information about the kind of damage, it is also
               possible to nest an <gi>unclear</gi> element within the <gi>damage</gi> element:
                  <egXML xml:lang="mul" xmlns="http://www.tei-c.org/ns/Examples">um aldr d<damage
                     agent="rubbing"><unclear>aga</unclear></damage> yndisniota</egXML></p>
            <p>Alternatively, the transcriber may not feel able to read the last three letters of
                  <mentioned>daga</mentioned> but may wish to supply them by conjecture. Note the
               use of the <att>resp</att> attribute to assign the conjecture to Finnur Jónsson:
                  <egXML xml:lang="mul" xmlns="http://www.tei-c.org/ns/Examples" source="#PH-eg-13"
                  >um aldr d<supplied reason="rubbing" resp="#finjon">aga</supplied>
                  yndisniota</egXML> The <gi>supplied</gi> element may if desired be enclosed within
               a <gi>damage</gi> element: <egXML xml:lang="mul"
                  xmlns="http://www.tei-c.org/ns/Examples" source="#PH-eg-13">um aldr d<damage
                     agent="rubbing"><supplied source="#msm">aga</supplied></damage>
                  yndisniota</egXML></p>
            <p>Contrast the use of <gi>gap</gi> in the next line, where the transcriber believes
               that four letters cannot be read at all because of the damage: <egXML xml:lang="mul"
                  xmlns="http://www.tei-c.org/ns/Examples" source="#PH-eg-13">þar komr inn dimmi
                  dreki fliugandi naþr frann neþan <gap reason="illegible" agent="rubbing"
                     quantity="4" unit="letter"/></egXML> As with <gi>supplied</gi>, this
                  <gi>gap</gi> might be enclosed by a <gi>damage</gi> element.</p>
            <p>Where elements are nested in this way, information about agency, etc. is by default
               inherited. In the following imaginary example, there is a smoke-damaged part within
               which two stretches can be read with some difficulty, and a third stretch which
               cannot be read at all: <egXML xmlns="http://www.tei-c.org/ns/Examples"><damage
                     agent="smoke">
                     <unclear>and the proof of this is</unclear>
                     <gap/>
                     <unclear>margin</unclear>
                  </damage>
               </egXML>
            </p>
            <p>The above examples record imperfect legibility due to damage. When imperfect
               legibility is due to some other reason (typically because the handwriting is
               ill-formed), the <gi>unclear</gi> element should be used without any enclosing
                  <gi>damage</gi> element. In Robert Southey's autograph of <title>The Life of
                  Cowper</title> the final six letters of <mentioned>attention</mentioned> are
               difficult to read because of the haste of the writing, though reasonably certain from
               the context. <egXML xmlns="http://www.tei-c.org/ns/Examples" source="#PH-eg-14">and
                  from time to time invited in like manner his att<unclear>ention</unclear></egXML>
               The <att>cert</att> attribute on the <gi>unclear</gi> element may be used to indicate
               the level of editorial confidence in the reading contained within it.</p>
         </div>
         <div type="div3" xml:id="PHCOMB">
            <head>Use of the <gi>gap</gi>, <gi>del</gi>, <gi>damage</gi>, <gi>unclear</gi>, and
                  <gi>supplied</gi> Elements in Combination</head>
            <p>The <gi>gap</gi>, <gi>damage</gi>, <gi>unclear</gi>, <gi>supplied</gi>, and
                  <gi>del</gi> elements may be closely allied in their use. For example, an area of
               damage in a primary source might be encoded with any one of the first four of these
               elements, depending on how far the damage has affected the readability of the text.
               Further, certain of the elements may nest within one another. The examples given in
               the last sections illustrate something of how these elements are to be distinguished
               in use. This may be formulated as follows: <list rend="bulleted">
                  <item>where the text has been rendered completely illegible by deletion or damage
                     and no text is supplied by the editor in place of what is lost: place an empty
                        <gi>gap</gi> element at the point of deletion or damage. Use the
                        <att>reason</att> attribute to state the cause (damage, deletion, etc.) of
                     the loss of text.</item>
                  <item>where the text has been rendered completely illegible by deletion or damage
                     and text is supplied by the editor in place of what is lost: surround the text
                     supplied at the point of deletion or damage with the <gi>supplied</gi> element.
                     Use the <att>reason</att> attribute to state the cause (damage, deletion, etc.)
                     of the loss of text leading to the need to supply the text.</item>
                  <item>where the text has been rendered partly illegible by deletion or damage so
                     that the text can be read but without perfect confidence: transcribe the text
                     and surround it with the <gi>unclear</gi> element. Use the <att>reason</att>
                     attribute to state the cause (damage, deletion, etc.) of the uncertainty in
                     transcription and the <att>cert</att> attribute to indicate the confidence in
                     the transcription.</item>
                  <item>where there is deletion or damage but at least some of the text can be read
                     with perfect confidence: transcribe the text and surround it with the
                        <gi>del</gi> element (for deletion) or the <gi>damage</gi> element (for
                     damage). Use appropriate attribute values to indicate the cause and type of
                     deletion or damage. Observe that the <att>degree</att> attribute on the
                        <gi>damage</gi> element permits the encoding to show that a letter, word, or
                     phrase is not perfectly preserved, though it may be read with
                     confidence.</item>
                  <item>where there is an area of deletion or damage and parts of the text within
                     that area can be read with perfect confidence, other parts with less
                     confidence, other parts not at all: in transcription, surround the whole area
                     with the <gi>del</gi> element (for deletion; or the <gi>delSpan</gi> element
                     where it crosses a structural boundary); or the <gi>damage</gi> element (for
                     damage). Text within the damaged area which can be read with perfect confidence
                     needs no further tagging. Text within the damaged area which cannot be read
                     with perfect confidence may be surrounded with the <gi>unclear</gi> element.
                     Places within the damaged area where the text has been rendered completely
                     illegible and no text is supplied by the editor may be marked with the
                        <gi>gap</gi> element. For each element, one may use appropriate attribute
                     values to indicate the cause and type of deletion or damage and the certainty
                     of the reading.</item>
               </list></p>
            <p>The rules for combinations of the <gi>add</gi> and <gi>del</gi> elements, and for the
               interpretation of such combinations, are similar: </p>
	       <list rend="bulleted">
                  <item>if one <gi>add</gi> element (with identifier <ident>ADD1</ident>) contains
                     another (with identifier <ident>ADD2</ident>), then the addition
                        <ident>ADD1</ident> was first made to the text, and later a second addition
                        (<ident>ADD2</ident>) was made within that added text: <egXML
                        xmlns="http://www.tei-c.org/ns/Examples">This is the text <add xml:id="ADD1"
                           >with some added <add xml:id="ADD2">(interlinear!)</add> material</add>
                        as written.</egXML></item>
                  <item>if one <gi>del</gi> element contains another, and the <att>seq</att>
                     attribute does not indicate otherwise, it should be assumed that the inner
                     deletion was made before the enclosing one. In the following example, the word
                        <mentioned>redundant</mentioned> was deleted before a second deletion
                     removed the entire passage: <egXML xmlns="http://www.tei-c.org/ns/Examples"
                           ><del>This sentence contains some <del>redundant</del> unnecessary
                           verbiage.</del></egXML></item>
                  <item>if a <gi>del</gi> element contains an <gi>add</gi> element, the normal
                     interpretation will be that an addition was made within a passage which was
                     later deleted in its entirety: <egXML xmlns="http://www.tei-c.org/ns/Examples"
                           ><del>This sentence was deleted <add>originally</add> from the
                           text.</del></egXML></item>
                  <item>if an <gi>add</gi> element contains a <gi>del</gi> element, the normal
                     interpretation will be that a deletion was made from a passage which had
                     earlier been added: <egXML xmlns="http://www.tei-c.org/ns/Examples"><add>This
                           sentence was added <del>eventually</del> to the
                     text.</add></egXML></item>
               </list>
         </div>
      </div>


      <div xml:id="alterations">
         <head>Marking up the Writing Process</head>
         <p>Modifications of various kinds (correction, addition, deletion, etc.) are frequently
            found within a single document, and may also be inferred when different documents are
            compared, although it may be an open question as to whether inter-document discrepancies
            <!-- at the
   dossier level --> should be regarded in the same way as intra-document
            alterations. When two witnesses are collated, we may observe that a word present in one
            is missing from the other: this does not necessarily imply that the word was added to
            the first witness, nor that it was deleted from the other. </p>

         <p>In this section we discuss a number of elements which may be useful when attempting to
            record traces of the writing process within a document. </p>

         <div xml:id="PH-mod">
            <head>Generic Modification</head>



            <p>Most, if not all, transcriptional elements imply a certain level of semantic
               interpretation. For instance, using the <gi>add</gi> element to encode a word or
               phrase that occupies interlinear space involves a decision that it has been
               deliberately inserted as an addition rather than an alternative, and indeed a
               judgment that it was written after, rather than before, the other lines. Where it is
               felt desirable to keep the recording of <soCalled>what is on the page</soCalled>
               entirely separate from <soCalled>what is the editor’s interpretation</soCalled>, the
               generic <gi>mod</gi> element may be preferred. <specList>
                  <specDesc key="mod"/>
               </specList> This element simply indicates any kind of modification that has been
               identified in the document, without prejudice as to its function. Occurrences of the
                  <gi>mod</gi> element may be categorized by means of their <att>type</att>
               attribute, and visual aspects of their appearance can be described by means of the
                  <att>rend</att> attribute, but they provide no further interpretation of the
               function or intention of the passage so marked up. The <att>spanTo</att> attribute
               may be used to indicate the end of a modified passage if this extends across the
               boundaries of some other XML element, for example from the middle of one line tagged
               as a <gi>line</gi> to the middle of another <gi>line</gi> some distance further on in
               the document. </p>
            <egXML xmlns="http://www.tei-c.org/ns/Examples">
               <line>words words words <mod rend="wavy-underlining" spanTo="#enduw"/>words with wavy
                  underline</line> &lt;!-- more lines here --> <line>wavy underlining finishes
                     here<anchor xml:id="enduw"/> more words</line>
            </egXML>
            <!-- QUERY real example needed -->
            <!-- also more discussion of spanTo -->

            <p>The distinction between an example such as that above and the simple use of
                  <gi>hi</gi> to mark the visual salience of the underlining (apart from the use of
               the <att>spanTo</att> attribute) is that <gi>hi</gi> does not imply that the visual
               effect being recorded is understood to represent some kind of modification. </p>
         </div>

         <div xml:id="PH-meta">
            <head>Metamarks</head>

            <p>By <term>metamark</term> we mean marks such as numbers, arrows, crosses, or other
               symbols introduced by the writer into a document expressly for the purpose of
               indicating how the text is to be read. Such marks thus constitute a kind of markup of
               the document, rather than forming part of the text. <specList>
                  <specDesc key="metamark" atts="function target "/>
               </specList>
            </p>

            <p>Unlike marginal notes or other additions to the text, metamarks are used by the
               writer to indicate a deliberate alteration of the writing itself, such as <q>move
                  this passage over there</q>. An addition or annotation by contrast would typically
               concern some property of the passage other than its intended location or status
               within the text flow. A metamark may contain text, or some other graphic which the
               encoder wishes to represent, or it may simply consist of arrows, dots, lines etc.
               which the encoder simply describes.</p>

            <!-- QUERY should it contain <desc> as a child? -->

            <p>The <gi>metamark</gi> element carries a <att>function</att> attribute which specifies
               the function of the metamark, using values such as <val>reorder</val>,
                  <val>flag</val>, <val>delete</val>, <val>insert</val> or <val>used</val>. The
               passage to which the metamark applies may be indicated in either of two ways: the
                  <att>target</att> attribute may be used to point to the element or elements
               containing the passage concerned, or the <att>spanTo</att> element may be used to
               point to a position in the document at which the passage concerned finishes. In the
               latter case, the <gi>metamark</gi> itself must be supplied at the position in the
               document where the passage concerned begins; in the former case it may be supplied at
               any convenient point. Both attributes should not be supplied. </p>

            <p>The following example is taken from an 15th century legal book from the city of
               Göttingen, containing regulations of everyday life issued by the city council <figure>
                  <graphic url="Images/ka04_1v-dtl.jpg" width="70%"/>
                  <head><title>Kundige bok 2</title>, fol 1v. </head>
               </figure>
            </p>


            <p>In the second paragraph, the word <mentioned xml:lang="la">lege</mentioned> ("read")
               was written in the left hand margin, next to the sentence beginning <q>Ock en
                  schullen de bruwere...</q>. It is thought to function as a metamark, indicating
               that this sentence forms part of the regulations. A further sentence was then added,
               while at some later stage the text and also the metamark were deleted. We might
               encode this as follows: <!-- ka04_1v-dtl.xml --><egXML
                  xmlns="http://www.tei-c.org/ns/Examples">
                  <delSpan spanTo="#endDel" change="#L3"/>
                  <metamark function="flag" target="#zone-1" change="#L2">lege</metamark>
                  <zone xml:id="zone-1" change="#L1">Ock en schullen de bruwere des hilgen dages
                     nicht over setten noch uppe den stillen fridach bruwen.</zone>
                  <addSpan spanTo="#endDel" change="#L2"/>
                  <zone>Noch nymande over setten, se en sehin denne erst, dat uppe den bonen neyn
                     stro noch, huw noch flaß ligghe, by pine eyner halven roden, deme bruwere so
                     wol alse dem bruwheren to murende.</zone>
                  <anchor xml:id="endDel"/>
               </egXML>
            </p>
            <p>The <att>change</att> attribute used here to indicate the sequencing of these various
               interventions is discussed below, in section <ptr target="#PH-changes"/>. The
               elements <gi>addSpan</gi> and <gi>delSpan</gi> are discussed in section <ptr
                  target="#PHAD"/>. </p>

            <p>The <gi>metamark</gi> element may also be used to encode the symbols etc. often found
               in marked-up proofs such as the following, taken from the Walt Whitman archive: <figure>
                  <graphic url="Images/whitman-03.jpg" width="400px"/>
                  <head>From a corrected proof of <title>Miracles</title> (Walt Whitman
                     Archive)</head>
               </figure></p>
            <!-- loc.00295 detail -->
            <p>In this example, the whole of what was originally the 14th section of the poem has
               been marked for deletion, both by horizontal and vertical lines, and by the metamarks
               resembling the <q>delta</q> deletion symbol to left and right of the section. The
               deletion itself might be encoded by using the normal <gi>del</gi> or <gi>delSpan</gi>
               element, and the metamarks by the <gi>metamark</gi> element. This is quite a
               different case from that of the next example, in which the writer does not intend to
               suppress the content, but only to mark that it has been copied to another manuscript
               or reused. </p>
            <p>
               <figure>
                  <graphic url="Images/whitman-02.jpg" width="70%"/>
                  <head>From "I am that halfgrown angry boy" (MS q 25), David M. Rubenstein Rare
                     Book &amp; Manuscript Library, Duke University. </head>
               </figure>
            </p>
            <p>This page contains internal deletions, additions, and retracings but these are
               semantically quite different from the apparent <soCalled>deletion</soCalled>
               signalled by the larger of the two single vertical lines, which shows that the
               written material has been transferred or re-used, not deleted. </p>
            <egXML xmlns="http://www.tei-c.org/ns/Examples">
               <surface>
                  <metamark function="used" rend="line" target="#X2"/>
                  <zone xml:id="X2">
                     <line>I am that halfgrown <add>angry</add> boy, fallen asleep</line>
                     <line>The tears of foolish passion yet undried</line>
                     <line>upon my cheeks.</line>
                     <!-- ... -->
                     <line>I pass through <add>the</add> travels and <del>fortunes</del> of
                           <retrace>thirty</retrace></line>
                     <line>years and become old,</line>
                     <line>Each in its due order comes and goes,</line>
                     <line>And thus a message for me comes.</line>
                     <line>The</line>
                  </zone>
                  <metamark function="used" target="#X2">Entered - Yes</metamark>
               </surface>
            </egXML>
            <p>In this example, we class as metamarks both the long vertical line and the annotation
                  <q>Entered - yes</q>.
               <!--The first indicates
that all of the writing between its own position and that of the
<gi>anchor</gi> element with identifier <val>X2</val> is marked as
having been used. This metamark takes the form of a cross.  The second
indicates that there is a mark in the form of a wavy line and that its
function is to separate the second writing zone on the surface, which
has identifier <val>z2</val>. -->
               Both metamarks are assumed to indicate that the whole of the written zone with
               identifier <code>X2</code> is marked as having been used. </p>

         </div>

         <div xml:id="PH-fix">
            <head>Fixation and Clarification</head>

            <p>A writer may sometimes rewrite material a second time without significant change and
               in the same place. We consider this a distinct activity from addition as usually
               defined because no new textual material results; instead the status of existing
               material is reaffirmed. We may distinguish two variants of this:
                  <term>fixation</term> where the first version was a tentative draft which is
               subsequently reaffirmed, for example by inking it over; and
                  <term>clarification</term>, where the first version was badly written and has been
               rewritten for clarity. The element <gi>retrace</gi> is provided for both cases; its
                  <att>cause</att> attribute may be used to distinguish these or other cases. <specList>
                  <specDesc key="retrace"/>
               </specList>
            </p>

            <p>In this simple example, taken from the papers of Henrik Ibsen, the writer wrote the
               word <mentioned>skuldren</mentioned> hastily, and then returned to it to make the
               letter <mentioned>l</mentioned> larger and clearer: <figure>
                  <graphic url="Images/skuldren.jpg" width="400px"/>
                  <head rend="it">From autograph ms of <title>Peer Gynt</title>, Collin 2869, 4°,
                     I.1.1, the Royal Library of Copenhagen</head>
               </figure> We might transcribe this word as follows: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples">
                  <line>... Sku<retrace cause="unclear">l</retrace>dren </line>
               </egXML>
            </p>

            <p>A single rewrite may not be sufficient, and it may be that the document becomes
               almost unreadable as a result of repeated clarification. In the following example, we
               can distinguish at least three attempts to write the letters
                  <mentioned>er</mentioned> in the word <mentioned>bægerklang</mentioned>: <figure>
                  <graphic url="Images/munch01.jpg" width="400px"/>
                  <head rend="it">Detail from autograph ms <title>Brand</title> in The Royal
                     Library, Denmark (KBK Collin 262) </head>

               </figure> We might encode this by nesting the <gi>retrace</gi> element as follows:
                  <egXML xmlns="http://www.tei-c.org/ns/Examples" source="#PH-ib05">
                  <line>ved Bæg<retrace cause="unclear" change="#stage2">
                        <retrace cause="unclear" change="#stage1">er</retrace>
                     </retrace> ...</line>
               </egXML> The <att>change</att> attribute used here is discussed further below (<ptr
                  target="#PH-changes"/>). </p>

            <p>The <gi>retrace</gi> element is used only for cases where text has been written
               multiple times. When metamarks and other markup-like strokes have been rewritten
               multiple times, the <gi>redo</gi> element described in the next section should be
               used in preference. </p>
         </div>

         <div xml:id="undo">
            <head>Confirmation, Cancellation, and Reinstatement of Modifications</head>

            <p><!--In a draft version of Goethe’s Faust, a passage was struck through once in pencil
               during one revision and then again with ink during a later revision, supposedly to
               confirm the deletion. <figure>
                  <graphic url="Images/faust_redo.jpg" width="90%"/>
                  <head rend="it">Fixation of a deletion in Goethe’s Faust</head>
               </figure> 
-->
               A writer may <!--also--> indicate that an alteration is itself to be altered: for
               example, a struck-through passage may be restored via a dotted underlining, or the
               underlining of a passage may be deleted by a wavy line.</p>

            <p>The following elements are provided to represent these situations: <specList>
                  <specDesc key="redo" atts="target "/>
                  <specDesc key="undo" atts="target "/>
               </specList>
            </p>

            <!--            <p>The <gi>redo</gi> element might be used to encode the Faust example above as
               follows:</p>
            <egXML xmlns="http://www.tei-c.org/ns/Examples">
               <line><redo xml:id="redo_3" hand="#g_t" target="#mod_1" cause="fix"/><mod
                     xml:id="mod_1" rend="strikethrough" spanTo="#anchor_1" hand="#g_bl"/>Ihr
                  hagren, triſten, krummgezog<mod rend="strikethrough">nen</mod>ener Nacken</line>
               <line>Wenn ihr nur piepſet iſt die Welt ſchon matt.<anchor xml:id="anchor_1"/></line>
            </egXML>
-->



            <p>The element <gi>restore</gi> (<ptr target="#PHCD"/>) is provided for the
               comparatively simple case where a simple deletion is marked as having been
               subsequently cancelled. The <gi>undo</gi> element discussed here is more widely
               applicable and may be used for any kind of cancellation. It points to the element or
               elements which are being cancelled. These components need not be contiguous, provided
               that the cancellation is clearly a single act; each distinct act of cancellation
               requires a distinct <gi>undo</gi> element, however. Either of the attributes
                  <att>target</att> or <att>spanTo</att> may be used to indicate the passages
               concerned. </p>

            <p>Consider the following imaginary example: <figure>
                  <graphic url="Images/undoing1.jpg" width="80%"/>
                  <head>Imaginary example demonstrating restoring and undoing</head>
               </figure> We hypothesize that the text has gone through three states or changes, as
               follows: <list rend="numbered">
                  <item>This is just some sample text, we need a real example. </item>
                  <item>This is not a real example.</item>
                  <item>This is just some text, not a real example.</item>
               </list>
            </p>

            <p>This sequence of events might be encoded as follows: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples">
                  <line>This is <del change="#s2" rend="overstrike">
                        <undo spanTo="#Xa" rend="dotted" change="#s3"/>just some <anchor xml:id="Xa"
                        /> sample <undo spanTo="#Xb" rend="dotted" change="#s3"/>text, <anchor
                           xml:id="Xb"/> we need</del>
                     <add change="#s2">not</add> a real example.</line>
               </egXML> using two <gi>undo</gi> elements, each with a <att>spanTo</att> attribute,
               to delimit the two parts of the deletion which were reverted at change s3. Note that
               in this case, since <att>target</att> is not supplied, it is the effect of the parent
               element (the <gi>del</gi>) which is assumed to be undone. </p>

            <p>Alternatively, we might more economically use the generic <gi>seg</gi> element within
               the <gi>line</gi> to delimit the two sequences whose deletion is being reverted, and
               then use the <att>target</att> attribute on a single <gi>undo</gi> element: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples">
                  <line>This is <del change="#s2" rend="overstrike">
                        <seg xml:id="X-a">just some</seg> sample <seg xml:id="X-b">text</seg>, we
                        need</del>
                     <add change="#s2">not</add> a real example.</line>
                  <undo target="#X-a #X-b" rend="dotted" change="#s3"/>
               </egXML>
               <!-- NOTE maybe add a third example doing this with xpath to pick out
individual tokens. Or one from a real doc -->
            </p>
         </div>

         <div xml:id="transpo">
            <head>Transpositions</head>

            <p>A <term>transposition</term> occurs when metamarks are found in a document indicating
               that passages should be moved to a different position. Typically this may be done
               using arrows, asterisks or numbers, or other means. By definition the result of a
               transposition is not present in the document, and should not therefore be encoded, if
               the intention is to represent the actual appearance of the document. Instead, the
               following elements may be used to indicate the intended reordering: <specList>
                  <specDesc key="listTranspose"/>
                  <specDesc key="transpose"/>
               </specList></p>
            <p>Consider for example, the following extract from an Ibsen manuscript <figure>
                  <graphic url="Images/ibsen01.jpg" width="400px"/>
                  <head>Extract from autograph <title>Digte</title> (Poems) NBO Ms. 4º 1110a</head>
               </figure> The underlined numbers 1 and 2 here indicate that, although the word
                  <mentioned>bör</mentioned> precedes the word <mentioned>hör</mentioned> in the
               text, the order of the two words should be reversed. We may encode this as follows:
                  <egXML xmlns="http://www.tei-c.org/ns/Examples" source="#PH-ib04">
                  <line><seg xml:id="ib01">bör</seg><metamark rend="underline"
                        function="transposition" target="#ib01" place="above">2.</metamark> og <seg
                        xml:id="ib02">hör</seg><metamark rend="underline" function="transposition"
                        target="#ib02" place="above">1.</metamark></line>
                  <listTranspose>
                     <transpose>
                        <ptr target="#ib02"/>
                        <ptr target="#ib01"/>
                     </transpose>
                  </listTranspose>
               </egXML>
            </p>

            <p>Note the use of the generic <gi>seg</gi> element to identify the sections of text
               being transposed. When (as in the following example) the whole of a line is to be
               transposed, there is no need to delimit the sections concerned: <figure>
                  <graphic url="Images/ibsen04.jpg" width="600px"/>
                  <head>Detail from autograph ms of <title>Den episke Brand</title> (KBK Collin
                     2869)</head>
               </figure>
               <!-- ibsen04.xml --><egXML xmlns="http://www.tei-c.org/ns/Examples" source="#PH-ib01">
                  <line xml:id="ib3"><metamark function="transposition" place="margin-left"
                        >2.)</metamark> thi da er du med Himmelen i Pagt; — </line>
                  <line xml:id="ib4">
                     <metamark function="transposition" place="margin-left">1.)</metamark> da kan du
                     Folkets Jøkelhjerter tine;</line>
                  <listTranspose>
                     <transpose>
                        <ptr target="#ib4"/>
                        <ptr target="#ib3"/>
                     </transpose>
                  </listTranspose>
               </egXML> When transposition is made, the whole element indicated is understood to be
               moved, not just its contents. In the above example, the metamarks are thus understood
               to be moved along with the lines to which they apply. </p>

            <!-- <p>In case the area to be transposed is overlapping with some other
kind of markup, the generic <gi>milestone</gi> can be used instead of
<gi>seg</gi> or any other existing elements.</p>
-->

            <p>One or more <gi>listTranspose</gi> elements may be supplied either embedded within
               the text or in the <gi>profileDesc</gi> of the header, depending on local preference.
               Each <gi>listTranspose</gi> can contain one or more <gi>transpose</gi> elements, each
               of which defines a single transposition.</p>
         </div>

         <div xml:id="alter">
            <head>Alternative Readings</head>
            <p><figure>
                  <graphic url="Images/moore04.png" width="400px"/>
                  <head>Detail from autograph manuscript of the second version of <title>Lalla
                        Rookh</title>, Pierpont Morgan MA 310</head>
               </figure> In this example two alternative readings are provided, but no preference is
               indicated. While the author apparently first composed the line <q>Alone before his
                  native river -</q>, at some later point, he entertained the possibility of using
               the word <mentioned>beside</mentioned> instead of <mentioned>before</mentioned>. The
               manuscript supplies no indication of which word Moore favours at this point, although
               in fact, in the first printed edition of <title>Lalla Rookh</title> the word
                  <mentioned>beside</mentioned> was chosen. </p>
            <p>The element <gi>alt</gi> provided by the <ident type="module">linking</ident> module
               gives a simple way of encoding the state of this manuscript, as follows: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples" source="#PH-eg-09">
                  <zone>
                     <line>Alone <seg xml:id="alt1">before</seg>
                        <add place="above" xml:id="alt2">beside</add> his native river ­—</line>
                     <alt target="#alt1 #alt2" mode="excl" weights="0 1"/>
                  </zone>
               </egXML>
            </p>
            <p>The <att>mode</att> attribute here indicates that the two possible readings indicated
               by the <att>target</att> attribute are mutually exclusive. The <att>weights</att>
               attribute indicates the relative importance or preference to be attached to the two
               readings on a scale running from zero (most improbable) to one (most probable). In
               this case, we have a very strong preference for the second reading because this is
               the one that appears in the published version of the poem. The <gi>alt</gi> element
               is further discussed in section <ptr target="#SAAT"/>. </p>
         </div>
         <!-- NOTE next section on ice, pending further council discussion -->
         <!--   
<div xml:id="subst">
      <head>Substitution</head>
      <p>In the current model for the TEI <gi>subst</gi> element, one or more additions
         and deletions may be combined if they are considered as representing a single
         editorial act, a substitution. Without extension, this model could not
         therefore include cases such as the following example taken from Thomas Moore's
<title>Lalla Rooke</title>
         <figure>
<graphic url="Images/moore01.png" width="400px"/>
         </figure>
</p><p> Here the word <mentioned>pondering</mentioned> is deleted, and the
         phrase <mentioned>she mus'd</mentioned> are added, while the word
<mentioned>thus</mentioned> remains unchanged. It seems appropriate to treat
         all of this as a single substitution. This would require a modification to the
         content model of <gi>subst</gi> so as to permit text along with other members
         of <ident type="class">model.pPart.transcriptional</ident>, so that this
         example could be encoded as follows: <egXML
xmlns="http://www.tei-c.org/ns/Examples">
<line>While <subst><del>pondering</del> thus <add>she
   mus'd</add></subst>, her pinions fann'd</line>
         </egXML></p>
   </div>-->

         <div xml:id="instantcorr">
            <head>Instant Corrections</head>
            <p>The use of elements such as <gi>del</gi> and <gi>add</gi> necessarily implies that
               the modifications they indicate were made at some time after the original writing. An
               exception to this is where a false start or <soCalled>instant</soCalled> correction
               has been identified: the author starts to write, and then immediately corrects what
               has been written. </p>
            <p>The <att>instant</att> attribute defined by this module may be used on any element
               which is a member of the <ident type="class">att.editLike</ident> class to modify
               this default assumption. When the value of <att>instant</att> is set to
                  <val>true</val>, the addition or deletion is considered to belong to the same
               change as its parent element, while <code>false</code> means some change later than
               that of its parent.</p>
            <p> An example of false start or instant correction can be seen in the following line:
                  <figure corresp="#WHITMS1">
                  <graphic url="Images/whitman03a.jpg" width="70%"/>
                  <head>Detail fron <title>[I am a curse]</title>, one of the drafts for Whitman's
                        <title>Song of Myself</title></head>
               </figure> in which we can detect the following sequence of events: <list
                  rend="numbered">
                  <item>The letter <val>T</val> is written and then immediately deleted</item>
                  <item>The word <val>The</val> is written, deleted, and replaced by the word
                        <val>His</val></item>
                  <item>The added word <val>His</val> is then deleted</item>
                  <item>The initial letter <val>i</val> of the words <mentioned>iron
                        necklace</mentioned> is overwritten with a capital I</item>
               </list> To indicate that the first of these acts must have taken place during the
               main act of writing, before the other deletion and additions, we might encode this
               revision campaign as follows: <egXML xmlns="http://www.tei-c.org/ns/Examples"
                  source="#WHITMS1">
                  <line><del instant="true">T</del>
                     <mod type="subst">
                        <del>The</del>
                        <add place="above">
                           <del rend="overstrike">His</del>
                        </add>
                     </mod>
                     <mod type="subst">
                        <del rend="overwritten">i</del>
                        <add place="superimposed">I</add>
                     </mod>ron necklace</line>
               </egXML>
            </p>
         </div>
      </div>
   </div>
   <div xml:id="PH-surfzone">
      <head>Advanced Uses of <gi>surface</gi> and <gi>zone</gi></head>

      <p>The function of the <gi>surface</gi> element is both to identify a specific area containing
         writing and to provide a two dimensional set of coordinates which can be used to position
         and provide dimensions for sub-parts of it. Furthermore, surfaces may nest within other
         surfaces, as in the case of <q>patches</q> or other written materials attached to the main
         writing surface. In the general case, the position and dimensions of such nested surfaces
         will be defined using the same coordinate system as that supplied by the parent
            <gi>surface</gi> element. It is also possible, however, that a different coordinate
         system is required for such a nested surface, perhaps because it requires a more complex
         granularity. We consider both possibilities.</p>

      <p>In the earlier examples showing nested examples we did not provide any coordinate
         information, for simplicity of presentation. Suppose however, that we wish to indicate the
         position and sizes of the newspaper scraps in <ptr target="#sleeprs"/> above, relative to
         the whole page. As previously noted, the four attributes <att>ulx</att>, <att>uly</att>,
            <att>lrx</att> and <att>lry</att> when given on the <gi>surface</gi> element define the
         coordinate scheme, rather than specifying the location of that surface. We must therefore
         introduce an additional <gi>zone</gi> element, as in the following revised encoding for
         this example <egXML source="#WHITMS2" xmlns="http://www.tei-c.org/ns/Examples">
            <surface ulx="0" uly="0" lrx="50" lry="50">
               <zone ulx="1" uly="1" lrx="10" lry="10">
                  <line>Poem</line>
                  <line>As in Visions of — at</line>
                  <line>night —</line>
                  <line>All sorts of fancies running through</line>
                  <line>the head</line>
               </zone>
               <zone ulx="4" uly="4" lrx="20" lry="20">
                  <surface type="newsprint" attachment="glue" flipping="false">
                     <zone>Spring has just set in here, and the weather.... a steamer </zone>
                     <metamark function="sequence">2</metamark>
                  </surface>
               </zone>
            </surface></egXML> In this version of the encoding, the inner surface, corresponding
         with the first piece of newsprint, inherits locational information from the <gi>zone</gi>
         element that contains it. This zone, and the preceding one, which contains a sequence of
            <gi>line</gi> elements, are both positioned in terms of the coordinates specified on the
         outermost <gi>surface</gi> element, which defines a scale running from 0 to 50 in either
         direction. On that scale, the <gi>line</gi> elements occupy a rectangle with coordinates
         (1,1,10,10), while the nested surface occupies a rectangle with coordinates
         (4,4,20,20).</p>
      <p>Now suppose that we wish to define a finer scale grid for the newspaper patch, perhaps
         because we wish to localize zones within it with greater accuracy. To do this we will need
         to specify the position of the nested surface as in the previous example, but also to
         define the new coordinate system. We accomplish this as follows: <egXML
            xmlns="http://www.tei-c.org/ns/Examples">
            <surface ulx="0" uly="0" lrx="50" lry="50">
               <zone ulx="1" uly="1" lrx="10" lry="10">
                  <line>Poem</line>
                  <!-- ... -->
                  <line>the head</line>
               </zone>
               <zone ulx="4" uly="4" lrx="20" lry="20">
                  <surface ulx="0" uly="0" lrx="100" lry="100">
                     <zone ulx="10" uly="10" lrx="90" lry="95"> Spring has just set in here, and the
                        weather .... a steamer </zone>
                  </surface>
               </zone>
            </surface></egXML> As before, the second zone defines the position and size of the
         newspaper patch itself in terms of a coordinate system running from 0 to 50 on both X and Y
         axes. The nested <gi>surface</gi> element however defines a new scale for all of its
         components, running from 0 to 100 on both X and Y axes. The position of the nested zone
         containing the text <mentioned>Spring ... steamer</mentioned> is now given in terms of this
         scale.</p>

      <p>All of the examples so far given have involved rectangular zones, for clarity of
         exposition. As noted above, the <att>points</att> attribute may be used to define
         non-rectangular zones as a series of points. For example, in the last of the Whitman
         examples discussed in section <ptr target="#PH-meta"/> above, we might wish to record the
         exact shape of the zone containing the metamark <mentioned>Entered</mentioned>. Since this
         is not a rectangular zone, we use the <att>points</att> attribute to indicate the points
         defining a polygon which contains it. The values used are expressed in terms of a
         coordinate space running from 0 to 229 in the X dimension, and 0 to 160 in the Y dimension. </p>

      <egXML xmlns="http://www.tei-c.org/ns/Examples">
         <surface ulx="0" uly="0" lrx="229" lry="160">
            <graphic url="whitman-02.jpg"/>
            <zone xml:id="entered" points="142,122 155,113 178,122
	 208,144 198,154 178,139"/>
         </surface>
      </egXML>

      <p>In exactly the same way, we may wish to identify the curved zone in the following image
         containing the word <mentioned>Northamptonshire</mentioned>: <figure>
            <graphic url="Images/mould-stone.jpg"/>
            <head>Gravestone of Private Moulds</head>
         </figure> This curved zone might be encoded in the following way: <egXML
            xmlns="http://www.tei-c.org/ns/Examples">
            <surface xml:id="badge" ulx="14.54" uly="16.14" lrx="0" lry="0">
               <graphic url="stone.jpg"/>
               <zone xml:id="county"
                  points="4.6,6.3 5.25,5.85 6.2,6.6
  8.2,7.4 9.9,6.6 10.9,6.1 11.4,6.7
  8.2,8.3 6.2,7.6"
               />
            </surface>
         </egXML>
      </p>
      <p>Finally, it should be noted that a <gi>zone</gi> does not need to be entirely contained
         within the two-dimensional space defined by its parent surface. For example, we might wish
         to encode the example in <ptr target="#durlach"/> above not as a surface representing the
         whole of the two page spread, but as a surface representing only the written part of this
         opening. The written part appears 50 units from the left of the image and 20 units from the
         top, while the bottom right corner of the written part appears 400 units from the left of
         the image, and 280 units from the top. We therefore define the written surface within this
         image as follows: <egXML xml:lang="und" xmlns="http://www.tei-c.org/ns/Examples"><facsimile>
               <surface ulx="50" uly="20" lrx="400" lry="280">
                  <!-- ... -->
               </surface>
            </facsimile></egXML> To describe the whole image, we will now need to define a zone of
         interest which represents an area larger than this surface. Using the same coordinate
         system as that defined for the surface, its coordinates are <val>0,0,500,321</val>. This
         zone of interest can be defined by a <gi>zone</gi> element, within which we can place the
         uncropped <gi>graphic</gi>: <egXML xml:lang="und" xmlns="http://www.tei-c.org/ns/Examples"><facsimile>
               <surface ulx="50" uly="20" lrx="400" lry="280">
                  <zone ulx="0" uly="0" lrx="500" lry="321">
                     <graphic
                        url="http://upload.wikimedia.org/wikipedia/commons/5/50/Handschrift.karlsruhe.blb.jpg"
                     />
                  </zone></surface>
            </facsimile></egXML>
      </p>

   </div>

   <div xml:id="PHLAY">
      <head>Aspects of Layout</head>
      <p>The following methods are available to capture general aspects of the layout of material on
         a page where this is considered important. Within the <gi>sourceDoc</gi> element, as
         already indicated, the element <gi>surface</gi> and <gi>surfaceGrp</gi> enable the encoder
         to represent directly the structure of a codex as gatherings or quires, leaves, and
         surfaces, as in the following example: <egXML xml:lang="und"
            xmlns="http://www.tei-c.org/ns/Examples"><sourceDoc>
               <surfaceGrp type="quire" n="1">
                  <surfaceGrp type="leaf" n="1">
                     <surface type="recto" n="1r">
                        <!-- ... -->
                     </surface>
                     <surface type="verso" n="1v">
                        <!-- ... -->
                     </surface>
                  </surfaceGrp>
                  <surfaceGrp type="leaf" n="2">
                     <surface type="recto" n="2r">
                        <!-- ... -->
                     </surface>
                     <surface type="verso" n="2v">
                        <!-- ... -->
                     </surface>
                  </surfaceGrp>
                  <!-- other leaves in first quire -->
               </surfaceGrp>
               <!-- other quires here -->
            </sourceDoc></egXML></p>
      <p>In some cases, it may be preferable to define <gi>surface</gi>s corresponding with each two
         page opening, for example where it is clear that the writer regarded each such opening as a
         single writing surface, with written zones or other features crossing the page divide. An
         example is shown here: <figure>
            <graphic url="Images/proust-42v.png" width="80%"/>
            <head>Opening from autograph ms of Proust's <title>A la recherche du temps perdu</title>
               (f 42v-43r)</head>
         </figure>
      </p>
      <p>The coloured lines added to this image indicate a number of zones of writing, colour coded
         to indicate the order in which they were written (purple, then green, then red). For
         example, the zone marked in red on the left contains a note referring to the purple zone on
         the right. </p>
      <!--
referring to the zone marked in purple on the right 
<line>Décidément je crois que cette promenade à l’Ile</line>
<line>ne sera que quand je m’amuse déjà avec Albertine. Ainsi</line>
<line>une partie…</line>

. olore refer to macro times of elaboration: first purple, then green, then red. Blue is for the pages within the opening.
-->
      <p>This approach assumes that the transcription will primarily be organized in the same way as
         the physical layout of the source, using embedded transcription elements. Alternatively,
         where the a non-embedded transcription has been provided, using the <gi>text</gi> element,
         it is still possible to record gathering breaks, page breaks, column breaks, line breaks
         etc in the source, using the elements described in section <ptr target="#CORS"/>. Detailed
         metadata about the physical make-up of a source will usually be summarized by the
            <gi>physDesc</gi> component of a <gi>msDesc</gi> element discussed in <ptr
            target="#msph"/>. </p>

      <div type="div3" xml:id="PHSP">
         <head>Space</head>
         <p>The author or scribe may have left space for a word, or for an initial capital, and for
            some reason the word or capital was never supplied and the space left empty. The
            presence of significant space in the text being transcribed may be indicated by the
               <gi>space</gi> element. <specList>
               <specDesc key="space" atts="resp" />
            </specList> Note that this element should not be used to mark normal inter-word space or
            the like. </p>
         <p>In line 694 of Chaucer's <title>Wife of Bath's Prologue</title> in the Holkham
            manuscript the scribe has left a space for a word where other manuscripts read
               <mentioned>preestes</mentioned>: <egXML xmlns="http://www.tei-c.org/ns/Examples">By
               god if wommen had writen storyes As <space quantity="7" unit="chars"/> han within her
               oratoryes</egXML> The <gi>supplied</gi> element discussed in the previous section may
            be used to supply the text presumed missing: <egXML
               xmlns="http://www.tei-c.org/ns/Examples">By god if wommen had writen storyes As
                  <supplied reason="space" resp="#ETD" source="#Hg">preestes</supplied> han within
               her oratoryes</egXML> Here, the fact of the space within the manuscript is indicated
            by the value of the <att>reason</att> attribute. The source of the supplied text is
            shown by the value of the <att>source</att> attribute as the Hengwrt manuscript; the
            transcriber responsible for supplying the text is ES. </p>
      </div>
      <div type="div3" xml:id="PHLN">
         <head>Lines</head>
         <p>One of the more common forms of modification encountered in written documents of any
            kind is the presence of lines written under, beside, or through the text. Such lines may
            be of various types: they may be solid, dashed or dotted, doubled or tripled, wavy or
            straight, or a combination of these and other renderings. The line may be used for
            emphasis, or to mark a foreign or technical term, or to signal a quotation or a title,
            etc.: the elements <gi>emph</gi>, <gi>foreign</gi>, <gi>term</gi>, <gi>mentioned</gi>,
            or <gi>title</gi> may be used for these. Where the line has a clear paratextual function
            the <gi>metamark</gi> element may be considered more appropriate. Frequently, a scholar
            may judge that a line is used to delete text: the <gi>del</gi> element is available to
            indicate this. In all these cases, the <att>rend</att> attribute may be used to supply
            further details concerning the style of the line. Thus, Lawrence's deletion by
            strike-through of <mentioned>my</mentioned> in the autograph of <title>Eloi, Eloi, lama
               sabachthani</title> may be encoded: <egXML xmlns="http://www.tei-c.org/ns/Examples"
               >For I hate this <del rend="strikethrough" hand="#dhl">my</del> body, which is so
               dear to me</egXML></p>
         <p>There will be instances, however, where a scholar wishes only to register the occurrence
            of lines in the text, without making any judgement as to what the lines signify. In
            these cases the <gi>hi</gi> element may be used, with the <att>rend</att> attribute to
            mark the style of line. In the manuscript of a letter by Robert Browning to George
            Moulton-Barrett the underlining of the phrase <mentioned>had obtained all the letters to
               Mr Boyd</mentioned> may be marked-up as follows: <egXML
               xmlns="http://www.tei-c.org/ns/Examples" source="#PH-eg-15">I have once — by
               declaring I would prosecute by law — hindered a man's proceedings who <hi
                  rend="underline">had obtained all the letters to Mr Boyd</hi></egXML></p>
         <p>The above examples presume the common case where a single word or phrase is marked by a
            line, with no doubt as to where the marking begins or ends and with no overlapping of
            the area of text with other marked areas of text. Where there is doubt, the
               <gi>certainty</gi> element may be used to record the doubt. In the Browning example
            cited above the underlining actually begins half-way under <mentioned>who</mentioned>,
            and this uncertainty could be remarked as follows: <egXML
               xmlns="http://www.tei-c.org/ns/Examples">I have once — by declaring I would prosecute
               by law — hindered a man's proceedings who <hi xml:id="cstart1" rend="underline">had
                  obtained all the letters to Mr Boyd</hi>
               <!-- ... -->
               <certainty target="#cstart1" locus="start" degree="0.70">
                  <desc>may begin with previous word</desc>
               </certainty></egXML></p>
         <p>Where the area of text marked overlaps other areas of text, for example crossing a
            structural division, one of the spanning mechanisms mentioned above must be used; for
            example where the line is thought to mark a deletion, the <gi>delSpan</gi> element may
            be used. Where it is desired simply to record the marking of a span of text in
            circumstances where it is not possible to surround the text with a <gi>hi</gi> element,
            the <gi>span</gi> element may be used with the <att>rend</att> or <att>type</att>
            attribute indicating the style of line-marking.</p>
         <p>More work needs to be done on clarifying the treatment of other textual features marked
            by lines which might so overlap or nest. For example, in many Middle English manuscripts
            (e.g. the Jesus and Digby verse collections), marginal sidebars may indicate metrical
            structure: couplets may be linked in pairs, with the pairs themselves linked into
            stanzas. Or, marginal sidebars may indicate emphasis, or may point out a region of text
            on which there is some annotation: in many manuscripts of Chaucer's <title>Wife of
               Bath's Prologue</title> lines 655–8 are marked with nesting parentheses against which
            the scribe has written <mentioned>nota</mentioned>.</p>
         <p>Such features could be captured by use of the <gi>note</gi> element, containing a prose
            description of the manuscript at this point, enhanced by a link to a visual
            representation (or facsimile) of the feature in question. For example, in the Chaucer
            example just cited, one may wish to record that the <mentioned>nota</mentioned> is
            written in the Hengwrt manuscript in the right margin against a single large left
            parenthesis bracketing the four lines, with two right parentheses in the right margin
            bracketing two overlapping pairs of lines: the first and third, the second and fourth.
            The <gi>note</gi> element allows us to record that the scribe wrote
               <mentioned>nota</mentioned>, but is not well-adapted to show that the
               <mentioned>nota</mentioned> points both at all four lines and at two pairs of lines
            within the four lines. The <gi>metamark</gi> element discussed in section <ptr
               target="#PH-meta"/> above provides better facilities for this kind of complex
            annotation. </p>
      </div>
   </div>
   <div type="div2" xml:id="PHSK">
      <head>Headers, Footers, and Similar Matter</head>

      <p>Such information as page numbers, signatures, or catchwords may be recorded in a
         specialized <gi>fw</gi> element provided for that purpose. Although the name derives from
         the term <term>forme work</term>, used in description of early printed documents (the
            <q>forme</q> being the block used to hold movable type), the <gi>fw</gi> element may be
         used for such features of any document, written or printed. Note that the purpose of this
         element is to record page numbers etc. <emph>actually present</emph> in the document being
         encoded, not necessarily to provide a complete or accurate pagination of it. </p>
      <p>Information about pagination etc. may also be provided using the <att>n</att> attribute of
         the <gi>pb</gi> or <gi>gb</gi> elements, or by other appropriate <gi>milestone</gi>
         elements, as further discussed in section <ptr target="#CORS"/>: since this information is
         usually provided by the encoder, it is not subject to the constraint that it should be
         present only if textually present in the source being encoded. In text-critical situations
         it may be useful to provide both a normalized version of the pagination and a
         representation of the catch-word or numbering, especially when the latter presents a
         variant reading, or is significant for compositor identification. <specList>
            <specDesc key="fw"/>
         </specList> The <gi>fw</gi> element may be used to encode any of the unchanging portions of
         a page forme, such as: <list rend="bulleted">
            <item>running heads (whether repeated or changing on every page, or alternating
               pages)</item>
            <item>running footers</item>
            <item>page numbers</item>
            <item>catch-words</item>
            <item>other material repeated from page to page, which falls outside the stream of the
               text</item>
         </list> It should not be used for marginal glosses, annotations, or textual variants, which
         should be tagged using <gi>gloss</gi>, <gi>note</gi>, or the text-critical tags described
         in chapter <ptr target="#TC"/>, respectively.</p>
      <p>For example: <egXML xmlns="http://www.tei-c.org/ns/Examples"><fw type="head"
               place="top-centre">Poëms.</fw>
            <fw type="pageNum" place="top-right">29</fw>
            <fw type="sig" place="bot-centre">E3</fw>
            <fw type="catch" place="bot-right">TEMPLE</fw></egXML>
         <!-- Donne, Poems 1633, p. 29 -->
         <!-- [Need several examples, all fuller than this one.     -->
         <!-- Take from DOSL materials? -MSM]                          --></p>
   </div>



   <div xml:id="PH-changes">
      <head>Changes</head>
      <p>A major purpose of genetic editing is the identification of <soCalled>revision
            campaigns</soCalled> or, more generally, <term>changes</term>. An editor may wish to
         assign a set of alterations (deletions, additions, substitutions, transpositions, etc.) or
         any other act of writing to a particular change, to indicate both that one or more of such
         phenomena preceded or followed another and also to indicate that they are related in some
         way, for example that one is a consequence of the other. They might also wish to group
         together certain revisions, regardless of when they might have occurred, based on a variety
         of other shared characteristics (e.g., corrections of factual errors or revisions that
         incorporate suggestions made by a given reader). To document this we need: <list>
            <item>a system to assign phenomena to a particular change</item>
            <item>a way to characterize a change, in itself and in relation to other changes.</item>
         </list></p>

      <p>The element <gi>creation</gi> (within the TEI header profile description) contains all
         information relating to the genesis or production of a text. It may contain a
            <gi>listChange</gi> element which contains a number of <gi>change</gi> elements, one for
         each identified change: <specList>
            <specDesc key="listChange" atts="ordered"/>
            <specDesc key="change"/>
         </specList>
      </p>

      <p>In the following example an editor has identified four distinct changes:</p>
      <egXML xmlns="http://www.tei-c.org/ns/Examples">
         <profileDesc>
            <creation>
               <listChange ordered="true">
                  <change xml:id="ST-1">First stage, written in ink </change>
                  <change xml:id="ST-2">Second stage, with revisions written in the author's hand
                     using pencil</change>
                  <change xml:id="ST-3">Fixation of the pencilled revisions together with further
                     revisions in the author's hand using ink</change>
                  <change xml:id="ST-4">Additions in a different hand, probably at a later
                     stage</change>
               </listChange>
            </creation>
         </profileDesc>
      </egXML>
      <p>The <gi>listChange</gi> element carries an attribute <att>ordered</att>, which can take the
         values <code>true</code> or <code>false</code> (the default). The attribute specifies
         whether the order of child elements signifies a temporal order for the revision campaigns
         which they document. In the example above, the editor has asserted that the four stages
         distinguished are ordered chronologically according to the order of the <gi>change</gi>
         elements.
         <!-- Note that asserting a specific order early on, though probably
         one of the hardest tasks in a genetic analysis, can considerably reduce the encoding effort
         in assigning textual alterations to stages during the transcription, as we will see below.
         For instance deletions can only be assigned to a stage that follows the one in which the
         passage being deleted was written down. Hence, having a certain order of stages put in
         place before transcription begins will allow the encoder to reduce verbose tagging, where
         default assumptions based on the natural order of actions can be made.</p>
      <p>-->
         If necessary, <gi>listChange</gi> elements can be nested hierarchically. This may be
         helpful in two cases. Firstly one can build up hypotheses about related revisions
         step-by-step, starting with stages of smaller coverage, whose members are certainly
         related, and then in a subsequent pass grouping these stages in turn, thereby extending
         their reach.</p>

      <egXML xmlns="http://www.tei-c.org/ns/Examples">
         <profileDesc>
            <creation>
               <listChange>
                  <change xml:id="o">An unrelated change note</change>
                  <listChange xml:id="m">
                     <change xml:id="m1">Alterations on one manuscript page, certainly
                        related</change>
                     <change xml:id="m2">Alterations on another manuscript page, certainly
                        related</change>
                  </listChange>
                  <change xml:id="p">Another unrelated change note</change>
               </listChange>
            </creation>
         </profileDesc>
      </egXML>
      <p>A nested <gi>listChange</gi> elements is also useful to indicate a <emph>partial</emph>
         ordering of revision campaigns.</p>
      <egXML xmlns="http://www.tei-c.org/ns/Examples">
         <listChange ordered="true">
            <change xml:id="ST1">The first stage</change>
            <listChange>
               <!-- We have no information about the order of these changes, except
     that they both followed ST1 and preceded STX  -->
               <change xml:id="ST-rev1">A revision of the first stage</change>
               <change xml:id="ST-rev2">Another revision of the first stage</change>
            </listChange>
            <change xml:id="STX">The last stage</change>
         </listChange>
      </egXML>
      <p>In addition to the possibility of ordering text stages in relation to each other,
            <gi>change</gi> elements may carry a number of attributes from the
            <ident type="class">att.datable</ident> class (<att>period</att>, <att>when</att>,
            <att>notBefore</att>, <att>notAfter</att>, <att>from</att>, and <att>to</att>) which
         allow each stage to be dated as exactly or inexactly as necessary, in the same way as is
         currently possible for the TEI <gi>date</gi> element.</p>
      <!-- Maybe note that absolute dates and relative order can conflict -->
      <egXML xmlns="http://www.tei-c.org/ns/Examples">
         <profileDesc>
            <creation>
               <date notAfter="1816-07-18"/>
               <listChange ordered="true">
                  <change xml:id="mod1" when="1816-07-16">The first draft of
                        <title>Persuasion</title>, completed by the date <date>July 16 1816</date>
                     which is written after the word <q>Finis</q> at <ref target="#pers-30">page
                        30</ref>.</change>
                  <change xml:id="mod2" notBefore="1816-07-16">After the <date>16th of July</date>
                     Austen starts revision of the two final chapters, by rewriting the end and
                     adding a new zone (<ref target="#transp-1">pages 32-35</ref>) to be inserted at
                        <ref target="#insertion-p1">page 19</ref>. This stage is documented by the
                     deletion of the date (<date>July 16 1816</date>) at <ref target="#pers-30">page
                        30</ref>, and the addition of more text and of a new date (<date>July 18.
                        1816</date>) at <ref target="#pers-31">page 31</ref></change>
                  <change notBefore="1816-07-18">Before publication, after <date>July 18th,
                        1816</date> chapters 10-11 were broken into three chapters, 10, 11, 12, as
                     witnessed by the print.</change>
               </listChange>
            </creation>
         </profileDesc>
      </egXML>
      <p>Each <gi>change</gi> element, apart from declaring a distinct change in the creation of the
         document, may also contain references to other annotations contained within the
            <gi>teiHeader</gi> or in the document (as shown in the previous example). Such
         references, along with the textual content, are purely documentary and do not affect the
         textual stage associated with any element thus referred to. The association of a textual
         component with a change is always made explicitly, either by using the <att>target</att>
         attribute on the <gi>change</gi> element to point to one or more elements, or by pointing
         from the element or elements concerned to the <gi>change</gi> element by means of their
            <att>change</att> attribute. If a <gi>change</gi> element is associated with some
         element, it is also associated with all of that element's children, unless otherwise
         indicated, for example by a new value for the <att>change</att> attribute. </p>
      <p>In the following simple example, the text at one stage read <q>This is a mouse</q>, and at
         the next <q>This is a house mouse</q>: <egXML xmlns="http://www.tei-c.org/ns/Examples">
            <line change="#firstStage">This is a <add change="#secondStage">house</add>
               mouse.</line>
         </egXML>
      </p>
      <p>In this example, however, the text originally read <q>This is a house</q>, and subsequently
            <q>This is a mouse</q>: <egXML xmlns="http://www.tei-c.org/ns/Examples">
            <line change="#firstStage">This is a <mod type="subst" change="#secondStage">
                  <del>house</del>
                  <add>mouse</add>
               </mod>.</line>
         </egXML> Note that in this case both the deletion and the addition are associated with the
         second stage. The word <q>house</q>, because it was deleted at the second stage, must have
         been present at the first stage, whereas the word <q>mouse</q> must have been added during
         the second stage. </p>

      <p>Elements such as <gi>add</gi> and <gi>del</gi> and the like carry an implied semantics
         concerning the order in which events in the writing of a document was carried out:
         something which is deleted must have been written before it was deleted; something which is
         added must have been added at a later stage of the writing. Even when a combination of such
         elements is used, the chronology can usually be inferred (see further <ptr target="#PHCOMB"
         />). Explicit indication of the stage to which some modification belongs is mostly useful
         in situations where all the alterations identified in a document are to be grouped, for
         example chronologically. </p>
      <!--For example, in the
manuscript of Goethe's <title>Helena</title> two distinct stages have
been identified, one dating from 1800, and one from 1825. 
<figure><graphic url="goethe-hel.jpg"/></figure></p>
In each line occur alterations. Their belonging to different phases of the writing process may be indicated in the following way:

following ...-->
      <!--
      <p>This simple example shows the latter of the two options: The relevant changes are declared
         in the header; then textual alterations and acts of writing are associated with them. The
         above markup indicates that the whole sentence was realized in the first stage, while the
         substitution of “house” with “mouse” happened at the second stage. </p>
      <p>A more complex and complete example:</p>
      <egXML xmlns="http://www.tei-c.org/ns/Examples">
         <profileDesc>
            <creation>
               <listChange ordered="true">
                  <change xml:id="firstStage">First stage, written in ink by a writer</change>
                  <change xml:id="secondStage">Revised by Goethe using pencil</change>
                  <change xml:id="thirdStage">Fixation of the revised passages and further revisions
                     by Goethe using ink</change>
                  <change xml:id="fourthStage">Addition of another stanza, probably at a later
                     stage</change>
               </listChange>
            </creation>
         </profileDesc> [...] <div change="#firstStage">
            <l n="11656">
               <subst>
                  <del>Ihr</del>
                  <add>
                     <retrace change="#thirdStage">
                        <seg change="#secondStage">Nun</seg>
                     </retrace>
                  </add>
               </subst> wanſtige Schuften mit den Feuerbacken</l>
            <l n="11657">Ihr glüht ſo recht vom Höllen Schwefel <subst
                  change="#secondStage #thirdStage">
                  <del>ſatt</del>
                  <add>feiſt</add>
               </subst>.</l>
            <l n="11658">
               <delSpan spanTo="#anchor_delSpan_1" change="#thirdStage"/>Ihr hagren, triſten, krummgezog<subst>
                  <del>nen</del>
                  <add>ener</add>
               </subst> Nacken</l>
            <l>Wenn ihr nur piepſet iſt die Welt ſchon matt.<anchor xml:id="anchor_delSpan_1"/></l>
         </div>
      </egXML>
     <p>Note first that a change, once assigned to an element, is inherited by all descendants of
         that element unless overridden by a subsequent assignment. So in the example above the
         three lines are assigned to the first stage initially. The writing of
            <mentioned>Nun</mentioned> (as part of the substitution in the first line) takes place
         in the second stage and is repeated or fixed in the third. Also the substitution in the
         second line is done repeatedly: initially it takes place in the second stage, but is
         fixated as a whole in the third.</p>-->
      <p>The interpretation of change assignments for a particular text passage is based on a number
         of implicit assumptions and constraints which have the effect of minimizing the amount of
         tagging necessary. The system is also flexible enough to support an explicit distinction
         between acts of writing and textual alterations, since either of these can be associated
         with changes described in the encoding. The following example shows an encoding in which
         the same passage is transcribed twice, once from a documentary perspective, and once from a
         textual one: <egXML xmlns="http://www.tei-c.org/ns/Examples">
            <profileDesc>
               <creation>
                  <listChange ordered="true">
                     <change target="#zone_1 #subst_3">First stage, written in ink by a
                        scribe</change>
                     <change
                        target="#zone_2 #mod_1 #line_1 #line_2 #subst_1 #subst_2
#subst_4 #delSpan_1"
                        >Revised by Goethe using pencil</change>
                     <change target="#redo_1 #redo_2 #redo_3 #subst_1 #subst_2
#delSpan_1 #add_1"
                        >Fixation of the revised passages and further revisions by Goethe using
                        ink</change>
                  </listChange>
               </creation>
            </profileDesc>
            <sourceDoc>
               <surface>
                  <zone xml:id="zone_1">
                     <line xml:id="line_1">
                        <handShift new="#g_bl"/>
                        <retrace hand="#g_t" xml:id="redo_1">Nun</retrace>
                     </line>
                     <line><handShift new="#jo_t"/>Ihr wanſtige Schuften mit den Feuerbacken</line>
                     <line xml:id="line_2">
                        <handShift new="#g_bl"/>
                        <retrace hand="#g_t" xml:id="redo_2">feiſt</retrace>
                     </line>
                     <line>Ihr glüht ſo recht vom Höllen Schwefel ſatt.</line> [...] </zone>
               </surface>
            </sourceDoc>
            <text>
               <body>
                  <l n="11656">
                     <subst xml:id="subst_1">
                        <del>Ihr</del>
                        <add>Nun</add>
                     </subst> wanſtige Schuften mit den Feuerbacken</l>
                  <l n="11657">Ihr glüht ſo recht vom Höllen Schwefel <subst xml:id="subst_2">
                        <del>ſatt</del>
                        <add>feiſt</add>
                     </subst>.</l>
               </body>
            </text>
         </egXML>
      </p>

      <p>The documentary transcription stresses the writing process, while the textual transcription
         emphasizes textual alterations. In either case, the change of writing activity associated
         with a particular feature in the transcript is explicitly indicated. From the documentary
         perspective, by assigning particular modifications to a specific change, we describe the
         writing process, in that they specify which segment has been written when
         <!-- and how often-->. From the textual perspective, the markup concentrates simply on the
         existence of textual alterations and makes no explicit claims about the order of writing.
         <!-- In this example, the association is made by pointing from the <gi>change</gi>
         element to all the passages and alterations in question in either perspective, which has
         the merit of not confusing the presentation of the interventions concerned with writing
         sequence information, at the price of requiring a distinct identifier on each intervention.-->
      </p>
   </div>



   <div type="div2" xml:id="PHTRXX">
      <head>Other Primary Source Features not Covered in these Guidelines</head>
      <p>We repeat the advice given at the beginning of this chapter, that these recommendations are
         not intended to meet every transcriptional circumstance ever likely to be faced by any
         scholar. They are intended rather as a base to enable encoding of the most common phenomena
         found in the course of scholarly transcription of primary source materials. These
         guidelines particularly do not address the encoding of physical description of textual
         witnesses: the materials of the carrier, the medium of the inscribing implement, the
         organisation of the carrier materials themselves (as quiring, collation, etc.), authorial
         instructions or scribal markup, etc., except insofar as these are involved in the broader
         question of manuscript description, as addressed by the <ident type="module"
            >msdescription</ident> module described in chapter <ptr target="#MS"/>. </p>
   </div>

   <div>
      <head>Module for Transcription of Primary Sources</head>

      <p>The module described in this chapter makes available the following components: <moduleSpec
            xml:id="DPH" ident="transcr">
            <altIdent type="FPI">Transcription of Primary Sources</altIdent>
            <desc>Transcription of primary sources</desc>
            <desc xml:lang="zh-TW">原文轉錄</desc>
            <desc xml:lang="fr">Représentation de sources primaires</desc>
            <desc xml:lang="it">Trascrizione di fonti primarie</desc>
            <desc xml:lang="pt">Transcrição de fontes primárias</desc>
            <desc xml:lang="ja">転記モジュール</desc>
         </moduleSpec><!--publicID:  -//TEI P5//ELEMENTS Additional Element Set for Transcription of Primary Sources//EN-->
         The selection and combination of modules to form a TEI schema is described in <ptr
            target="#STIN"/>. </p>
      <specGrp xml:id="DTCHD">
         <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/addSpan.xml"/>
         <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/damage.xml"/>
         <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/damageSpan.xml"/>
         <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/delSpan.xml"/>
         <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/ex.xml"/>
         <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/fw.xml"/>
         <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/handNotes.xml"/>
         <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/handShift.xml"/>
         <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/am.xml"/>
         <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/restore.xml"/>
         <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/space.xml"/>
         <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/subst.xml"/>
         <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/substJoin.xml"/>
         <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/supplied.xml"/>
         <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/surplus.xml"/>
        <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/secl.xml"/>
         <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/line.xml"/>
         <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/listChange.xml"/>
         <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/listTranspose.xml"/>
         <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/metamark.xml"/>
         <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/mod.xml"/>
         <!--<include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/patch.xml"/>-->
         <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/redo.xml"/>
         <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/retrace.xml"/>
         <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/transpose.xml"/>
         <include xmlns="http://www.w3.org/2001/XInclude" href="../../Specs/undo.xml"/>
      </specGrp>
   </div>
</div>
