<?xml version="1.0" encoding="UTF-8"?>
<!-- © TEI Consortium. Dual-licensed under CC-by and BSD2 licenses; see the file COPYING.txt for details. -->
<?xml-model href="https://jenkins.tei-c.org/job/TEIP5-dev/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" xmlns:xi="http://www.w3.org/2001/XInclude" type="div1"
   xml:id="PH" n="18">
   <head>Representation of Primary Sources</head>

   <p>This chapter describes elements that may be used to represent primary source materials, such
      as manuscripts, printed books, ephemera, or other textual documents. Some of these specialized
      elements, particularly at phrase-level, add to the other elements available within
         <gi>text</gi> to deal with textual phenomena more specific to primary source transcription.
      Other structural and block-level elements described here can be used to represent primary
      source materials by prioritizing the encoding of their spatial features over their logical
      textual structure (that is, the elements described in chapter <ptr target="#DS"/>). These
      elements, <gi>facsimile</gi>, <gi>sourceDoc</gi>, and their children, may be used in parallel
      and in combination with an encoding of logical text structures with <gi>text</gi>, or as
      standalone representations. The element <gi>sourceDoc</gi> in particular provides a way of
      combining facsimile and transcriptions by embedding transcribed text. This approach focuses on
      physical and textual features that can be primarily described spatially, such as the sequence
      of pages in a manuscript, or the layout of a printed page. This is not meant to be the only
      way of transcribing primary sources in TEI, or even a preferred way; which approach is more
      appropriate will depend on the specific needs of your project.</p>

   <p>Although this chapter discusses manuscript materials more frequently than other forms of
      written text, most of the recommendations presented are equally applicable to facsimiles of a
      wide variety of media, including printed matter, monumental inscriptions, and art. Each medium
      has its own vocabulary of agents. In the following examples, terms such as
         <soCalled>scribe</soCalled>, <soCalled>author</soCalled>, <soCalled>editor</soCalled>,
         <soCalled>annotator</soCalled> or <soCalled>corrector</soCalled> 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 <soCalled>author</soCalled> and the
         <soCalled>scribe</soCalled> are the same person.</p>

   <p>This module may be used in conjunction with other modules. These recommendations are not
      intended to meet every transcriptional circumstance 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 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 (such
      as quiring, collation), 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>

   <p>This chapter begins by describing elements for handling digitally-encoded images of primary
      source materials for the purpose of creating digital facsimiles using the <gi>facsimile</gi>
      element (<ptr target="#PHFAX"/>).</p>
   <p>The next section (<ptr target="#PH-transcr"/>) describes two ways of combining a facsimile
      images with a transcription; either by referencing a parallel transcription in <gi>text</gi>,
      or by providing an <soCalled>embedded</soCalled> transcription that prioritizes the encoding
      of a resource’s spatial features via the <gi>sourceDoc</gi> element and a number of
      transcriptional elements. </p>
   <p>Section <ptr target="#PHST"/> documents elements that support scholars in recording
      information about specific features of the text written on its physical carrier, such as <ptr
         target="#PHCH"/> and <ptr target="#PHPH"/></p>
   <p>Section <ptr target="#PHLAY"/> describes how complex page layouts may be represented.</p>
   <p>Section <ptr target="#PHSK"/> introduces the element <gi>fw</gi> (<term>forme work</term>) for
      encoding material repeated from page to page that falls outside the stream of the text.</p>
   <p>Section <ptr target="#PH-changes"/> describes how to document changes made during the
      production or revision of a primary source.</p>
   <p>The chapter concludes with a technical overview of the structure and organization of the
      module described here. Some elements from other chapters are recontexualized for situations
      involving the transcription of primary source materials, whether within <gi>text</gi> or
         <gi>sourceDoc</gi>. Therefore, this overview should be read in conjunction with chapters
         <ptr target="#CO"/> and <ptr target="#WD"/>.</p>

   <div xml:id="PHFAX">

      <head>Digital Facsimiles</head>

      <p>A common approach in the TEI to representing pre-existing sources involves transcribing or
         otherwise converting sources into character form before marking them up. However, it is
         also a common practice to make a different form of <soCalled>digital text</soCalled> that
         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 or
            <soCalled>embedded</soCalled> as discussed in <ptr target="#PH-transcr"/>. 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"
            xml:id="PHFAX-egXML-it" valid="feasible" source="#UND">
            <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>
         (page beginning) 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"/>
            <specDesc key="path" 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>sourceDoc</gi>
         element is used when a digital facsimile contains a transcription that prioritizes the
         encoding of the spatial features and layout of a text document over the text’s logical
         textual structure; the <gi>text</gi> element should be used when it contains a textual
         transcription focused on its logical features. When the digital facsimile contains only
         images, however, only <gi>facsimile</gi> elements should be used. 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 xmlns="http://www.tei-c.org/ns/Examples"
            xml:id="PHFAX-egXML-yf" xml:lang="und" source="#UND">
            <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
            xmlns="http://www.tei-c.org/ns/Examples" xml:id="PHFAX-egXML-fj" xml:lang="und"
            source="#UND">
            <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 xmlns="http://www.tei-c.org/ns/Examples"
            xml:id="PHFAX-egXML-oq" xml:lang="und" source="#UND">
            <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="https://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
            xmlns="http://www.tei-c.org/ns/Examples" xml:id="PHFAX-egXML-hx" xml:lang="und"
            source="#UND"><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" xml:id="PHFAX-egXML-jq" source="#UND"><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="https://web.archive.org/web/20191023112411/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 xmlns="http://www.tei-c.org/ns/Examples"
            xml:id="PHFAX-egXML-iv" xml:lang="und" source="#UND"><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" xml:id="PHFAX-egXML-fr"
            source="#UND"><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" xml:id="PHFAX-egXML-dk" source="#UND"><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 the examples above 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
            xmlns="http://www.tei-c.org/ns/Examples" xml:id="PHFAX-egXML-hz" xml:lang="und"
            source="#UND">
            <zone ulx="105" uly="76" lrx="175" lry="160">
               <graphic url="Bovelles49r-detail.png"/>
            </zone>
         </egXML>
      </p>


      <p>Within a <gi>surface</gi> or <gi>zone</gi>, individual lines can be identified using the
            <gi>path</gi> element, which also carries the <att>points</att> attribute: <figure
            xml:id="facs-fig3">
            <graphic url="Images/facs-fig3.jpg"/>
            <head>Smaller detail of p 49r from Bovelles highlighting two specific lines</head>
         </figure>
         <egXML xmlns="http://www.tei-c.org/ns/Examples" xml:id="PHFAX-egXML-rl">
            <surface ulx="0" uly="0" lrx="443" lry="272">
               <graphic url="facs-fig3.jpg"/>
               <path points="74,73 171,244" xml:id="balan"/>
               <path points="71,203 173,116" xml:id="dindan"/>
            </surface></egXML> This is useful for linking an annotation or explanation to a specific
         line on an object surface. Any number of coordinates can be included to specify lines which
         are not straight; this example shows how the first of the famous <soCalled>story
            lines</soCalled> appearing at the beginning of chapter 40 of <title level="m">Tristram
            Shandy</title> might be encoded: <figure xml:id="facs-fig4">
            <graphic url="Images/sterne.png"/>
            <head>Page 152 of <title level="m">Tristram Shandy</title></head>
         </figure>
         <egXML xmlns="http://www.tei-c.org/ns/Examples" xml:id="PHFAX-egXML-lp">
            <surface ulx="0" uly="0" lrx="411" lry="652">
               <graphic url="sterne.png"/>
               <path
                  points="65,511 88,510 92,517                    100,521 107,520 112,516 116,512                    117,511 152,512 156,508 162,505                    169,505 174,506 178,509 179,512                    236,514 136,479 208,493 270,512                    328,513 336,525 339,528 339,536                    331,539 328,535 329,530 334,526                    342,521 345,519 350,512 397,514                    402,498 414,515 425,515 435,531                    440,513 475,513 475,518 477,520                    479,521 481,522 483,521 484,518                    486,516 486,514 491,512 494,514                    496,520 496,529 493,535 494,539                    497,543 501,543 504,543 507,540                    508,537 507,526 505,518 502,510                    501,508 501,503 503,501 506,500                    510,500 512,503 513,507 511,513                    543,516 552,513 552,501 550,496                    549,490 552,486 562,487 564,468                    559,465 557,462 556,457 558,453                    562,450 570,451 573,446 579,433"
               />
            </surface></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 can be presented as an embedded 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" xml:id="PH-bov-egXML-tn"
               source="#UND"><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:id="PH-bov-egXML-hh" 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
               xmlns="http://www.tei-c.org/ns/Examples" xml:id="PH-bov-egXML-zh" xml:lang="und"><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">
            <xi:include href="../../Specs/facsimile.xml"/>
            <xi:include href="../../Specs/sourceDoc.xml"/>
            <xi:include href="../../Specs/att.global.facs.xml"/>
            <xi:include href="../../Specs/att.global.change.xml"/>
            <xi:include href="../../Specs/surface.xml"/>
            <xi:include href="../../Specs/surfaceGrp.xml"/>
            <xi:include href="../../Specs/att.coordinated.xml"/>
            <xi:include href="../../Specs/zone.xml"/>
            <xi:include href="../../Specs/path.xml"/>
            <xi:include href="../../Specs/model.resource.xml"/>
            <xi:include href="../../Specs/model.describedResource.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" xml:id="PHZLAB-egXML-kf">
            <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" xml:id="PHZLAB-egXML-pk" 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 xml:id="PH-surfzone">
            <head>Advanced Uses of <gi>surface</gi> and <gi>zone</gi></head>

            <p>As a child of <gi>sourceDoc</gi>, the <gi>surface</gi> element both identifies a
               specific area containing writing and provides a two dimensional set of coordinates
               which can be used to position and define dimensions for sub-parts of it. In the
               context of three-dimensional objects, the <gi>surface</gi> element also provides a
               three-dimensional set of points which can be used to define the dimensions of the
               object. 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
                  xmlns="http://www.tei-c.org/ns/Examples" xml:id="PH-surfzone-egXML-rj"
                  source="#WHITMS2">
                  <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" xml:id="PH-surfzone-egXML-mr">
                  <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" xml:id="PH-surfzone-egXML-bu"
               source="#UND">
               <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
                  xml:id="PH-surfzone-figure-mc">
                  <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" xml:id="PH-surfzone-egXML-vy"
                  source="#UND">
                  <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>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
                  xmlns="http://www.tei-c.org/ns/Examples" xml:id="PH-surfzone-egXML-of"
                  xml:lang="und" source="#UND"><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
                  xmlns="http://www.tei-c.org/ns/Examples" xml:id="PH-surfzone-egXML-du"
                  xml:lang="und" source="#UND"><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>
            <p>Finally, if you are using the <gi>surface</gi> and <gi>zone</gi> elements to encode a
               three-dimensional object, it is essential to include the Z-axis as well as the X- and
               Y- axes. You can represent the spatial information of a three-dimensional object
               using the <att>points</att> attribute to construct a polygonal shape. When you are
               using the <gi>surface</gi> and <gi>zone</gi> elements in a three-dimensional context,
               the <gi>surface</gi> element represents the surface of the entire three-dimensional object. The
                  <gi>graphic</gi> element can then be used to reference an image or three-dimensional model
               of the object. All the zones of interest on the object can be defined using the
                  <gi>zone</gi> element. For example, if a monument features both a relief and an
               inscription, the <gi>zone</gi> element can be used to delineate each feature
               respectively. You can use the <att>points</att> attribute on a <gi>zone</gi> element
               to represent the three-dimensional spatial information for these zones of interest.
                  <egXML xmlns="http://www.tei-c.org/ns/Examples" xml:id="PH-surfzone-egXML-jo"
                  xml:lang="und" source="#UND">
                  <sourceDoc>
                     <surface xml:id="inscription" type="3Dobject">
                        <figure>
                           <graphic type="model" subtype="glb" url="inscription1.glb"/>
                           <graphic type="texture" url="texture.png"/>
                        </figure>
                        <zone xml:id="inscription1">
                           <zone xml:id="inscription1_relief"/>
                           <zone xml:id="inscription1_text" points="0,1,0 1,0,0 -1,0,0 0,-1,0">
                              <lb n="1"/>
                              <choice><expan><abbr>D</abbr><ex>is</ex></expan></choice>
                              <choice><expan><abbr>M</abbr><ex>anibus</ex></expan></choice>
                              <zone xml:id="inscription1_l2"
                                 points="0,0,0 0.5,0,0 -0.5,0,0 0,-0.5,0">
                                 <lb n="2"/><gap reason="lost" extent="unknown" unit="character"/>
                                 <zone>M</zone><zone>I</zone>
                              </zone>
                              <zone xml:id="inscription1_l3"
                                 points="0,-0.5,0 -0.5,0,0 0.5,0,0 0,0.5,0">
                                 <lb n="3" break="no"/><gap reason="lost" extent="unknown"
                                    unit="char"/>
                                 <zone>R</zone>
                              </zone>
                              <lb n="4" break="no"/>
                              <gap reason="lost" extent="unknown" unit="char"/> XXXXVII
                                       <choice><expan><abbr>stip</abbr><ex>endiorum</ex></expan></choice>
                              <lb n="5"/> XXVIII
                                 <choice><expan><abbr>Iul</abbr><ex>ius</ex></expan></choice>
                              Martialis <lb n="6"/>
                              <choice><expan><abbr>dupl</abbr><ex>icarius</ex></expan></choice> alae
                                       Britan<choice><expan><ex>n</ex><abbr>ic</abbr><ex>a</ex><abbr>e</abbr></expan></choice>
                              <lb n="7"/> heres Ermius <lb n="8"
                                       /><choice><expan><abbr>lib</abbr><ex>ertus</ex></expan></choice>
                              eius </zone>
                        </zone>
                     </surface>
                  </sourceDoc>
               </egXML>
            </p>
         </div>
      </div>

   </div>

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

      <p>When transcribing a primary source, whether using <gi>text</gi> or <gi>sourceDoc</gi>,
         scholars may wish to record information concerning individual readings of letters, words,
         or larger units. 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:
               pagination, lineation, unusual spaces, changes of manuscript hand, etc. (section <ptr
                  target="#PHPH"/>)</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 (<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.global.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 xml:id="PHAB-figure-zk">
                  <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" xml:id="PHAB-egXML-nu"
                  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"
                  xml:id="PHAB-egXML-av"><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"
                  xml:id="PHAB-egXML-wb"><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" xml:id="PHAB-egXML-rb"><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" xml:id="PHAB-egXML-dx"><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"
                  xml:id="PHAB-egXML-ss"><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" xml:id="PHAB-egXML-pi">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" xml:id="PHAB-egXML-on" 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" xml:id="PHAB-egXML-lg"><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" xml:id="PHAB-egXML-qs">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" xml:id="PHAB-egXML-sn">
                  <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" xml:id="PHAB-egXML-wu">For alle the while
                  that I had <choice><sic>goo<abbr>ɗ</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" xml:id="PHCC-egXML-ud">But <sic>One</sic>
                  must have lived ...</egXML> or corrected: <egXML
                  xmlns="http://www.tei-c.org/ns/Examples" xml:id="PHCC-egXML-cy">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"
                  xml:id="PHCC-egXML-la">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
                  xmlns="http://www.tei-c.org/ns/Examples" xml:id="PHCC-egXML-xr" xml:lang="la"
                  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" xml:id="PHCC-egXML-mk" 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" xml:id="PHCC-egXML-lp">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"
                  xml:id="PHCC-egXML-ff">
                  <!-- 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 xmlns="http://www.tei-c.org/ns/Examples"
                  xml:id="PHCC-egXML-kd" xml:lang="la" 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"
                  xml:id="PHCC-egXML-tv"><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
                  xmlns="http://www.tei-c.org/ns/Examples" xml:id="PHCC-egXML-lg" xml:lang="la"
                  >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
                  xmlns="http://www.tei-c.org/ns/Examples" xml:id="PHCC-egXML-bk" xml:lang="la"
                  >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" xml:id="PHCC-egXML-ru">
                  <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"
                  xml:id="PHCC-egXML-mp"> 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 an <gi>msDesc</gi> element (see <ptr target="#MS"/>): <egXML
                  xmlns="http://www.tei-c.org/ns/Examples" xml:id="PHCC-egXML-wl">
                  <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" xml:id="PHCC-egXML-px">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" xml:id="PHCC-egXML-lm">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" xml:id="PHAD-egXML-cg" 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" xml:id="PHAD-egXML-wl" 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 xml:id="PHAD-figure-pk">
                  <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" xml:id="PHAD-egXML-ap" source="#UND">
                  <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" xml:id="PHAD-egXML-li" 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" xml:id="PHAD-egXML-dk" 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" xml:id="PHAD-egXML-pl"
                  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"
                  xml:id="PHAD-egXML-dp" 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" xml:id="PHAD-egXML-qe" 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" xml:id="PHAD-egXML-la">
                  <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" xml:id="PHAD-egXML-kw" 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"
                  xml:id="PHSU-egXML-fa"><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" xml:id="PHSU-egXML-oz">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>A special case of a substitution may consist of a superfluous word or phrase that is
               silently replaced by some addition. E.g. a scribe abandons a word (without indicating
               it should be deleted), and then writes a replacement word immediately after. Here the
               encoder may interpret this as an <soCalled>unmarked</soCalled> deletion which can
               then be combined with a corresponding addition to a substitution.</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" xml:id="PHSU-egXML-zw"> 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 xml:id="PHSU-figure-ju">
                  <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" xml:id="PHSU-egXML-ca" 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" xml:id="PHSU-egXML-on">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" xml:id="PHCD-egXML-hg">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 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" xml:id="PHOM-egXML-sc" source="#PH-eg-05"
                  >Others <gap reason="cancelled" 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"
                  xml:id="PHOM-egXML-me" 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"
                     xml:id="PHOM-egXML-xs" source="#PHegsurp">
                     <sic>dedikararunt</sic>
                  </egXML></item>
               <item>additionally supply a corrected form <egXML
                     xmlns="http://www.tei-c.org/ns/Examples" xml:id="PHOM-egXML-ya"
                     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"
                     xml:id="PHOM-egXML-lh" 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" xml:id="PHOM-egXML-qo"
                  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" xml:id="PHOM-egXML-qj" 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" xml:id="PHOM-egXML-ng"
                  >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>A <gi>handShift</gi> element can be used to indicate a change of hand even within an
               element with a <att>hand</att> attribute. The text following the <gi>handShift</gi>
               must be considered to be in the new hand. </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"
                  xml:id="PHDH-egXML-vu" 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" xml:id="PHDH-egXML-iz">
                  <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" xml:id="PHDH-egXML-gu" 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>
            <!-- TODO: This discussion needs @source! -->
            <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" xml:id="PHHR-egXML-xs"><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. It should be noted that the <att>source</att> attribute may be used in a
               simiilar fashion to indicate, for example, when an encoding decision is based on the
               work of a previous editor or on an article. In that case, the <att>source</att> would
               point to a <gi>bibl</gi> in the bibliography.</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" xml:id="PHHR-egXML-yh">
                  <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" xml:id="PHHR-egXML-pz">
                  <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" xml:id="PHDA-egXML-ga" 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"
                  xml:id="PHDA-egXML-ou" 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" xml:id="PHDA-egXML-jl"><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
                  xmlns="http://www.tei-c.org/ns/Examples" xml:id="PHDA-egXML-yb" xml:lang="mul">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 xmlns="http://www.tei-c.org/ns/Examples" xml:id="PHDA-egXML-fa"
                  xml:lang="mul">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 xmlns="http://www.tei-c.org/ns/Examples" xml:id="PHDA-egXML-yj"
                  xml:lang="mul" 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
                  xmlns="http://www.tei-c.org/ns/Examples" xml:id="PHDA-egXML-uq" xml:lang="mul"
                  source="#PH-eg-13">um aldr d<damage agent="rubbing"><supplied source="#msm"
                        >aga</supplied></damage> yndisniota</egXML> The transcriber may also provide
               alternative conjectures by enclosing multiple <gi>supplied</gi> elements within a
                  <gi>choice</gi> element.</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
                  xmlns="http://www.tei-c.org/ns/Examples" xml:id="PHDA-egXML-uf" xml:lang="mul"
                  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"
                  xml:id="PHDA-egXML-sn"><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" xml:id="PHDA-egXML-xq"
                  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. Note that the
                        <gi>gap</gi> could be wrapped in a <gi>del</gi> or <gi>damage</gi> element.
                     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" xml:id="PHCOMB-egXML-es">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"
                     xml:id="PHCOMB-egXML-fk"><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"
                     xml:id="PHCOMB-egXML-ky"><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"
                     xml:id="PHCOMB-egXML-bd"><add>This sentence was added <del>eventually</del> to
                        the text.</add></egXML></item>
               <item>When some text has been blackened out so thoroughly that can no longer be read,
                  the encoding should be: <egXML xmlns="http://www.tei-c.org/ns/Examples"
                     xml:id="PHCOMB-egXML-wo">runs out the door in <gap extent="1 word"/>
                     shirt</egXML></item>
               <item>For consistency, one might prefer to encode the deletion as such, using
                     <gi>del</gi>, and containing a <gi>gap</gi>, as in the following example:
                     <egXML xmlns="http://www.tei-c.org/ns/Examples" xml:id="PHCOMB-egXML-ss">runs
                     out the door in <del><gap extent="1 word"/></del> shirt</egXML></item>
               <item>This is something that would be necessary if one wanted to encode a
                     <gi>subst</gi> including an illegible deletion: <egXML
                     xmlns="http://www.tei-c.org/ns/Examples" xml:id="PHCOMB-egXML-jk"
                              >sum<subst><del><gap extent="2 characters"/></del><add place="inline"
                           >mo</add></subst>ns</egXML></item>
               <item>If some parts of the deleted text are readable, and other parts unreadable, it
                  should be encoded as in the following example: <egXML
                     xmlns="http://www.tei-c.org/ns/Examples" xml:id="PHCOMB-egXML-zx">Billy in The
                           <del><gap extent="1 character"/>ng<gap extent="2 characters"/></del>
                     Silver Dollar.. </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" xml:id="PH-mod-egXML-gu">
               <line>words words words <mod rend="wavy-underlining" spanTo="#enduw"/>words with wavy
                  underline</line> &lt;!-- more lines here --&gt; <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
                  xml:id="PH-meta-figure-rf">
                  <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 as an embedded transcription (keeping in mind that the
               elements described here can also be used within <gi>text</gi>):
                  <!-- ka04_1v-dtl.xml --><egXML xmlns="http://www.tei-c.org/ns/Examples"
                  xml:id="PH-meta-egXML-iv">
                  <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 xml:id="PH-meta-figure-ak">
                  <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
               proofreading mark resembling the <q>deleatur</q> or <q>dele</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 xml:id="PH-meta-figure-iv">
                  <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" xml:id="PH-meta-egXML-hy">
               <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 embedded transcription 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. <gi>metamark</gi> can be similarly used within <gi>text</gi> to encode the same
               phenomenon as part of a transcription that privileges logical over physical and
               layout structures. </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 xml:id="PH-fix-figure-ux">
                  <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" xml:id="PH-fix-egXML-uz"> Sku<retrace
                     cause="unclear">l</retrace>dren </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
                  xml:id="PH-fix-figure-hp">
                  <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" xml:id="PH-fix-egXML-rs"
                  source="#PH-ib05"> ved Bæg<retrace cause="unclear" change="#stage2">
                     <retrace cause="unclear" change="#stage1">er</retrace>
                  </retrace> ... </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 xml:id="undo-figure-of">
                  <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" xml:id="undo-egXML-mn"> 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. </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 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" xml:id="undo-egXML-az"> 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. <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
                  xml:id="transpo-figure-hg">
                  <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" xml:id="transpo-egXML-gp"
                  source="#PH-ib04">
                  <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>
                  <!-- either nearby or elsewhere, typically inside <profileDesc> or <standOff>: -->
                  <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. The following example uses an embedded transcription approach,
               which typically identifies lines of writing with the <gi>line</gi> element. This
               makes it trivial to refer to the transposed line, but when encoding transposition
               within <gi>text</gi> the encoder will need to find a way to identify the line with
               another element, such as <gi>seg</gi>.<figure xml:id="transpo-figure-lj">
                  <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"
                  xml:id="transpo-egXML-ch" 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>
                  <!-- either nearby or elsewhere, typically inside <profileDesc> or <standOff>: -->
                  <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, in the <gi>profileDesc</gi> of the header, or in a <gi>standOff</gi>
               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 xml:id="alter-figure-ic">
                  <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" xml:id="alter-egXML-dt"
                  source="#PH-eg-09">Alone <seg xml:id="alt1">before</seg>
                  <add place="above" xml:id="alt2">beside</add> his native river ­— <alt
                     target="#alt1 #alt2" mode="excl" weights="0 1"/>
               </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 xml:id="instantcorr-figure-ei" 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"
                  xml:id="instantcorr-egXML-xu" source="#WHITMS1">
                  <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 </egXML>
            </p>
         </div>
      </div>
   </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 xmlns="http://www.tei-c.org/ns/Examples"
            xml:id="PHLAY-egXML-vd" xml:lang="und" source="#UND"><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 xml:id="PHLAY-figure-pu">
            <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 a non-embedded transcription has been provided, using the <gi>text</gi> element, it
         is still possible to record gathering beginnings, page beginnings, column beginnings, line
         beginnings 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 an <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"
               xml:id="PHSP-egXML-kv">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" xml:id="PHSP-egXML-js">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"
               xml:id="PHLN-egXML-yt">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" xml:id="PHLN-egXML-bp" 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" xml:id="PHLN-egXML-ps">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="PHRB">
      <head>Transcription and Ruby</head>

      <p>These Guidelines also provide special elements to support the encoding of ruby annotations,
         which are common in East Asian textual traditions. These elements provide a method of
         capturing a specific type of annotation, in addition to the generic methods like the
            <gi>note</gi> or <gi>interp</gi> elements. Both the specific and general methods should
         integrate well with the transcriptional elements described above, allowing authorial and
         scribal features to be captured in conjunction with ruby base text and annotations. See
            <ptr target="#COHTGRB"/> for more information about these elements.</p>
   </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" xml:id="PHSK-egXML-kl"><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>Identifying Changes and Revisions</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
         regard a particular set of alterations (deletions, additions, substitutions,
         transpositions, etc.) or any other act of writing as a single object for which we use the
         general term <term>change</term>, 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 <soCalled>change</soCalled> as
               defined above</item>
            <item>a way to characterize each such change, in itself and in relation to
               others.</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 set of alterations identified: <specList>
            <specDesc key="listChange" atts="ordered"/>
            <specDesc key="change"/>
         </specList>
      </p>

      <p>In the following example an editor has identified four distinct sets of alterations:</p>
      <egXML xmlns="http://www.tei-c.org/ns/Examples" xml:id="PH-changes-egXML-zh">
         <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 sets
         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 <gi>change</gi> elements of smaller coverage, whose members are
         certainly related, and then in a subsequent pass grouping these in turn, thereby extending
         their reach.</p>

      <egXML xmlns="http://www.tei-c.org/ns/Examples" xml:id="PH-changes-egXML-je">
         <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> element is also useful to indicate a <emph>partial</emph>
         ordering of <gi>change</gi> elements.</p>
      <egXML xmlns="http://www.tei-c.org/ns/Examples" xml:id="PH-changes-egXML-os">
         <listChange ordered="true">
            <change xml:id="ST1">The first stage</change>
            <listChange ordered="false">
               <!-- 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 being ordered by their sequence within a
            <gi>listChange</gi> element, <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 element 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" xml:id="PH-changes-egXML-ks">
         <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 moment or phase 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
         between a textual component and a <gi>change</gi> element is always made explicitly, either
         by using the <att>target</att> attribute on the <gi>change</gi> element to point to one or
         more textual 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"
            xml:id="PH-changes-egXML-ko">
            <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"
            xml:id="PH-changes-egXML-al">
            <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 <gi>change</gi> element. The word <q>house</q>, because its deletion forms part of
         this second set of alterations, must have been present originally, whereas the word
            <q>mouse</q> must have been added during the second set of alterations. </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 set of alterations 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 <gi>change</gi> elements with respect to 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"
            xml:id="PH-changes-egXML-dj">
            <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 <gi>change</gi> element,
         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.), and
         authorial instructions or scribal markup, 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">
            <idno type="FPI">Transcription of Primary Sources</idno>
            <desc xml:lang="en" versionDate="2006-09-13">Transcription of primary sources</desc>
            <desc xml:lang="zh-TW" versionDate="2018-07-12">原文轉錄</desc>
            <desc xml:lang="fr" versionDate="2018-07-12">Représentation de sources primaires</desc>
            <desc xml:lang="it" versionDate="2018-07-12">Trascrizione di fonti primarie</desc>
            <desc xml:lang="pt" versionDate="2018-07-12">Transcrição de fontes primárias</desc>
            <desc xml:lang="ja" versionDate="2018-07-12">転記モジュール</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">
         <xi:include href="../../Specs/addSpan.xml"/>
         <xi:include href="../../Specs/damage.xml"/>
         <xi:include href="../../Specs/damageSpan.xml"/>
         <xi:include href="../../Specs/delSpan.xml"/>
         <xi:include href="../../Specs/ex.xml"/>
         <xi:include href="../../Specs/fw.xml"/>
         <xi:include href="../../Specs/handNotes.xml"/>
         <xi:include href="../../Specs/handShift.xml"/>
         <xi:include href="../../Specs/am.xml"/>
         <xi:include href="../../Specs/restore.xml"/>
         <xi:include href="../../Specs/space.xml"/>
         <xi:include href="../../Specs/subst.xml"/>
         <xi:include href="../../Specs/substJoin.xml"/>
         <xi:include href="../../Specs/supplied.xml"/>
         <xi:include href="../../Specs/surplus.xml"/>
         <xi:include href="../../Specs/secl.xml"/>
         <xi:include href="../../Specs/line.xml"/>
         <xi:include href="../../Specs/listChange.xml"/>
         <xi:include href="../../Specs/listTranspose.xml"/>
         <xi:include href="../../Specs/metamark.xml"/>
         <xi:include href="../../Specs/mod.xml"/>
         <!--<xi:include href="../../Specs/patch.xml"/>-->
         <xi:include href="../../Specs/redo.xml"/>
         <xi:include href="../../Specs/retrace.xml"/>
         <xi:include href="../../Specs/transpose.xml"/>
         <xi:include href="../../Specs/undo.xml"/>
      </specGrp>
   </div>
</div>
