<TEI xmlns="http://www.tei-c.org/ns/1.0">
  <teiHeader>
    <fileDesc>
      <titleStmt>
        <title type="main">TEI by Example</title>
        <title type="sub">Module 7: Critical Editing</title>
        <author xml:id="RvdB">Ron Van den Branden</author>
        <editor xml:id="EV">Edward Vanhoutte</editor>
        <editor xml:id="MT">Melissa Terras</editor>
        <sponsor>Association for Literary and Linguistic Computing (ALLC)</sponsor>
        <sponsor>Centre for Data, Culture and Society, University of Edinburgh, UK</sponsor> 
        <sponsor>Centre for Digital Humanities (CDH), University College London, UK</sponsor>
        <sponsor>Centre for Computing in the Humanities (CCH), King’s College London, UK</sponsor>
        <sponsor>Centre for Scholarly Editing and Document Studies (CTB) , Royal Academy of Dutch Language and Literature, Belgium</sponsor>
        <funder>
          <address>
            <addrLine>Centre for Scholarly Editing and Document Studies (CTB)</addrLine>
            <addrLine>Royal Academy of Dutch Language and Literature</addrLine>
            <addrLine>Koningstraat 18</addrLine>
            <addrLine>9000 Gent</addrLine>
            <addrLine>Belgium</addrLine>
          </address>
          <email>ctb@kantl.be</email>
        </funder>
        <principal>Edward Vanhoutte</principal>
        <principal>Melissa Terras</principal>
      </titleStmt>
      <publicationStmt>
        <publisher>Centre for Scholarly Editing and Document Studies (CTB) , Royal Academy of Dutch Language and Literature, Belgium</publisher>
        <distributor>Centre for Scholarly Editing and Document Studies (CTB) , Royal Academy of Dutch Language and Literature, Belgium</distributor>
        <pubPlace>Gent</pubPlace>
        <address>
          <addrLine>Centre for Scholarly Editing and Document Studies (CTB)</addrLine>
          <addrLine>Royal Academy of Dutch Language and Literature</addrLine>
          <addrLine>Koningstraat 18</addrLine>
          <addrLine>9000 Gent</addrLine>
          <addrLine>Belgium</addrLine>
        </address>
        <availability status="free">
          <p>Licensed under a <ref target="http://creativecommons.org/licenses/by-sa/3.0/">Creative Commons Attribution ShareAlike 3.0 License</ref>
                    </p>
        </availability>
        <date when="2010-07-09">9 July 2010</date>
      </publicationStmt>
      <seriesStmt>
        <title>TEI By Example.</title>
        <respStmt>
          <name>Edward Vanhoutte</name>
          <resp>editor</resp>
        </respStmt>
        <respStmt>
          <name>Ron Van den Branden</name>
          <resp>editor</resp>
        </respStmt>
        <respStmt>
          <name>Melissa Terras</name>
          <resp>editor</resp>
        </respStmt>
      </seriesStmt>
      <sourceDesc>
        <p>Digitally born</p>
      </sourceDesc>
    </fileDesc>
    <encodingDesc>
      <projectDesc>
        <p>TEI By Example offers a series of freely available online tutorials walking individuals through the different stages in marking up a document in TEI (Text Encoding Initiative). Besides a general introduction to text encoding, step-by-step tutorial modules provide example-based introductions to eight different aspects of electronic text markup for the humanities. Each tutorial module is accompanied with a dedicated examples section, illustrating actual TEI encoding practise with real-life examples. The theory of the tutorial modules can be tested in interactive tests and exercises.</p>
      </projectDesc>
    </encodingDesc>
    <profileDesc>
      <langUsage>
        <language ident="en-GB">en-GB</language>
      </langUsage>
    </profileDesc>
    <revisionDesc>
      <change when="2020-07-02" who="#RvdB">proofing corrections</change>
      <change when="2020-06-12" who="#RvdB">technical revision</change>
      <change when="2010-07-13" who="#RvdB">
                <list>
                    <item>added distinction <gi>gi</gi> — <tag>gi scheme="..."</tag> — <gi>tag</gi>
                    </item>
        <item>final spellcheck</item>
                </list>
            </change>
      <change when="2010-07-09" who="#RvdB">release</change>    
      <change when="2009-09-28" who="RvdB">authoring</change>
    </revisionDesc>
  </teiHeader>
  <text xml:id="TBED07v00" type="tutorials">
    <body>
            <head>Module 7: Critical Editing</head>
            <div xml:id="intro">
        <head>Introduction</head>
        <p>When texts are considered random combinations of strings, this can entertain interesting predictions about the completion of the complete works of William Shakespeare by a(n army of) hypothetical monkey(s) randomly hitting the keys on a typewriter (see <ref target="http://en.wikipedia.org/wiki/Infinite_monkey_theorem">the infinite monkey theorem</ref>). Indeed, to a computer, the textual universe <emph>is</emph> a <ref target="http://en.wikipedia.org/wiki/The_Library_of_Babel">library of Babel</ref>, in which every possible text is as likely (or rather <emph>un</emph>likely) to exist as any other text. From this perspective, perfect duplicates may perfectly co-exist with gazillions of close approximations and texts that have nothing in common at all. In an intellectual, human context, where characters are ordered along (arbitrary) rules, two sensible texts will most likely have nothing in common at all, rather than being related in any way. In fact, the chances of identical texts can almost be ruled out to either perfect mechanical photocopies, or blatant cases of plagiarism, and as such be considered uninteresting from an intellectual point of view. However, especially in the context of greatly valued literary, cultural, and/or historical works, the odd chance that such a text has a closely resembling counterpart becomes quite interesting. It may at least indicate some kind of relationship between both texts, even provide insight in its transmission through time, shed light on its history and conception, perhaps tell us something about the creative process of its author, or by extension provide insights in The Creative Process in the working of the human mind. These domains of knowledge inform different kinds of theories of textual criticism, each with their own research interests, principles and practises. What they all have in common, however, is an attempt to represent related texts found in different physical <term>witnesses</term> as different <term>versions</term> of the same abstract <term>work</term>.</p>
        <p>As we have seen already, in order to make this world of meaning accessible to/via computers, text encoding with TEI provides a sensible approach. Moreover, besides the general provisions for text encoding, the TEI Guidelines define a range of specific elements and mechanisms to represent textual variation in a sensible way for further analysis. The TEI Guidelines devote a complete chapter, <ref target="https://tei-c.org/release/doc/tei-p5-doc/en/html/TC.html">12. Critical Apparatus</ref>, to the documentation of specific elements that are grouped into the <ident type="module">textcrit</ident> module for the encoding of textual variation. In order to use the elements covered in this tutorial module, you are thus required to include the dedicated <ident type="module">textcrit</ident> TEI module in your TEI schema.<note>For directions on composing a TEI schema by selecting TEI modules and elements, see <ptr type="crossref" target="TBED08v00.xml"/>.</note>
                </p>
      </div>
            <div xml:id="variation">
        <head>Textual Variation</head>
        <p>Similar to all other TEI modules, the elements and attributes defined in the TEI <ident type="module">textcrit</ident> module can be used for the encoding of existing source materials (be they in print or digital form), or the encoding of electronic documents from scratch. However, the <emph>use</emph> of this module in the context of electronic critical editing, adds another perspective to this traditional authorial/editorial angle (see <ref type="bibl" target="#vanhoutte2009">Vanhoutte and Van den Branden 2009</ref>). Electronic or digital critical editions can be created from scratch either by encoding different primary source materials straight <emph>as</emph> a critical edition, or by generating the edition from previously encoded electronic transcriptions of those materials as independent texts in their own right. Therefore, the tags defined in the TEI <ident type="module">textcrit</ident> module can be used to: 
          <list type="gloss">
            <label>digitise</label>
            <item>an existing print edition</item>
            <label>create</label>
            <item>a digital edition, e.g., by recording some or all of the known variations among different witnesses to the text in a critical apparatus of variants</item>
            <label>generate</label>
            <item>a digital edition from encoded transcriptions of the documentary source material</item>
          </list>
        </p>
        <p>In the examples in this TBE module, <soCalled>critical editing with TEI</soCalled> will be understood as the act of encoding material sources in a TEI representation that allows for the creation or generation of a digital edition in some form (using any output format in the digital medium, e.g., HTML pages, PDF, flash movies,...), rather than digitising an existing critical edition. In this sense, the authorial/editorial angle of this TBE module differs from that of the other modules (focusing on the digitisation of a material source text in a certain genre). However, the strategies discussed in this tutorial for representing textual variation can equally be applied to the digitisation of existing critical editions. Where there are differences, these will be pointed out explicitly.</p>
        <p>For example, consider following texts:
          <table rows="2" cols="2" xml:id="table1">
            <row>
              <cell>
                <figure xml:id="figure1">
                  <graphic url="../../../images/tutorials/TBED07v00/SG_P2_small.jpg"/>
                  <head type="legend">A page of version P2 of the TEI Guidelines</head>
                </figure>
              </cell>
              <cell>
                <figure xml:id="figure2">
                  <graphic url="../../../images/tutorials/TBED07v00/SG_P3_small.jpg"/>
                  <head type="legend">A page of version P3 of the TEI Guidelines</head>
                </figure>
              </cell>
            </row>
            <row>
              <cell>
                <figure xml:id="figure3">
                  <graphic url="../../../images/tutorials/TBED07v00/SG_P4_small.jpg"/>
                  <head type="legend">A page of version P4 of the TEI Guidelines</head>
                </figure>
              </cell>
              <cell>
                <figure xml:id="figure4">
                  <graphic url="../../../images/tutorials/TBED07v00/SG_P5_small.jpg"/>
                  <head type="legend">A page of version P5 of the TEI Guidelines</head>
                </figure>
              </cell>
            </row>
          </table>
        </p>
        <p>Some of these images may look more or less familiar to you: they are facsimiles from the first page of chapter 2 of the printed TEI Guidelines throughout their different incarnations, from version P2 (1992) to the latest version, P5 (2009). As you can imagine, the technological evolutions of these 17 years have prompted considerable changes to this chapter that introduces the technological background of text encoding with TEI, ranging from rephrasing, addition or deletion of notes, changes in italicisation, restructuring of paragraphs, etc. One way of approaching this textual variation could consist of encoding these text versions as physically distinct TEI documents, in which corresponding text structures could be aligned by a common identification mechanism. For example, the first couple of paragraphs in these 4 text witnesses could be encoded in different TEI documents as follows:
          <table rows="1" cols="2" xml:id="table2">
            <row>
              <cell role="label">P2</cell>
              <cell role="label">P3</cell>
            </row>
            <row>
              <cell>
                <figure xml:id="example1">
                  <egXML xmlns="http://www.tei-c.org/ns/Examples">
                    <pb n="2"/>
                    <head>Chapter 2 <lb/>A GENTLE INTRODUCTION TO SGML</head>
                    <p xml:id="p1" corresp="P3.xml#p1 P4.xml#p1 P5.xml#p1">The encoding scheme defined by these Guidelines is formulated as an application of a system known as the Standard Generalized Markup Language (SGML).<note place="foot" xml:id="n1" corresp="P3.xml#n1 P4.xml#n2">
                                                <bibl>
                                                    <editor>International Organization for Standardization</editor>, <title>ISO 8879: Information processing--Text and office systems--Standard Generalized Mark-up Language (SGML)</title>, ([<pubPlace>Geneva</pubPlace>]: <publisher>ISO</publisher>, <date>1986</date>).</bibl> Although widely said to be short for the surnames of its progenitors, the official expansion of this abbreviation is "Standard Generalized Markup Language."</note> SGML is an international standard for the definition of device-independent, system-independent methods of representing texts in electronic form. This chapter presents a brief tutorial guide to its main features, for those readers who have not encountered it before. For a more technical account of TEI practice in using the SGML standard, see chapter 30, "TEI Conformance," [in separate fascicle]; for a more technical description of the subset of SGML used by the TEI encoding scheme, see chapter 39, "Formal Grammar for the TEI-Interchange-Format Subset of SGML," [in separate fascicle].</p>
                    <p xml:id="p2a" corresp="P3.xml#p2a P4.xml#p2 P5.xml#p2">SGML is an international standard for the description of marked-up electronic text. More exactly, SGML is a metalanguage, that is, a means of formally describing a language, in this case, a markup language. Before going any further we should define these terms.</p>
                    <p xml:id="p2b" corresp="P3.xml#p2b P4.xml#p2 P5.xml#p2">Historically, the word markup has been used to describe annotation or other marks within a text intended to instruct a compositor or typist how a particular passage should be printed or laid out. Examples include wavy underlining to indicate boldface, special symbols for passages to be omitted or printed in a particular font and so forth. As the formatting and printing of texts was automated, the term was extend-ed to cover all sorts of special markup codes inserted into electronic texts to govern formatting, printing, or other processing.</p>
                  </egXML>
                  <head type="legend">An encoded page of version P2 of the TEI Guidelines</head>
                </figure>
              </cell>
              <cell>
                <figure xml:id="example2">
                  <egXML xmlns="http://www.tei-c.org/ns/Examples">
                    <pb n="13"/>
                    <head>Chapter 2 <lb/>A Gentle Introduction to SGML</head>
                    <p xml:id="p1" corresp="P2.xml#p1 P4.xml#p1 P5.xml#p1">The encoding scheme defined by these Guidelines is formulated as an application of a system known as the Standard Generalized Markup Language (SGML). <note place="foot" xml:id="n1" corresp="P2.xml#n1 P4.xml#n2">
                                                <bibl>
                                                    <editor>International Organization for Standardization</editor>, <title>ISO 8879: Information processing - Text and office systems - Standard Generalized Markup Language (SGML)</title>, ([<pubPlace>Geneva</pubPlace>]: <publisher>ISO</publisher>, <date>1986</date>)</bibl>
                                            </note> SGML is an international standard for the definition of device-independent, system-independent methods of representing texts in electronic form. This chapter presents a brief tutorial guide to its main features, for those readers who have not encountered it before. For a more technical account of TEI practice in using the SGML standard, see chapter 28, "Conformance," on page 727. For a more technical description of the subset of SGML used by the TEI encoding scheme, see chapter 39, "Formal Grammar for the TEI-Interchange-Format Subset of SGML," on page 1247.</p>
                    <p xml:id="p2a" corresp="P2.xml#p2a P4.xml#p2 P5.xml#p2">SGML is an international standard for the description of marked-up electronic text. More exactly, SGML is a <hi>metalanguage</hi>, that is, a means of formally describing a language, in this case, a <hi>markup language</hi>. Before going any further we should define these terms.</p>
                    <p xml:id="p2b" corresp="P2.xml#p2b P4.xml#p2 P5.xml#p2">Historically, the word <hi>markup</hi> has been used to describe annotation or other marks within a text intended to instruct a compositor or typist how a particular passage should be printed or laid out. Examples include wavy underlining to indicate boldface, special symbols for passages to be omitted or printed in a particular font and so forth. As the formatting and printing of texts was automated, the term was extended to cover all sorts of special <hi>markup codes</hi> inserted into electronic texts to govern formatting, printing, or other processing.</p>
                  </egXML>
                  <head type="legend">An encoded page of version P3 of the TEI Guidelines</head>
                </figure>
              </cell>
            </row>
            <row>
              <cell role="label">P4</cell>
              <cell role="label">P5</cell>
            </row>
            <row>
              <cell>
                <figure xml:id="example3">
                  <egXML xmlns="http://www.tei-c.org/ns/Examples">
                    <pb n="13"/>
                    <head>2 A Gentle Introduction to XML</head>
                    <note type="disclaimer" xml:id="n1">As originally published in previous editions of the Guidelines, this chapter provided a gentle introduction to 'just enough' SGML for anyone to understand how the TEI used that standard. Since then, the Gentle Guide seems to have taken on a life of its own independent of the Guidelines, having been widely distributed (and flatteringly imitated) on the web. In revising it for the present draft, the editors have therefore felt free to reduce considerably its discussion of SGML-specific matters, in favour of a simple presentation of how the TEI uses XML.</note>
                    <p xml:id="p1" corresp="P2.xml#p1 P3.xml#p1 P5.xml#p1">The encoding scheme defined by these Guidelines may be formulated either as an application of the ISO Standard Generalized Markup Language (SGML)<note place="foot" corresp="P2.xml#n1 P3.xml#n1">
                                                <bibl>
                                                    <editor>International Organization for Standardization</editor>, <title>ISO 8879: Information processing - Text and office systems - Standard Generalized Markup Language (SGML)</title>, ([<pubPlace>Geneva</pubPlace>]: <publisher>ISO</publisher>, <date>1986</date>)</bibl>
                                            </note> or of the more recently developed W3C Extensible Markup Language (XML)<note place="foot" xml:id="n3">
                                                <bibl>
                                                    <editor>World Wide Web Consortium</editor>: <title>Extensible Markup Language (XML) 1.0</title>, available from <ref target="http://www.w3.org/TR/REC-xml">http://www.w3.org/TR/REC-xml</ref>
                                                </bibl>
                                            </note>. Both SGML and XML are widely-used for the definition of device-independent, system-independent methods of storing and processing texts in electronic form; XML being in fact a simplification or derivation of SGML. In the present chapter we introduce informally the basic concepts underlying such markup languages and attempt to explain to the reader encountering them for the first time how they are actually used in the TEI scheme. Except where the two are explicitly distinguished, references to XML in what follows may be understood to apply equally well to the TEI usage of SGML. For a more technical account of TEI practice see chapter 28 <hi>Conformance</hi>; for a more technical description of the subset of SGML used by the TEI encoding scheme, see chapter 39 <hi>Formal Grammar for the TEI-Interchange-Format Subset of SGML</hi>.</p>
                    <p xml:id="p2" corresp="P2.xml#p2a P2.xml#p2b P3.xml#p2a P3.xml#p2b P5.xml#p2">XML is an extensible markup language used for the description of marked-up electronic text. More exactly, XML is a <hi>metalanguage</hi>, that is, a means of formally describing a language, in this case, a <hi>markup language</hi>. Historically, the word <hi>markup</hi> has been used to describe annotation or other marks within a text intended to instruct a compositor or typist how a particular passage should be printed or laid out. Examples include wavy underlining to indicate boldface, special symbols for passages to be omitted or printed in a particular font and so forth. As the formatting and printing of texts was automated, the term was extended to cover all sorts of special codes inserted into electronic texts to govern formatting, printing, or other processing.</p>
                  </egXML>
                  <head type="legend">An encoded page of version P4 of the TEI Guidelines</head>
                </figure>
              </cell>
              <cell>
                <figure xml:id="example4">
                  <egXML xmlns="http://www.tei-c.org/ns/Examples">
                    <pb n="xxxi"/>
                    <head>v <lb/>A Gentle Introduction to XML</head>
                    <p xml:id="p1" corresp="P2.xml#p1 P3.xml#p1 P5.xml#p1">The encoding scheme defined by these Guidelines is formulated as an application of the Extensible Markup Language (XML) (Bray et al. (eds.) (2006)). XML is widely used for the definition of device-independent, system-independent methods of storing and processing texts in electronic form. It is now also the interchange and communication format used by many applications on the World Wide Web. In the present chapter we informally introduce some of its basic concepts and attempt to explain to the reader encountering them for the first time how and why they are used in the TEI scheme. More detailed technical accounts of TEI practice in this respect are provided in chapters <hi>23. Using the TEI</hi>, <hi>1. The TEI Infrastructure</hi>, and <hi>22. Documentation Elements</hi> of these Guidelines.</p>
                    <p xml:id="p2" corresp="P2.xml#p2a P2.xml#p2b P3.xml#p2a P3.xml#p2b P4.xml#p2">Strictly speaking, XML is a metalanguage, that is, a language used to describe other languages, in this case, markup languages. Historically, the word markup has been used to describe annotation or other marks within a text intended to instruct a compositor or typist how a particular passage should be printed or laid out. Examples include wavy underlining to indicate boldface, special symbols for passages to be omitted or printed in a particular font, and so forth. As the formatting and printing of texts was automated, the term was extended to cover all sorts of special codes inserted into electronic texts to govern formatting, printing, or other processing.</p>
                  </egXML>
                  <head type="legend">An encoded page of version P5 of the TEI Guidelines</head>
                </figure>
              </cell>
            </row>
          </table>
        </p>
        <p>This would allow for maximal representation of the distinct material sources, and leave the identification of the actual variation either to further processing or human inspection. A variant of this approach could integrate the transcriptions of the text in all material witnesses in a single TEI document, and make use of appropriate linking attributes to point out the alignment between the different text structures. In their naivety, such systems are both redundant and crude. While providing <emph>all</emph> text of all text witnesses, and aligning the corresponding text structures, they provide little <emph>insight</emph> in the places where the different witnesses actually differ.</p>
        <p>In order to encode the actual textual variation between the different text versions in a meaningful way, the TEI Guidelines provide a specialised module of elements and attributes that allow you to encode textual variation at word level. This TBE tutorial will first discuss how to describe the different text witnesses represented in the critical edition; next deal with the encoding of textual variants between these witnesses in isolation; then treat different ways of integrating such records of variation within the encoding of the critical edition; and finally point out potential problems and pitfalls when creating a critical edition with TEI.</p>
      </div>
            <div xml:id="listWit">
        <head>Describing Text Witnesses</head>
        <p>When creating, generating or digitising a critical edition, it is of crucial importance to document the text witnesses whose transcriptions it contains. This can be done in a <gi>listWit</gi> (list of witnesses) element, which can be put either in the <gi>sourceDesc</gi> section of the TEI header (when creating or generating a critical edition), or somewhere in the  <gi>text</gi>, usually in the <gi>front</gi> section (when digitising an existing critical edition). The <gi>listWit</gi> element should describe each text witness in its own <gi>witness</gi> element. This element can contain a prose description of the witness in plain text, possibly enriched with a specialised element for bibliographic description (<gi>bibl</gi>, <gi>biblStruct</gi>, or <gi>biblFull</gi>). The witness definitions should provide a unique identification code in the <att>xml:id</att> attribute. This code is used as a <term>sigil</term> in the critical edition, in order to connect the textual variants with the respective witnesses in which they occur (see <ptr target="#apparatus" type="crossref"/>). For example, the witness list for our critical edition of the TEI Guidelines could look as follows:
          <figure xml:id="example5">
            <egXML xmlns="http://www.tei-c.org/ns/Examples">
              <TEI>
                <teiHeader>
                  <fileDesc>
                    <!-- ... -->
                    <sourceDesc>
                      <listWit>
                        <witness xml:id="p2">
                          <bibl>
                                                        <editor>Sperberg-McQueen, M.</editor>; <editor>Burnard, L.</editor> (eds.). <title>TEI P2 Guidelines for the Encoding and Interchange of Machine Readable Texts Draft P2</title> (published serially 1992-1993); Draft Version <date when="1993-04-02">2 of April 1993</date>: <extent>19 chapters</extent>. Available from <ptr target="https://tei-c.org/Vault/Vault-GL.html"/> (accessed October 2008).</bibl>
                        </witness>
                        <witness xml:id="p3">
                          <bibl>
                                                        <editor>Sperberg-McQueen, C.M.</editor>; <editor>Burnard, L.</editor> (eds.). <title>Guidelines for Electronic Text Encoding and Interchange. TEI P3. Revised reprint.</title>
                            <publisher>Text Encoding Initiative</publisher>: <pubPlace>Oxford</pubPlace>, <pubPlace>Providence</pubPlace>, <pubPlace>Charlottesville</pubPlace>, <pubPlace>Bergen</pubPlace>, <date when="1999">1999</date>
                                                    </bibl>
                        </witness>
                        <witness xml:id="p4">
                          <bibl>
                                                        <editor>Sperberg-McQueen, C.M.</editor>; <editor>Burnard, L.</editor> (eds.). <title>TEI P4: Guidelines for Electronic Text Encoding and Interchange. XML-compatible edition.</title>
                            <publisher>Text Encoding Initiative Consortium</publisher>: <pubPlace>Oxford</pubPlace>, <pubPlace>Providence</pubPlace>, <pubPlace>Charlottesville</pubPlace>, <pubPlace>Bergen</pubPlace>, <date when="2002">2002</date>
                                                    </bibl>
                        </witness>
                        <witness xml:id="p5">
                          <bibl>
                                                        <editor>Sperberg-McQueen, C.M.</editor>; <editor>Burnard, L.</editor> (eds.). <title>TEI P5: Guidelines for Electronic Text Encoding and Interchange. Revised and re-edited.</title>
                            <publisher>Text Encoding Initiative Consortium</publisher>: <pubPlace>Oxford</pubPlace>, <pubPlace>Providence</pubPlace>, <pubPlace>Charlottesville</pubPlace>, <pubPlace>Nancy</pubPlace>, <date when="2005">2005</date>
                                                    </bibl>
                        </witness>
                      </listWit>
                    </sourceDesc>
                  </fileDesc>
                  <!-- ... -->
                </teiHeader>
                <!-- ... -->
              </TEI>
            </egXML>
            <head type="legend">A list of witness descriptions for four versions of the TEI Guidelines</head>
          </figure>
        </p>
        <p>Such bibliographic descriptions of course are easier for printed works than for manuscripts; for the latter type of witnesses, some kind of description inside <gi>listWit</gi> is advised, preferably with a pointer (using <gi>ptr</gi> or <gi>ref</gi>) to a full description of the manuscript inside <gi>msDescription</gi>. 
          <note type="reference">For a full discussion of the <gi>msDescription</gi> element, see section <ref target="https://tei-c.org/release/doc/tei-p5-doc/en/html/MS.html#msdesc">10.2 The Manuscript Description Element</ref> of the TEI Guidelines, and section <ref target="https://tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCAPWL">12.1.4.3 The Witness List</ref> for examples of describing manuscript witnesses in a digital edition.</note>
        </p>
        <p>In a critical edition, it may make sense to discern groups of witnesses that have many text variants in common in comparison to other witnesses and can often be conveniently summarised in one sigil. In the witness list, witnesses can be grouped by wrapping their <gi>witness</gi> descriptions in nesting <gi>listWit</gi> structures. The common sigil then can be provided as the value for an <att>xml:id</att> attribute of the group’s <gi>listWit</gi> element. The nested witness groups can be labelled with a <gi>head</gi> element. For example, in our sample text witnesses it may make sense to discern those versions of the TEI Guidelines dealing with SGML, and those dealing with XML. This could look as follows:</p>
        <figure xml:id="example6">
          <egXML xmlns="http://www.tei-c.org/ns/Examples">
            <TEI>
              <teiHeader>
                <fileDesc>
                  <!-- ... -->
                  <sourceDesc>
                    <listWit>
                      <listWit xml:id="teiSGML">
                        <head>TEI Guidelines covering SGML</head>
                        <witness xml:id="p2">
                          <bibl>
                                                        <editor>Sperberg-McQueen, M.</editor>; <editor>Burnard, L.</editor> (eds.). <title>TEI P2 Guidelines for the Encoding and Interchange of Machine Readable Texts Draft P2</title> (published serially 1992-1993); Draft Version <date when="1993-04-02">2 of April 1993</date>: <extent>19 chapters</extent>. Available from <ptr target="https://tei-c.org/Vault/Vault-GL.html"/> (accessed October 2008).</bibl>
                        </witness>
                        <witness xml:id="p3">
                          <bibl>
                                                        <editor>Sperberg-McQueen, C.M.</editor>; <editor>Burnard, L.</editor> (eds.). <title>Guidelines for Electronic Text Encoding and Interchange. TEI P3. Revised reprint.</title>
                            <publisher>Text Encoding Initiative</publisher>: <pubPlace>Oxford</pubPlace>, <pubPlace>Providence</pubPlace>, <pubPlace>Charlottesville</pubPlace>, <pubPlace>Bergen</pubPlace>, <date when="1999">1999</date>
                                                    </bibl>
                        </witness>
                      </listWit>
                      <listWit xml:id="teiXML">
                        <head>TEI Guidelines covering XML</head>
                        <witness xml:id="p4">
                          <bibl>
                                                        <editor>Sperberg-McQueen, C.M.</editor>; <editor>Burnard, L.</editor> (eds.). <title>TEI P4: Guidelines for Electronic Text Encoding and Interchange. XML-compatible edition.</title>
                            <publisher>Text Encoding Initiative Consortium</publisher>: <pubPlace>Oxford</pubPlace>, <pubPlace>Providence</pubPlace>, <pubPlace>Charlottesville</pubPlace>, <pubPlace>Bergen</pubPlace>, <date when="2002">2002</date>
                                                    </bibl>
                        </witness>
                        <witness xml:id="p5">
                          <bibl>
                                                        <editor>Sperberg-McQueen, C.M.</editor>; <editor>Burnard, L.</editor> (eds.). <title>TEI P5: Guidelines for Electronic Text Encoding and Interchange. Revised and re-edited.</title>
                            <publisher>Text Encoding Initiative Consortium</publisher>: <pubPlace>Oxford</pubPlace>, <pubPlace>Providence</pubPlace>, <pubPlace>Charlottesville</pubPlace>, <pubPlace>Nancy</pubPlace>, <date when="2005">2005</date>
                                                    </bibl>
                        </witness>
                      </listWit>
                    </listWit>
                  </sourceDesc>
                </fileDesc>
                <!-- ... -->
              </teiHeader>
              <!-- ... -->
            </TEI>
          </egXML>
          <head type="legend">Grouping descriptions of related text witnesses in <gi>listWit</gi>.</head>
        </figure>
        <note type="summary">The different text witnesses included in a critical edition should be documented in a <gi>listWit</gi> element. Such a list may occur in the <gi>sourceDesc</gi> section of the TEI header (for digital editions created or generated from scratch), or in the <gi>text</gi> of the edition, usually in the <gi>front</gi> section (for digital editions digitised from an existing edition). Each text witness should be described in a <gi>witness</gi> element, containing either a prose description as plain text, possibly enriched with specific TEI elements for bibliographic description (<gi>bibl</gi>, <gi>biblStruct</gi>, <gi>biblFull</gi>). An <att>xml:id</att> attribute must be provided for each witness, which is used as the sigil for this witness in the edition. Witness groups can be distinguished in separate nested <gi>listWit</gi> elements.</note>
      </div>
            <div xml:id="apparatus">
        <head>Encoding Textual Variants</head>
        <div xml:id="basicApp">
          <head>Basic Organisation of an Apparatus Entry</head>
          <p>Traditionally, printed critical editions have developed efficient mechanisms to represent textual variants on as little physical space as possible in what is commonly called a <term>critical apparatus</term>. Many types of apparatus exist, depending on the editorial theory, but all tend to put the different readings found in the different text witnesses on a par with one version of the text, which is commonly called the <term>base text</term>. The TEI Guidelines offer an analogous mechanism for representing textual variants in a concise way. A piece of text with corresponding variants in the different text witnesses, is encoded in an <gi>app</gi> (apparatus entry) element, which holds all different readings. Each reading must be encoded in a <gi>rdg</gi> (reading) element, which can be associated to its respective text witness by means of the <att>wit</att> attribute. Its value should point to the definition of the text witness in a <gi>listWit</gi> element elsewhere in the edition (see <ptr target="#listWit" type="crossref"/>). For example, let’s have a closer look at the chapter title in our sample:
            <table rend="border" xml:id="table3">
              <row>
                <cell role="label">
                                    <ident>[witness p2]</ident>
                                </cell>
                <cell>
                  <hi rend="highlight">Chapter 2</hi>
                                    <lb/> 
                  A <hi rend="highlight">GENTLE INTRODUCTION TO SGML</hi>
                </cell>
              </row>
              <row>
                <cell role="label">
                                    <ident>[witness p3]</ident>
                                </cell>
                <cell>
                  <hi rend="highlight">Chapter 2</hi>
                                    <lb/> 
                  A <hi rend="highlight">Gentle Introduction to SGML</hi>
                </cell>
              </row>
              <row>
                <cell role="label">
                                    <ident>[witness p4]</ident>
                                </cell>
                <cell>
                  <hi rend="highlight">2</hi> A <hi rend="highlight">Gentle Introduction to XML</hi>
                </cell>
              </row>
              <row>
                <cell role="label">
                                    <ident>[witness p5]</ident>
                                </cell>
                <cell>
                  <hi rend="highlight">v</hi>
                                    <lb/>
                  A <hi rend="highlight">Gentle Introduction to XML</hi>
                </cell>
              </row>
            </table>
          </p>
          <p>In above example, all text that differs from the corresponding fragment in any other witness is highlighted in yellow. Only the word <q>A</q> is shared between all text witnesses. In a digital edition of our sample, these stretches of variant text could be encoded in two apparatus entries:</p>
          <figure xml:id="example7">
            <egXML xmlns="http://www.tei-c.org/ns/Examples">
              <app>
                <rdg wit="#p2">Chapter 2 <lb/>
                                </rdg>
                <rdg wit="#p3">Chapter 2 <lb/>
                                </rdg>
                <rdg wit="#p4">2</rdg>
                <rdg wit="#p5">v <lb/>
                                </rdg>
              </app>
              <app>
                <rdg wit="#p2">GENTLE INTRODUCTION TO SGML</rdg>
                <rdg wit="#p3">Gentle Introduction to SGML</rdg>
                <rdg wit="#p4">Gentle Introduction to XML</rdg>
                <rdg wit="#p5">Gentle Introduction to XML</rdg>
              </app>
            </egXML>
            <head type="legend">Apparatus entries without preferred readings, encoded in <gi>rdg</gi>.</head>
          </figure>
          <p>In this example, both textual variants are encoded as two apparatus entries, with four readings each. Each <gi>rdg</gi> element points to the definition of its corresponding text witness by means of the <term>sigla</term> in its <att>wit</att> attribute. Notice how each sigil starts with a <code>#</code> sign, because it addresses the <att>xml:id</att> value of a <gi>witness</gi> element in the edition.<note>Notice, how the TEI Guidelines offer the <emph>means</emph> to encode textual variation, without imposing any theoretical assumptions on <emph>how</emph> to encode an apparatus for the variants in different texts. The treatment of variation in different text versions is an explicit theoretical act of interpretation, and it is up to the encoder to determine corresponding text fragments, and where to delimit stretches of variation. Likewise, the examples in this TBE tutorial module are fairly theory-neutral, in that they tend to use the maximal length of differing text fragments as guiding principle for the demarcation of textual variants.</note>
                    </p>
          <p>In printed critical editions, the assumption of a base text against which all other versions are compared is quite common. Therefore, besides readings, a TEI apparatus entry can also contain a <gi>lem</gi> (lemma) element, identifying the reading it contains as a <soCalled>preferred</soCalled> reading, according to the editor’s theory of the text. Notice that if a <gi>lem</gi> element is used, it must occur as the first element inside <gi>app</gi>. If version <ident>p2</ident> were considered the base text to the edition of this sample, the previous example could be encoded as follows:<note>Because in the context of electronic critical editing a <soCalled>preferred</soCalled> reading in a <gi>lem</gi> element is fairly theory-dependent, the examples in this TBE tutorial module will mostly just list all variants as equal <gi>rdg</gi> elements. You have to know, however, that each <gi>app</gi> element may always specify one of its readings as lemma (<gi>lem</gi>) as well.</note>
            <figure xml:id="example8">
              <egXML xmlns="http://www.tei-c.org/ns/Examples">
                <app>
                  <lem wit="#p2">Chapter 2 <lb/>
                                    </lem>
                  <rdg wit="#p3">Chapter 2 <lb/>
                                    </rdg>
                  <rdg wit="#p4">2</rdg>
                  <rdg wit="#p5">v <lb/>
                                    </rdg>
                </app>
                <app>
                  <lem wit="#p2">GENTLE INTRODUCTION TO SGML</lem>
                  <rdg wit="#p3">Gentle Introduction to SGML</rdg>
                  <rdg wit="#p4">Gentle Introduction to XML</rdg>
                  <rdg wit="#p5">Gentle Introduction to XML</rdg>
                </app>
              </egXML>
              <head type="legend">Apparatus entries with a preferred reading in <gi>lem</gi>.</head>
            </figure>
          </p>
          <p>In order to make this representation more efficient, identical readings can be collapsed into one single <gi>rdg</gi> element, by combining the sigla into a list separated by white spaces in the <att>wit</att> attribute:
            <figure xml:id="example9">
              <egXML xmlns="http://www.tei-c.org/ns/Examples">
                <app>
                  <rdg wit="#p2 #p3">Chapter 2 <lb/>
                                    </rdg>
                  <rdg wit="#p4">2</rdg>
                  <rdg wit="#p5">v <lb/>
                                    </rdg>
                </app>
                <app>
                  <rdg wit="#p2">GENTLE INTRODUCTION TO SGML</rdg>
                  <rdg wit="#p3">Gentle Introduction to SGML</rdg>
                  <rdg wit="#p4 #p5">Gentle Introduction to XML</rdg>
                </app>
              </egXML>
              <head type="legend">Grouping identical readings in a  single <gi>rdg</gi> element.</head>
            </figure>
          </p>
          <p>Remember how we distinguished different witness groups in the previous section of this tutorial? This allows us to rewrite the sigla of readings shared by the versions of the TEI Guidelines dealing with either SGML or XML, using the group identification code for the corresponding group of witnesses:
            <figure xml:id="example10">
              <egXML xmlns="http://www.tei-c.org/ns/Examples">
                <app>
                  <rdg wit="#teiSGML">Chapter 2 <lb/>
                                    </rdg>
                  <rdg wit="#p4">2</rdg>
                  <rdg wit="#p5">v <lb/>
                                    </rdg>
                </app>
                <app>
                  <rdg wit="#p2">GENTLE INTRODUCTION TO SGML</rdg>
                  <rdg wit="#p3">Gentle Introduction to SGML</rdg>
                  <rdg wit="#teiXML">Gentle Introduction to XML</rdg>
                </app>
              </egXML>
              <head type="legend">Referring to witness groups in <gi>rdg</gi>.</head>
            </figure>
          </p>
          <p>You should consider an <gi>app</gi> element as a cross-section of a text fragment over all of the different text witnesses. This means that all <gi>lem</gi> and <gi>rdg</gi> contents should be interpreted as mutually exclusive alternatives. Therefore, each text witness listed in the <att>wit</att> attributes inside an <gi>app</gi> element should occur only once. Ideally, this should be the minimal requirement as well, so that each apparatus entry contains one corresponding text fragment across all different text witnesses included in the edition (although this is not strictly necessary when the edition uses one base text: see <ptr target="#appConnect" type="crossref"/>).</p>
          <note type="summary">Each variant in a TEI encoded critical edition should be encoded as an apparatus entry, in an <gi>app</gi> element. An apparatus entry contains the different textual variants found in the text witnesses, encoded in different <gi>rdg</gi> (reading) elements. If the edition considers one of the text witnesses as the <term>base</term> text, the readings from that witness can be encoded as a lemma instead, in a <gi>lem</gi> element. Each <gi>lem</gi> or <gi>rdg</gi> element should indicate the text witness(es) it corresponds to in a <att>wit</att> attribute. The value of this attribute consists of a white space separated list of pointers to the <att>xml:id</att> code(s) of the <gi>witness</gi> element(s) describing the corresponding text witness(es).</note>
        </div>
        <div xml:id="appGrouping">
          <head>Grouping Readings</head>
          <p>In both variants considered so far, arguments could be made for (re)grouping the readings. In the first apparatus entry, reading <ident>p5</ident> is set apart from all others because of the diverging chapter number. In the second apparatus entry, one possible case for explicit grouping could be the <soCalled>genetic</soCalled> similarity of the variants in those versions of the TEI Guidelines dealing with SGML or XML.</p>
          <p>One way of grouping readings is provided by a <gi>rdgGrp</gi> element. It can be wrapped around <gi>rdg</gi> elements in an apparatus entry, in order to indicate their relatedness in some way. This <gi>rdgGrp</gi> really is nothing more than a wrapper for grouping related readings. For example, the readings in the previous example could be grouped as follows:
            <figure xml:id="example11">
              <egXML xmlns="http://www.tei-c.org/ns/Examples">
                <app>
                  <rdg wit="#teiSGML">Chapter 2 <lb/>
                                    </rdg>
                  <rdgGrp>
                    <rdg wit="#p4">2</rdg>
                    <rdg wit="#p5">v <lb/>
                                        </rdg>
                  </rdgGrp>
                </app>
                <app>
                  <rdgGrp>
                    <rdg wit="#p2">GENTLE INTRODUCTION TO SGML</rdg>
                    <rdg wit="#p3">Gentle Introduction to SGML</rdg>
                  </rdgGrp>
                  <rdg wit="#teiXML">Gentle Introduction to XML</rdg>
                </app>
              </egXML>
              <head type="legend">Grouping related readings in <gi>rdgGrp</gi>.</head>
            </figure>
            </p>
          <p>When you take a closer look at these variants, you’ll see that some of these readings contain common text as well. In the first variant, the number <q>2</q> is shared between both <ident>teiSGML</ident> readings, and the <ident>p4</ident> reading. In the last variant, the <ident>p2</ident> and <ident>p3</ident> readings are set apart by the common phrase <q>SGML</q>, as opposed to <q>XML</q> in the <ident>teiXML</ident> readings. Yet, both <ident>p2</ident> and <ident>p3</ident> text witnesses vary internally in their use of capitals. Such refinements can’t be expressed using the <gi>rdgGrp</gi> grouping mechanism, as a <gi>rdgGrp</gi> element can only contain <gi>rdg</gi> or <gi>lem</gi> elements. If this grouping is to be maintained, you could express them in a more fine-grained manner using another grouping mechanism: introducing nesting <gi>app</gi> elements in the <gi>rdg</gi> elements that share common text as well as variant readings:
            <figure xml:id="example12">
              <egXML xmlns="http://www.tei-c.org/ns/Examples">
                <app>
                  <rdg wit="#teiSGML #p4">
                    <app>
                      <rdg wit="#teiSGML">Chapter</rdg>
                      <rdg wit="#p4"/>
                    </app> 2 <app>
                      <rdg wit="#teiSGML">
                                                <lb/>
                                            </rdg>
                      <rdg wit="#p4"/>
                    </app>
                  </rdg>
                  <rdg wit="#p5">v <lb/>
                  </rdg>
                </app>
                <app>
                  <rdg wit="#teiSGML">
                    <app>
                      <rdg wit="#p2">GENTLE INTRODUCTION TO</rdg>
                      <rdg wit="#p3">Gentle Introduction to</rdg>
                    </app> SGML</rdg>
                  <rdg wit="#teiXML">Gentle Introduction to XML</rdg>
                </app>
              </egXML>
              <head type="legend">Grouping readings in nesting <gi>app</gi> elements.</head>
            </figure>
          </p>
          <p>In the first variant, the apparatus distinguishes between those readings whose heading refers to the second chapter (<ident>teiSGML</ident> and <ident>p4</ident>), and reading <ident>p5</ident>, which refers to chapter five. However, as the first group of readings shows internal variation, this can be expressed in further nesting <gi>app</gi> elements (see the nesting <gi>app</gi> elements for the <q>Chapter</q> sub-variant, and the line break). The common text can be encoded as plain text contents of the grouping <gi>rdg</gi> element (see the <q>2</q>, which occurs in all readings of the group: <ident>teiSGML</ident>, and <ident>p4</ident>). In the second variant, the readings corresponding to the text witnesses dealing with SGML are set apart from those dealing with XML. Since the first group of readings contains internal variation, the variant text (<q>Gentle Introduction to</q>) is wrapped in a nesting <gi>app</gi> element, while the common text (<q>SGML</q>) appears as plain text inside the grouping <gi>rdg</gi> element.</p>
          <note type="summary">When so desired, related readings can be grouped using one of two mechanisms. The first one wraps a dedicated <gi>rdgGrp</gi> element around related readings. This element can only contain <gi>lem</gi> and <gi>rdg</gi> elements. A more sophisticated way of grouping readings is provided by using nesting <gi>app</gi> structures inside a <gi>rdg</gi> element.</note>
        </div>
        <div xml:id="appType">
          <head>Classification</head>
          <p>So far, the most elaborate encoding of the chapter’s title in the different text witnesses looks as follows:
            <figure xml:id="example13">
              <egXML xmlns="http://www.tei-c.org/ns/Examples">
                <app>
                  <rdg wit="#teiSGML #p4">
                    <app>
                      <rdg wit="#teiSGML">Chapter</rdg>
                      <rdg wit="#p4"/>
                    </app> 2 <app>
                      <rdg wit="#teiSGML">
                                                <lb/>
                                            </rdg>
                      <rdg wit="#p4"/>
                    </app>
                  </rdg>
                  <rdg wit="#p5">v <lb/>
                  </rdg>
                </app>
                <app>
                  <rdg wit="#teiSGML">
                    <app>
                      <rdg wit="#p2">GENTLE INTRODUCTION TO</rdg>
                      <rdg wit="#p3">Gentle Introduction to</rdg>
                    </app> SGML</rdg>
                  <rdg wit="#teiXML">Gentle Introduction to XML</rdg>
                </app>
              </egXML>
              <head type="legend">Heterogenous grouping of readings.</head>
            </figure>
          </p>
          <p>Admittedly, this organisation is not the most intuitive one, mostly because it mixes different perspectives: 
            <list rend="bulleted">
              <item>a content-oriented one in the first apparatus entry, grouping those variants with a common reading (i.e., the chapter number referred to)</item>
              <item>a genetic-oriented one in the second apparatus entry, grouping the readings according to the groups of witnesses (i.e., those occurring in the versions of the TEI Guidelines dealing with SGML or XML)</item>
            </list>
          </p>
          <p>However, this is not necessarily the most interesting perspective, for it obscures some obvious correspondences. For example, there is no way of deducting the correspondence between the <gi>lb</gi> reading occurring in three of the four witnesses, as it is <soCalled>buried</soCalled> in two different reading groups. There is no reason, however, not to reorganise these apparatus entries in more atomic units:
          <figure xml:id="example14">
            <egXML xmlns="http://www.tei-c.org/ns/Examples">
              <app>
                <rdg wit="#p2 #p3">Chapter</rdg>
                <rdg wit="#p4 #p5"/>
              </app>
              <app>
                <rdg wit="#p2 #p3 #p4">2</rdg>
                <rdg wit="#p5">v</rdg>
              </app>
              <app>
                <rdg wit="#p2 #p3 #p5">
                  <lb/>
                </rdg>
                <rdg wit="#p4"/>
              </app>
              <app>
                <rdg wit="#p2">GENTLE INTRODUCTION TO</rdg>
                <rdg wit="#p3 #p4 #p5">Gentle Introduction to</rdg>
              </app>
              <app>
                <rdg wit="#p2 #p3">SGML</rdg>
                <rdg wit="#p4 #p5">XML</rdg>
              </app>
            </egXML>
            <head type="legend">Atomic encoding of minimal stretches of variation.</head>
          </figure>
          </p>
          <p>One could argue that on closer examination, not all of these variants have the same <soCalled>status</soCalled>: some are more substantive than others. This may be pointed out at the level of the individual readings, by means of a <att>type</att> attribute. In this way, we could for example distinguish between <val>orthographic</val> readings (differing only in their spelling or presentation) and <val>substantive</val> readings (differing in meaning):
            <figure xml:id="example15">
              <egXML xmlns="http://www.tei-c.org/ns/Examples">
                <app>
                  <rdg wit="#p2 #p3" type="substantive">Chapter</rdg>
                  <rdg wit="#p4 #p5" type="substantive"/>
                </app>
                <app>
                  <rdg wit="#p2 #p3 #p4" type="substantive">2</rdg>
                  <rdg wit="#p5" type="substantive">v</rdg>
                </app>
                <app>
                  <rdg wit="#p2 #p3 #p5" type="orthographic">
                    <lb/>
                  </rdg>
                  <rdg wit="#p4" type="orthographic"/>
                </app>
                <app>
                  <rdg wit="#p2" type="orthographic">GENTLE INTRODUCTION TO</rdg>
                  <rdg wit="#p3 #p4 #p5" type="substantive">Gentle Introduction
                    to</rdg>
                </app>
                <app>
                  <rdg wit="#p2 #p3" type="substantive">SGML</rdg>
                  <rdg wit="#p4 #p5" type="substantive">XML</rdg>
                </app>
              </egXML>
              <head type="legend">Categorising individual readings with <att>type</att> on <gi>rdg</gi>.</head>
            </figure>
          </p>
          <p>With this distinction in place, the type of reading could be adopted as guiding principle to derive larger stretches of variation: only when two subsequent variants only have orthographically different readings, they can be merged to one apparatus entry. Notice also, how in this case all readings for the different apparatus entries share the same type. This can be encoded at the higher level of the apparatus entry as well, simply by providing a <att>type</att> attribute for the <gi>app</gi> element:
            <figure xml:id="example16">
              <egXML xmlns="http://www.tei-c.org/ns/Examples">
                <app type="substantive">
                  <rdg wit="#p2 #p3 #p4">
                    <app>
                      <rdg wit="#p2 #p3">Chapter</rdg>
                      <rdg wit="#p4"/>
                    </app> 2 </rdg>
                  <rdg wit="#p5">v</rdg>
                </app>
                <app type="orthographic">
                  <rdg wit="#p2 #p3 #p5">
                    <lb/>
                  </rdg>
                  <rdg wit="#p4"/>
                </app>
                <app type="orthographic">
                  <rdg wit="#p2">GENTLE INTRODUCTION TO</rdg>
                  <rdg wit="#p3 #p4 #p5">Gentle Introduction to</rdg>
                </app>
                <app type="substantive">
                  <rdg wit="#p2 #p3">SGML</rdg>
                  <rdg wit="#p4 #p5">XML</rdg>
                </app>
              </egXML>
              <head type="legend">Categorising variants with <att>type</att> on <gi>app</gi>.</head>
            </figure>
          </p>
          <p>The <gi>rdgGrp</gi>, too, can have a <att>type</att> attribute for specifying the nature of the group of readings it holds. For example, we could revisit the earlier grouping example using <gi>rdgGrp</gi>:
            <figure xml:id="example17">
              <egXML xmlns="http://www.tei-c.org/ns/Examples">
                <app>
                  <rdg type="substantive">Chapter 2 <lb/>
                                    </rdg>
                  <rdgGrp type="substantive">
                    <rdg wit="#p4">2</rdg>
                    <rdg wit="#p5">v <lb/>
                    </rdg>
                  </rdgGrp>
                </app>
                <app>
                  <rdgGrp type="orthographic">
                    <rdg wit="#p2">GENTLE INTRODUCTION TO SGML</rdg>
                    <rdg wit="#p3">Gentle Introduction to SGML</rdg>
                  </rdgGrp>
                  <rdg wit="#teiXML" type="substantive">Gentle Introduction to
                    XML</rdg>
                </app>
              </egXML>
              <head type="legend">Categorising variants with <att>type</att> on <gi>rdgGrp</gi>.</head>
            </figure>
          </p>
          <note type="summary">The readings inside <gi>rdg</gi> and <gi>lem</gi> can be categorised with a <att>type</att> attribute, in order to indicate what type of variant they contain. When readings are grouped using <gi>rdgGrp</gi>, the <att>type</att> attribute equally can indicate what type of variants the reading group consists of. When an apparatus entry only contains variants of the same type, this may be expressed by the <att>type</att> attribute at the <gi>app</gi> level.</note>
        </div>
        <div xml:id="rdgDetails">
          <head>Reading Details</head>
          <p>Besides witness (<att>wit</att>) and type information (<att>type</att>), readings and lemmas can provide more information about the readings they hold, in dedicated attributes. One type of information that is particularly useful for critical editions of manuscript source materials, is the identification of a document hand that is responsible for a certain reading, especially when its text witness has been written by different hands. This can be expressed in a <att>hand</att> attribute, which points to the definition of that hand in the TEI header (see <ptr type="crossref" target="TBED02v00.htm#handNotes"/>). This could be applied to our example texts: although the TEI Guidelines are not manuscripts, they are written collaboratively by a team of editors who could be considered document hands. Suppose that we could determine who was responsible for what change in the different versions included in our example critical edition, this could be encoded as follows:
            <figure xml:id="example18">
              <egXML xmlns="http://www.tei-c.org/ns/Examples">
                <teiHeader>
                  <!-- ... -->
                  <profileDesc>
                    <handNotes>
                      <handNote xml:id="MSMQ">Michael Sperberg-McQueen</handNote>
                      <handNote xml:id="LB">Lou Burnard</handNote>
                      <handNote xml:id="SB">Syd Bauman</handNote>
                      <handNote xml:id="SR">Sebastian Rahtz</handNote>
                    </handNotes>
                  </profileDesc>
                  <!-- ... -->
                </teiHeader>
                <!-- ... -->
                <app>
                  <rdg wit="#p2" hand="#MSMQ">Chapter 2 <lb/>
                                    </rdg>
                  <rdg wit="#p3">Chapter 2 <lb/>
                                    </rdg>
                  <rdg wit="#p4" hand="#SB">2</rdg>
                  <rdg wit="#p5" hand="#SR">v <lb/>
                                    </rdg>
                </app>
                <app>
                  <rdg wit="#p2" hand="#LB">GENTLE INTRODUCTION TO SGML</rdg>
                  <rdg wit="#p3">Gentle Introduction to SGML</rdg>
                  <rdg wit="#p4" hand="#SB">Gentle Introduction to XML</rdg>
                  <rdg wit="#p5">Gentle Introduction to XML</rdg>
                </app>
              </egXML>
              <head type="legend">Providing information on hands for individual readings.</head>
            </figure>
          </p>
          <p>Of course this attribution is subject to a greater or lesser deal of interpretation (especially in this contrived example). Therefore, it makes sense to indicate who is responsible for this interpretation. This can be expressed in a <att>resp</att> attribute, which can point to an individual responsible for some aspects of the digital edition, as identified in the TEI header (see <ptr type="crossref" target="TBED02v00.htm#titleStmt"/>). As always, the <att>resp</att> attribute applies to all aspects of the element it is attached to, and can equally be used to indicate the responsibility for an unsure transcription of a reading. As the hand attribution in the previous example can be considered quite putative, it makes sense to provide responsibility information as well:
            <figure xml:id="example19">
              <egXML xmlns="http://www.tei-c.org/ns/Examples">
                <teiHeader>
                  <fileDesc>
                    <titleStmt>
                      <title>The TEI Guidelines, an electronic critical
                        edition</title>
                      <editor xml:id="TBEcrew">The TBE crew</editor>
                      <!-- ... -->
                    </titleStmt>
                    <!-- ... -->
                  </fileDesc>
                  <!-- ... -->
                  <profileDesc>
                    <handNotes>
                      <handNote xml:id="MSMQ">Michael Sperberg-McQueen</handNote>
                      <handNote xml:id="LB">Lou Burnard</handNote>
                      <handNote xml:id="SB">Syd Bauman</handNote>
                      <handNote xml:id="SR">Sebastian Rahtz</handNote>
                    </handNotes>
                  </profileDesc>
                  <!-- ... -->
                </teiHeader>
                <!-- ... -->
                <app>
                  <rdg wit="#p2" hand="#MSMQ" resp="#TBEcrew">Chapter 2 <lb/>
                                    </rdg>
                  <rdg wit="#p3">Chapter 2 <lb/>
                                    </rdg>
                  <rdg wit="#p4" hand="#SB" resp="#TBEcrew">2</rdg>
                  <rdg wit="#p5" hand="#SR" resp="#TBEcrew">v <lb/>
                                    </rdg>
                </app>
                <app>
                  <rdg wit="#p2" hand="#LB" resp="#TBEcrew">GENTLE INTRODUCTION TO
                    SGML</rdg>
                  <rdg wit="#p3">Gentle Introduction to SGML</rdg>
                  <rdg wit="#p4" hand="#SB" resp="#TBEcrew">Gentle Introduction to
                    XML</rdg>
                  <rdg wit="#p5">Gentle Introduction to XML</rdg>
                </app>
              </egXML>
              <head type="legend">Stating responsibility for interpretations.</head>
            </figure>
          </p>
          <p>Using attributes on <gi>rdg</gi> holds the danger of overgeneralisation, as in following example:
            <figure xml:id="example20">
              <egXML xmlns="http://www.tei-c.org/ns/Examples" valid="false">
                <app>
                  <seg rend="incorrect">
                    <rdg wit="#p2 #p3" hand="#MSMQ" resp="#TBEcrew">Chapter 2 <lb/>
                                        </rdg>
                  </seg>
                  <rdg wit="#p4" hand="#SB" resp="#TBEcrew">2</rdg>
                  <rdg wit="#p5" hand="#SR" resp="#TBEcrew">v <lb/>
                                    </rdg>
                </app>
                <app>
                  <rdg wit="#p2" hand="#LB" resp="#TBEcrew">GENTLE INTRODUCTION TO SGML</rdg>
                  <rdg wit="#p3">Gentle Introduction to SGML</rdg>
                  <seg rend="incorrect">
                    <rdg wit="#teiXML" hand="#SB" resp="#TBEcrew">Gentle Introduction to XML</rdg>
                  </seg>
                </app>
              </egXML>
              <head type="legend">Imprecise attribution of reading details on <soCalled>collapsed</soCalled> <gi>rdg</gi> elements.</head>
            </figure>
          </p>
          <p>This example is incorrect because the first reading of the first apparatus entry overgeneralises the hand information for the <ident>p3</ident> witness, and the last reading of the last entry incorrectly attributes the hand information for the <ident>p5</ident> witness. It <emph>can</emph> be done, however, using a dedicated <gi>witDetail</gi> element, which is intended to provide more information about a specific reading in an apparatus entry. It must have a <att>wit</att> attribute, identifying the specific text witness it provides more information for. In order to anchor it to a specific <gi>rdg</gi> element, a <att>target</att> attribute can be used to point to the <att>xml:id</att> of the concerned <gi>rdg</gi> element. This implies that the reading concerned must be formally identified with an <att>xml:id</att> attribute. For example, the previous example could be corrected as:
            <figure xml:id="example21">
              <egXML xmlns="http://www.tei-c.org/ns/Examples">
                <app>
                  <rdg wit="#p2 #p3" xml:id="rdg1.1">Chapter 2 <lb/>
                                    </rdg>
                  <witDetail target="#rdg1.1" wit="#p2" resp="#TBEcrew">attributed to <ref target="#MSMQ">Michael Sperberg-McQueen</ref>
                                    </witDetail>
                  <rdg wit="#p4" hand="#SB" resp="#TBEcrew">2</rdg>
                  <rdg wit="#p5" resp="#TBEcrew">v <lb/>
                                    </rdg>
                </app>
                <app>
                  <rdg wit="#p2" hand="#LB" resp="#TBEcrew">GENTLE INTRODUCTION TO SGML</rdg>
                  <rdg wit="#p3">Gentle Introduction to SGML</rdg>
                  <rdg wit="#teiXML" xml:id="rdg2.3">Gentle Introduction to XML</rdg>
                  <witDetail target="#rdg2.3" wit="#p4" resp="#TBEcrew">attributed to <ref target="#SB">Syd Bauman</ref>
                                    </witDetail>
                </app>
              </egXML>
              <head type="legend">Providing more information about specific readings with <gi>witDetail</gi>.</head>
            </figure>
          </p>
          <p>The <gi>witDetail</gi> element is a specialised type of <gi>note</gi>, which means it can occur at many places in the document: either inline at the place of the reading needing further specification, or grouped together elsewhere in the document. The TEI Guidelines recommend to place this element inside <gi>app</gi>, immediately after the <gi>lem</gi> or <gi>rdg</gi> element it provides more information for.</p>
          <note type="summary">Lemma (<gi>lem</gi>) and readings (<gi>rdg</gi>) can be further qualified by means of attributes. The <att>resp</att> attribute can be used to identify the person responsible for the encoding of the reading, while the document hand responsible for that particular reading can be referred to in a <att>hand</att> attribute. When more detailed information is to be given for a particular reading in a particular text witness, this can be done in a <gi>witDetail</gi> element, whose <att>wit</att> attribute must point to the concerned text witness, and whose <att>target</att> attribute can be used to point to the identification code of the affected reading(s).</note>
        </div>
      </div>
            <div xml:id="appConnect">
        <head>Encoding Variation in Texts</head>
        <p>After this discussion of the encoding of textual variation itself, it is time to have a look at the bigger picture: how do you integrate these variants into an electronic critical edition? The TEI Guidelines provide 3 different mechanisms for integrating apparatus entries in the encoding of texts (don’t let the names intimidate you):
          <list type="gloss">
            <label>location-referenced method</label>
            <item>apparatus entries are linked to the identified text blocks in a base text that contain the respective lemmas [I, E]</item>
            <label>double end-point attachment method</label>
            <item>apparatus entries are linked to explicitly identified start and end positions in a base text [I, E]</item>
            <label>parallel segmentation method</label> 
            <item>apparatus entries are encoded inside a transcription of the common (invariant) text of all text witnesses [I]</item>
          </list>
        </p>
        <p>In this overview, the [I] and [E] labels indicate where an apparatus encoded with that method can be physically located with regards to the transcription of the (base) text it is linked to: 
          <list type="gloss">
            <label>[E]: external apparatus</label>
            <item>the apparatus is located outside the transcription of a base text, either in some other part of the TEI document containing the transcription, or in a physically distinct document <lb/>→ location-referenced, double end-point attachment</item>
            <label>[I]: internal apparatus</label>
            <item>each apparatus entry is located inline in the transcription of a (base) text, at the place where the variant occurs <lb/>→ location-referenced, double end-point attachment, parallel segmentation</item>
          </list>
        </p>
        <p>The method chosen and the physical location of the apparatus must be encoded in the TEI Header, in the <gi>variantEncoding</gi> element inside the <gi>encodingDesc</gi> section. This is an empty element with two mandatory attributes (see <ptr type="crossref" target="TBED02v00.htm#variantEncoding"/>): 
          <list rend="bulleted">
            <item>
                            <att>method</att>: indicates the method of linking the critical apparatus to the text: either <val>location-referenced</val>, <val>double-end-point</val>, or <val>parallel-segmentation</val>.</item>
            <item>
                            <att>location</att>: indicates the location of the critical apparatus with regards to the text: either <val>external</val> or <val>internal</val>.</item>
          </list>
        </p>
        <note type="summary">The TEI Guidelines offer 3 methods for linking the critical apparatus to the text. The method chosen must be documented in the <gi>encodingDesc</gi> section of the TEI header, in a special <gi>variantEncoding</gi> element. This is an empty element with 2 mandatory attributes. The <att>method</att> attribute specifies the method of linking the apparatus to the text (either <val>location-referenced</val>, <val>double-end-point</val>, or <val>parallel-segmentation</val>). The <att>location</att> attribute specifies the location of the apparatus relative to the text (either <val>external</val> or <val>internal</val>).</note>
        <div xml:id="locRef">
          <head>The Location-Referenced Method</head>
          <p>The location-referenced method links an apparatus entry to a base text, by anchoring it to the text structure in the base text where the variant occurs. This can be done either internally (inside the running text), or externally (outside the running text).</p>
          <p>In an internal location-referenced apparatus, the apparatus entries are encoded within the text structures in which the variants occur. The exact location, however, is unimportant. For example, the second paragraph could be encoded as follows:
            <figure xml:id="example22">
              <egXML xmlns="http://www.tei-c.org/ns/Examples">
                <TEI>
                  <teiHeader>
                    <!-- ... -->
                    <encodingDesc>
                      <variantEncoding method="location-referenced" location="internal"/>
                    </encodingDesc>
                    <!-- ... -->
                  </teiHeader>
                  <text>
                    <body>
                      <!-- ... -->
                      <p>The encoding scheme defined by these Guidelines is<app>
                                                    <rdg wit="#p3">is</rdg>
                                                    <rdg wit="#p4">may be</rdg>
                                                </app> formulated<app>
                                                    <rdg wit="#p2 #p3"/>
                                                    <rdg wit="#p4">either</rdg>
                                                </app> as an application of the Extensible<app>
                                                    <rdg wit="#p2 #p3">a system known as the Standard Generalized</rdg>
                                                    <rdg wit="#p4">the ISO Standard Generalized</rdg>
                                                </app> Markup Language (XML) (Bray et al. (eds.) (2006)). XML is widely used<app>
                                                    <rdg wit="#p2">(SGML).<note place="foot">
                                                            <bibl>
                                                                <editor>International Organization for Standardization</editor>, <title>ISO 8879: Information processing--Text and office systems--Standard Generalized Mark-up Language (SGML)</title>, ([<pubPlace>Geneva</pubPlace>]: <publisher>ISO</publisher>, <date>1986</date>).</bibl> Although widely said to be short for the surnames of its progenitors, the official expansion of this abbreviation is "Standard Generalized Markup Language."</note> SGML is an international standard</rdg>
                                                    <rdg wit="#p3">(SGML). <note place="foot">
                                                            <bibl>
                                                                <editor>International Organization for Standardization</editor>, <title>ISO 8879: Information processing - Text and office systems - Standard Generalized Markup Language (SGML)</title>, ([<pubPlace>Geneva</pubPlace>]: <publisher>ISO</publisher>, <date>1986</date>)</bibl>
                                                        </note> SGML is an international standard</rdg>
                                                    <rdg wit="#p4">(SGML)<note place="foot">
                                                            <bibl>
                                                                <editor>International Organization for Standardization</editor>, <title>ISO 8879: Information processing - Text and office systems - Standard Generalized Markup Language (SGML)</title>, ([<pubPlace>Geneva</pubPlace>]: <publisher>ISO</publisher>, <date>1986</date>)</bibl>
                                                        </note>or of the more recently developed W3C Extensible Markup Language (XML)<note place="foot">
                                                            <bibl>
                                                                <editor>World Wide Web Consortium</editor> : <title>Extensible Markup Language (XML) 1.0</title>, available from <ref target="http://www.w3.org/TR/REC-xml">http://www.w3.org/TR/REC-xml</ref>
                                                            </bibl>
                                                        </note>. Both SGML and XML are widely-used</rdg>
                                                </app> for the definition of device-independent, system-independent methods of storing and processing<app>
                                                    <rdg wit="#p4">storing and processing</rdg>
                                                    <rdg wit="#p2 #p3">representing</rdg>
                                                </app> texts in electronic form. It is now also the interchange and communication format used by many applications on the World Wide Web. In<app>
                                                    <rdg wit="#p2 #p3">. This chapter presents a brief tutorial guide to its main features, for those readers who have not encountered it before. For a more technical account of TEI practice in using</rdg>
                                                    <rdg wit="#p4">; XML being in fact a simplification or derivation of SGML. In the present chapter we introduce informally the basic concepts underlying such markup languages and attempt to explain to</rdg>
                                                </app> the present chapter we informally introduce some of its basic concepts and attempt to explain to the reader encountering them for the first time how and why they are<app>
                                                    <rdg wit="#p2">SGML standard, see chapter 30, "TEI Conformance," [in separate fascicle]; for a more technical description of the subset of SGML</rdg>
                                                    <rdg wit="#p3">SGML standard, see chapter 28, "Conformance," on page 727. For a more technical description of the subset of SGML</rdg>
                                                    <rdg wit="#p4">reader encountering them for the first time how they are actually used in the TEI<app>
                                                            <rdg wit="#p2 #p3 #p4">encoding</rdg>
                                                        </app> scheme. Except where the two are explicitly distinguished, references to XML in what follows may be understood to apply equally well to the TEI usage of SGML. a more technical account of For TEI practice see chapter 28 <hi>Conformance</hi> ; for a more technical description of the subset of SGML</rdg>
                                                </app> used in<app>
                                                    <rdg wit="#p2 #p3 #p4">by</rdg>
                                                </app> the TEI scheme. More detailed technical accounts of TEI practice in this respect are provided in chapters <hi>23. Using the TEI</hi>, <hi>1. The TEI Infrastructure</hi>, and <hi>22. Documentation Elements</hi> of these Guidelines.<app>
                                                    <rdg wit="#p2">, see chapter 39, "Formal Grammar for the TEI-Interchange-Format Subset of SGML," [in separate fascicle]</rdg>
                                                    <rdg wit="#p3">, see chapter 39, "Formal Grammar for the TEI-Interchange-Format Subset of SGML," on page 1247</rdg>
                                                    <rdg wit="#p4">, see chapter 39 <hi>Formal Grammar for the TEI-Interchange-Format Subset of SGML</hi>
                                                    </rdg>
                                                </app> 
                      </p>
                      <!-- ... -->
                    </body>
                  </text>
                </TEI>
              </egXML>
              <head type="legend">Encoding variation with an internal <soCalled>location-referenced</soCalled> apparatus.</head>
            </figure>
          </p>
          <p>Notice how the apparatus entries can occur anywhere as long as it is inside the text structure (in this case, the <gi>p</gi> element) that contains their variants. The same method can be used for an external apparatus, in which the textual variants are encoded either at a different place inside the base text, or in a physically distinct TEI document. In this external apparatus, each apparatus entry must have a specific attribute: <att>loc</att>. Its value should refer to the canonical reference of the text structure that contains the variants concerned. In an external apparatus, the previous example could look as follows:<note>Notice, how the <att>loc</att> attribute does <emph>not</emph> refer to an <att>xml:id</att> value of the text structure concerned, but to its <soCalled>canonical reference</soCalled>. For more information, see the documentation of the <gi>app</gi> element, and section <ref target="https://tei-c.org/release/doc/tei-p5-doc/en/html/HD.html#HD54">2.3.5 The Reference System Declaration</ref> of the TEI Guidelines.</note>
            <figure xml:id="example23">
              <egXML xmlns="http://www.tei-c.org/ns/Examples">
                <TEI>
                  <teiHeader>
                    <!-- ... -->
                    <encodingDesc>
                      <variantEncoding method="location-referenced" location="external"/>
                    </encodingDesc>
                    <!-- ... -->
                  </teiHeader>
                  <text>
                    <body>
                      <!-- ... -->
                      <p n="par2">The encoding scheme defined by these Guidelines is formulated as an application of the Extensible Markup Language (XML) (Bray et al. (eds.) (2006)). XML is widely used for the definition of device-independent, system-independent methods of storing and processing texts in electronic form. It is now also the interchange and communication format used by many applications on the World Wide Web. In the present chapter we informally introduce some of its basic concepts and attempt to explain to the reader encountering them for the first time how and why they are used in the TEI scheme. More detailed technical accounts of TEI practice in this respect are provided in chapters <hi>23. Using the TEI</hi>, <hi>1. The TEI Infrastructure</hi>, and <hi>22. Documentation Elements</hi> of these Guidelines.</p>
                      <!-- ... -->
                    </body>
                    <back>
                      <div type="apparatus">
                        <p>
                          <app loc="par2">
                            <rdg wit="#p2 #p3">is</rdg>
                            <rdg wit="#p4">may be</rdg>
                          </app>
                          <app loc="par2">
                            <rdg wit="#p2 #p3"/>
                            <rdg wit="#p4">either</rdg>
                          </app>
                          <app loc="par2">
                            <rdg wit="#p2 #p3">a system known as the Standard Generalized</rdg>
                            <rdg wit="#p4">the ISO Standard Generalized</rdg>
                          </app>
                          <!-- ... -->
                        </p>
                      </div>
                    </back>
                  </text>
                </TEI>
              </egXML>
              <head type="legend">Encoding variation with an external <soCalled>location-referenced</soCalled> apparatus.</head>
            </figure>
          </p>
          <p>In these examples, the <ident>p5</ident> version of the TEI Guidelines is adopted as the base text to which the apparatus entries are linked. This is the sole text witness for which a full transcription is provided in the electronic critical edition using this reference method. Because of this, the reading of this base text may be omitted from the <gi>app</gi> elements, as in the examples above. Due to the implicit nature of the location references of the apparatus entries, it may be hard to identify the exact places with textual variation. Therefore, the reading of the base text may equally be provided in the apparatus entries inside a <gi>lem</gi> element; combined with string matching, this can help the user of the edition to find out where the actual variation occurs (but notice the difficulty with apparatus entries encoding <emph>additions</emph> to the base text, as in the second <gi>app</gi> element of following example):
            <figure xml:id="example24">
              <egXML xmlns="http://www.tei-c.org/ns/Examples">
                <TEI>
                  <teiHeader>
                    <!-- ... -->
                    <encodingDesc>
                      <variantEncoding method="location-referenced" location="external"/>
                    </encodingDesc>
                    <!-- ... -->
                  </teiHeader>
                  <text>
                    <body>
                      <!-- ... -->
                      <p n="par2">The encoding scheme defined by these Guidelines is formulated as an application of the Extensible Markup Language (XML) (Bray et al. (eds.) (2006)). XML is widely used for the definition of device-independent, system-independent methods of storing and processing texts in electronic form. It is now also the interchange and communication format used by many applications on the World Wide Web. In the present chapter we informally introduce some of its basic concepts and attempt to explain to the reader encountering them for the first time how and why they are used in the TEI scheme. More detailed technical accounts of TEI practice in this respect are provided in chapters <hi>23. Using the TEI</hi>, <hi>1. The TEI Infrastructure</hi>, and <hi>22. Documentation Elements</hi> of these Guidelines.</p>
                      <!-- ... -->
                    </body>
                    <back>
                      <div type="apparatus">
                        <p>
                          <app loc="par2">
                            <lem wit="#p3 #p5">is</lem>
                            <rdg wit="#p4">may be</rdg>
                          </app>
                          <app loc="par2">
                            <lem wit="#p2 #p3 #p5"/>
                            <rdg wit="#p4">either</rdg>
                          </app>
                          <app loc="par2">
                            <lem wit="#p5">the Extensible</lem>
                            <rdg wit="#p2 #p3">a system known as the Standard Generalized</rdg>
                            <rdg wit="#p4">the ISO Standard Generalized</rdg>
                          </app>
                          <!-- ... -->
                        </p>
                      </div>
                    </back>
                  </text>
                </TEI>
              </egXML>
              <head type="legend">Including the base text in an external <soCalled>location-referenced</soCalled> apparatus.</head>
            </figure>
          </p>
          <note type="summary">The location-referenced method uses an implicit anchoring technique to link the apparatus entries with the base text. In an internal apparatus, the apparatus entries can occur anywhere inside the text structure in which their variants occur. In an external apparatus, the link is established through the use of the <att>loc</att> attribute on the <gi>app</gi> elements, which points to a canonical reference of the relevant text structures in the base text.</note>
        </div>
        <div xml:id="doubleEndPoint">
          <head>The Double End-Point Attachment Method</head>
          <p>The double end-point attachment method links an apparatus entry to a base text, by anchoring it to the exact start and end positions of its lemma in the base text. This can be done either internally (inside the running text), or externally (outside the running text).</p>
          <p>In an internal double end-point attachment apparatus, the apparatus entries occur immediately after their lemma in the transcription of the base text. A specific <att>from</att> attribute must be used to point exactly at the starting point of the preceding lemma in the text. Its value should be a pointer to the formal identification code of an element in the base text that corresponds to the start of the lemma. If this point coincides with the start of an existing text structure, the identification code of its element may be used; otherwise, an empty <gi>anchor</gi> element must be inserted in the base text, whose sole purpose is to provide a formal code in its <att>xml:id</att> attribute. For example, an internal double end-point attachment apparatus for the example in the previous section could look as follows:
            <figure xml:id="example25">
              <egXML xmlns="http://www.tei-c.org/ns/Examples">
                <TEI>
                  <teiHeader>
                    <!-- ... -->
                    <encodingDesc>
                      <variantEncoding method="double-end-point" location="internal"/>
                    </encodingDesc>
                    <!-- ... -->
                  </teiHeader>
                  <text>
                    <body>
                      <!-- ... -->
                      <p>The encoding scheme defined by these Guidelines <anchor xml:id="lem1"/>is<app from="#lem1">
                                                    <rdg wit="#p3">is</rdg>
                                                    <rdg wit="#p4">may be</rdg>
                                                </app> formulated <anchor xml:id="lem2"/>
                                                <app from="#lem2">
                                                    <rdg wit="#p2 #p3"/>
                                                    <rdg wit="#p4">either</rdg>
                                                </app> as an application of the <anchor xml:id="lem3"/>Extensible<app from="#lem3">
                                                    <rdg wit="#p2 #p3">a system known as the Standard Generalized</rdg>
                                                    <rdg wit="#p4">the ISO Standard Generalized</rdg>
                                                </app> Markup Language <anchor xml:id="lem4"/>(XML) (Bray et al. (eds.) (2006)). XML is widely used<app from="#lem4">
                                                    <rdg wit="#p2">(SGML).<note place="foot">
                                                            <bibl>
                                                                <editor>International Organization for Standardization</editor>, <title>ISO 8879: Information processing--Text and office systems--Standard Generalized Mark-up Language (SGML)</title>, ([<pubPlace>Geneva</pubPlace>]: <publisher>ISO</publisher>, <date>1986</date>).</bibl> Although widely said to be short for the surnames of its progenitors, the official expansion of this abbreviation is "Standard Generalized Markup Language."</note> SGML is an international standard</rdg>
                                                    <rdg wit="#p3">(SGML). <note place="foot">
                                                            <bibl>
                                                                <editor>International Organization for Standardization</editor>, <title>ISO 8879: Information processing - Text and office systems - Standard Generalized Markup Language (SGML)</title>, ([<pubPlace>Geneva</pubPlace>]: <publisher>ISO</publisher>, <date>1986</date>)</bibl>
                                                        </note> SGML is an international standard</rdg>
                                                    <rdg wit="#p4">(SGML)<note place="foot">
                                                            <bibl>
                                                                <editor>International Organization for Standardization</editor>, <title>ISO 8879: Information processing - Text and office systems - Standard Generalized Markup Language (SGML)</title>, ([<pubPlace>Geneva</pubPlace>]: <publisher>ISO</publisher>, <date>1986</date>)</bibl>
                                                        </note> or of the more recently developed W3C Extensible Markup Language (XML)<note place="foot">
                                                            <bibl>
                                                                <editor>World Wide Web Consortium</editor>: <title>Extensible Markup Language (XML) 1.0</title>, available from <ref target="http://www.w3.org/TR/REC-xml">http://www.w3.org/TR/REC-xml</ref>
                                                            </bibl>
                                                        </note>. Both SGML and XML are widely-used</rdg>
                                                </app> for the definition of device-independent, system-independent methods of <anchor xml:id="lem5"/>storing and processing<app from="#lem5">
                                                    <rdg wit="#p2 #p3">representing</rdg>
                                                    <rdg wit="#p4">storing and processing</rdg>
                                                </app> texts in electronic form<anchor xml:id="lem6"/>. It is now also the interchange and communication format used by many applications on the World Wide Web. In<app from="#lem6">
                                                    <rdg wit="#p2 #p3">. This chapter presents a brief tutorial guide to its main features, for those readers who have not encountered it before. For a more technical account of TEI practice in using</rdg>
                                                    <rdg wit="#p4">; XML being in fact a simplification or derivation of SGML. In the present chapter we introduce informally the basic concepts underlying such markup languages and attempt to explain to</rdg>
                                                </app> the <anchor xml:id="lem7"/>present chapter we informally introduce some of its basic concepts and attempt to explain to the reader encountering them for the first time how and why they are<app from="#lem7">
                                                    <rdg wit="#p2">SGML standard, see chapter 30, "TEI Conformance," [in separate fascicle]; for a more technical description of the subset of SGML</rdg>
                                                    <rdg wit="#p3">SGML standard, see chapter 28, "Conformance," on page 727. For a more technical description of the subset of SGML</rdg>
                                                    <rdg wit="#p4">reader encountering them for the first time how they are actually used in the TEI scheme. Except where the two are explicitly distinguished, references to XML in what follows may be understood to apply equally well to the TEI usage of SGML. a more technical account of For TEI practice see chapter 28 <hi>Conformance</hi> ; for a more technical description of the subset of SGML</rdg>
                                                </app> used <anchor xml:id="lem8"/>in<app from="#lem8">
                                                    <rdg wit="#p2 #p3 #p4">by</rdg>
                                                </app> the TEI <anchor xml:id="lem9"/>
                                                <app from="#lem9">
                                                    <rdg wit="#p2 #p3 #p4">encoding</rdg>
                                                </app>scheme<anchor xml:id="lem10"/>. More detailed technical accounts of TEI practice in this respect are provided in chapters <hi>23. Using the TEI</hi>, <hi>1. The TEI Infrastructure</hi>, and <hi>22. Documentation Elements</hi> of these Guidelines<app from="#lem10">
                                                    <rdg wit="#p2">, see chapter 39, "Formal Grammar for the TEI-Interchange-Format Subset of SGML," [in separate fascicle]</rdg>
                                                    <rdg wit="#p3">, see chapter 39, "Formal Grammar for the TEI-Interchange-Format Subset of SGML," on page 1247</rdg>
                                                    <rdg wit="#p4">, see chapter 39 <hi>Formal Grammar for the TEI-Interchange-Format Subset of SGML</hi>
                                                    </rdg>
                                                </app>.</p>
                      <!-- ... -->
                    </body>
                  </text>
                </TEI>
              </egXML>
              <head type="legend">Encoding variation with an internal <soCalled>double end-point attachment</soCalled> apparatus.</head>
            </figure>
          </p>
          <p>An external double end-point attachment apparatus is very similar to its internal equivalent, apart from the fact that the apparatus entries are located outside of the running text. Due to this physical separation, the need arises to explicitly point out the end point of the lemma in the base text as well (again, either using the <att>xml:id</att> attribute of an existing text structure, or that of an explicit <gi>anchor</gi> element). In order to refer to this end point of the textual variation, the <gi>app</gi> element must have another attribute: <att>to</att>, pointing at the identification code of the relevant point in the base text. For example, an external apparatus for the previous example could look as follows:
            <figure xml:id="example26">
              <egXML xmlns="http://www.tei-c.org/ns/Examples">
                <TEI>
                  <teiHeader>
                    <!-- ... -->
                    <encodingDesc>
                      <variantEncoding method="double-end-point" location="external"/>
                    </encodingDesc>
                    <!-- ... -->
                  </teiHeader>
                  <text>
                    <body>
                      <!-- ... -->
                      <p>The encoding scheme defined by these Guidelines <anchor xml:id="lem1s"/>is<anchor xml:id="lem1e"/> formulated <anchor xml:id="lem2"/> as an application of the <anchor xml:id="lem3s"/>Extensible<anchor xml:id="lem3e"/> Markup Language <anchor xml:id="lem4s"/>(XML) (Bray et al. (eds.) (2006)). XML is widely used<anchor xml:id="lem4e"/> for the definition of device-independent, system-independent methods of <anchor xml:id="lem5"/>storing and processing<anchor xml:id="lem5e"/> texts in electronic form<anchor xml:id="lem6s"/>. It is now also the interchange and communication format used by many applications on the World Wide Web. In<anchor xml:id="lem6e"/> the <anchor xml:id="lem7s"/>present chapter we informally introduce some of its basic concepts and attempt to explain to the reader encountering them for the first time how and why they are<anchor xml:id="lem7e"/> used <anchor xml:id="lem8s"/>in<anchor xml:id="lem8e"/> the TEI <anchor xml:id="lem9"/> scheme<anchor xml:id="lem10s"/>. More detailed technical accounts of TEI practice in this respect are provided in chapters <hi>23. Using the TEI</hi>, <hi>1. The TEI Infrastructure</hi>, and <hi>22. Documentation Elements</hi> of these Guidelines<anchor xml:id="lem10e"/>.</p>
                      <!-- ... -->
                    </body>
                    <back>
                      <div type="apparatus">
                        <p>
                          <app from="#lem1s" to="#lem1e">
                            <rdg wit="#p3">is</rdg>
                            <rdg wit="#p4">may be</rdg>
                          </app>
                          <app from="#lem2" to="#lem2">
                            <rdg wit="#p2 #p3"/>
                            <rdg wit="#p4">either</rdg>
                          </app>
                          <app from="#lem3s" to="#lem3e">
                            <rdg wit="#p2 #p3">a system known as the Standard Generalized</rdg>
                            <rdg wit="#p4">the ISO Standard Generalized</rdg>
                          </app>
                          <!-- ... -->
                        </p>
                      </div>
                    </back>
                  </text>
                </TEI>
              </egXML>
              <head type="legend">Encoding variation with an external <soCalled>double end-point attachment</soCalled> apparatus.</head>
            </figure>
          </p>
          <p>Of course, here too, the lemma of the base text can be explicitly recorded in the apparatus entries as well:
            <figure xml:id="example27">
              <egXML xmlns="http://www.tei-c.org/ns/Examples">
                <TEI>
                  <teiHeader>
                    <!-- ... -->
                    <encodingDesc>
                      <variantEncoding method="double-end-point" location="external"/>
                    </encodingDesc>
                    <!-- ... -->
                  </teiHeader>
                  <text>
                    <body>
                      <!-- ... -->
                      <p>The encoding scheme defined by these Guidelines <anchor xml:id="lem1s"/>is<anchor xml:id="lem1e"/> formulated <anchor xml:id="lem2"/> as an application of the <anchor xml:id="lem3s"/>Extensible<anchor xml:id="lem3e"/> Markup Language <anchor xml:id="lem4s"/>(XML) (Bray et al. (eds.) (2006)). XML is widely used<anchor xml:id="lem4e"/> for the definition of device-independent, system-independent methods of <anchor xml:id="lem5"/>storing and processing<anchor xml:id="lem5e"/> texts in electronic form<anchor xml:id="lem6s"/>. It is now also the interchange and communication format used by many applications on the World Wide Web. In<anchor xml:id="lem6e"/> the <anchor xml:id="lem7s"/>present chapter we informally introduce some of its basic concepts and attempt to explain to the reader encountering them for the first time how and why they are<anchor xml:id="lem7e"/> used <anchor xml:id="lem8s"/>in<anchor xml:id="lem8e"/> the TEI <anchor xml:id="lem9"/> scheme<anchor xml:id="lem10s"/>. More detailed technical accounts of TEI practice in this respect are provided in chapters <hi>23. Using the TEI</hi>, <hi>1. The TEI Infrastructure</hi>, and <hi>22. Documentation Elements</hi> of these Guidelines<anchor xml:id="lem10e"/>.</p>
                      <!-- ... -->
                    </body>
                    <back>
                      <div type="apparatus">
                        <p>
                          <app from="#lem1s" to="#lem1e">
                            <lem wit="#p3 #p5">is</lem>
                            <rdg wit="#p4">may be</rdg>
                          </app>
                          <app from="#lem2" to="#lem2">
                            <lem wit="#p2 #p3 #p5"/>
                            <rdg wit="#p4">either</rdg>
                          </app>
                          <app from="#lem3s" to="#lem3e">
                            <lem wit="#p5">the Extensible</lem>
                            <rdg wit="#p2 #p3">a system known as the Standard Generalized</rdg>
                            <rdg wit="#p4">the ISO Standard Generalized</rdg>
                          </app>
                          <!-- ... -->
                        </p>
                      </div>
                    </back>
                  </text>
                </TEI>
              </egXML>
              <head type="legend">Including the base text in an external <soCalled>double end-point attachment</soCalled> apparatus.</head>
            </figure>
          </p>
          <note type="summary">The double end-point attachment method provides a means to explicitly anchor an apparatus entry to the exact position where its lemma in the base text differs from one of the other readings. In an internal apparatus, the apparatus entries should be placed immediately after the base text’s lemma. Each <gi>app</gi> element must have a <att>from</att> attribute pointing to the <att>xml:id</att> identification code of an element indicating the start of the lemma in the base text. In an external apparatus, the apparatus entries must formally identify the end point of the lemma as well, using a <att>to</att> attribute that points to the <att>xml:id</att> identification code of an element indicating the end of the lemma in the base text. If no other elements are available, these <att>xml:id</att> attributes may be encoded on empty <gi>anchor</gi> elements inside the base text.</note>
        </div>
        <div xml:id="parallelSeg">
          <head>The Parallel Segmentation Method</head>
          <p>Contrary to both other methods, the parallel segmentation method only allows for the encoding of an inline apparatus. Similarly to an internal double end-point attachment apparatus entry, a parallel segmented apparatus entry is encoded inline, at the exact place where the variation occurs. However, a parallel segmented apparatus entry encodes <emph>all</emph> readings as equal variants, thus interweaving the common (invariant) text of all text witnesses with apparatus entries that contain all different alternative readings. In this sense, the notions of a <term>base text</term> and <term>lemma</term> become obsolete: all text that is common, is shared; all varying text is encoded as a separate reading in an apparatus entry. Because of this exact anchoring at the place of occurrence in the <soCalled>palimpsest</soCalled> text, no specific attributes are necessary for the <gi>app</gi> element. For example, the preceding example can be expressed as a parallel segmented apparatus as follows:
            <figure xml:id="example28">
              <egXML xmlns="http://www.tei-c.org/ns/Examples">
                <TEI>
                  <teiHeader>
                    <!-- ... -->
                    <encodingDesc>
                      <variantEncoding method="parallel-segmentation" location="internal"/>
                    </encodingDesc>
                    <!-- ... -->
                  </teiHeader>
                  <text>
                    <body>
                      <!-- ... -->
                      <p>The encoding scheme defined by these Guidelines <app>
                                                    <rdg wit="#p2 #p3 #p5">is</rdg>
                                                    <rdg wit="#p4">may be</rdg>
                                                </app> formulated <app>
                                                    <rdg wit="#p4">either </rdg>
                                                    <rdg wit="#p2 #p3 #p5"/>
                                                </app>as an application of <app>
                                                    <rdg wit="#p2 #p3">a system known as the Standard Generalized</rdg>
                                                    <rdg wit="#p4">the ISO Standard Generalized</rdg>
                                                    <rdg wit="#p5">the Extensible</rdg>
                                                </app> Markup Language <app>
                                                    <rdg wit="#p2">(SGML).<note place="foot">
                                                            <bibl>
                                                                <editor>International Organization for Standardization</editor>, <title>ISO 8879: Information processing--Text and office systems--Standard Generalized Mark-up Language (SGML)</title>, ([<pubPlace>Geneva</pubPlace>]: <publisher>ISO</publisher>, <date>1986</date>).</bibl> Although widely said to be short for the surnames of its progenitors, the official expansion of this abbreviation is "Standard Generalized Markup Language."</note> SGML is an international standard</rdg>
                                                    <rdg wit="#p3">(SGML). <note place="foot">
                                                            <bibl>
                                                                <editor>International Organization for Standardization</editor>, <title>ISO 8879: Information processing - Text and office systems - Standard Generalized Markup Language (SGML)</title>, ([<pubPlace>Geneva</pubPlace>]: <publisher>ISO</publisher>, <date>1986</date>)</bibl>
                                                        </note> SGML is an international standard</rdg>
                                                    <rdg wit="#p4">(SGML)<note place="foot">
                                                            <bibl>
                                                                <editor>International Organization for Standardization</editor>, <title>ISO 8879: Information processing - Text and office systems - Standard Generalized Markup Language (SGML)</title>, ([<pubPlace>Geneva</pubPlace>]: <publisher>ISO</publisher>, <date>1986</date>)</bibl>
                                                        </note>or of the more recently developed W3C Extensible Markup Language (XML)<note place="foot">
                                                            <bibl>
                                                                <editor>World Wide Web Consortium</editor> : <title>Extensible Markup Language (XML) 1.0</title>, available from <ref target="http://www.w3.org/TR/REC-xml">http://www.w3.org/TR/REC-xml</ref>
                                                            </bibl>
                                                        </note>. Both SGML and XML are widely-used</rdg>
                                                    <rdg wit="#p5">(XML) (Bray et al. (eds.) (2006)). XML is widely used</rdg>
                                                </app> for the definition of device-independent, system-independent methods of <app>
                                                    <rdg wit="#p2 #p3">representing</rdg>
                                                    <rdg wit="#p4 #p5">storing and processing</rdg>
                                                </app> texts in electronic form<app>
                                                    <rdg wit="#p2 #p3">. This chapter presents a brief tutorial guide to its main features, for those readers who have not encountered it before. For a more technical account of TEI practice in using</rdg>
                                                    <rdg wit="#p4">; XML being in fact a simplification or derivation of SGML. In the present chapter we introduce informally the basic concepts underlying such markup languages and attempt to explain to</rdg>
                                                    <rdg wit="#p5">. It is now also the interchange and communication format used by many applications on the World Wide Web. In</rdg>
                                                </app> the <app>
                                                    <rdg wit="#p2">SGML standard, see chapter 30, "TEI Conformance," [in separate fascicle]; for a more technical description of the subset of SGML</rdg>
                                                    <rdg wit="#p3">SGML standard, see chapter 28, "Conformance," on page 727. For a more technical description of the subset of SGML</rdg>
                                                    <rdg wit="#p4">reader encountering them for the first time how they are actually used in the TEI scheme. Except where the two are explicitly distinguished, references to XML in what follows may be understood to apply equally well to the TEI usage of SGML. a more technical account of For TEI practice see chapter 28 <hi>Conformance</hi> ; for a more technical description of the subset of SGML</rdg>
                                                    <rdg wit="#p5">present chapter we informally introduce some of its concepts and attempt to explain to the reader encountering them basic for the first time how and why they are</rdg>
                                                </app> used <app>
                                                    <rdg wit="#p2 #p3 #p4">by</rdg>
                                                    <rdg wit="#p5">in</rdg>
                                                </app> the TEI <app>
                                                    <rdg wit="#p2 #p3 #p4">encoding</rdg>
                                                    <rdg wit="#p5"/>
                                                </app> scheme<app>
                                                    <rdg wit="#p2">, see chapter 39, "Formal Grammar for the TEI-Interchange-Format Subset of SGML," [in separate fascicle]</rdg>
                                                    <rdg wit="#p3">, see chapter 39, "Formal Grammar for the TEI-Interchange-Format Subset of SGML," on page 1247</rdg>
                                                    <rdg wit="#p4">, see chapter 39 <hi>Formal Grammar for the TEI-Interchange-Format Subset of SGML</hi>
                                                    </rdg>
                                                    <rdg wit="#p5">. More detailed technical accounts of TEI practice in this respect are provided in chapters <hi>23. Using the TEI</hi>, <hi>1. The TEI Infrastructure</hi>, and <hi>22. Documentation Elements</hi> of these Guidelines</rdg>
                                                </app>.</p>
                      <!-- ... -->
                    </body>
                  </text>
                </TEI>
              </egXML>
              <head type="legend">Encoding variation with an (internal) <soCalled>parallel segmentation</soCalled> apparatus.</head>
            </figure>
          </p>
          <note type="summary">The parallel segmentation method encodes all variants as equal readings inside apparatus entries that are located at their precise place of occurrence in all texts. This results in a single text that contains an integral view on both the common text and the textual variants. Because of this, the notions of <term>base text</term> and <term>lemma</term> become irrelevant.</note>
        </div>
      </div>
            <div xml:id="appCaveat">
        <head>Caveats</head>
        <p>Until the release of <ref target="https://tei-c.org/Vault/P5/2.9.1/doc/tei-p5-doc/en/html/">version 2.9.1</ref> of the TEI Guidelines in 2015, <gi>lem</gi> and <gi>rdg</gi> could only contain phrase-level elements. For a very long time, this had caused problems for variants that involve larger structural units. Yet, since version 2.9.1, <gi>lem</gi> and <gi>rdg</gi> can contain chunk-level elements such as <gi>div</gi>, <gi>p</gi>, <gi>ab</gi>, <gi>lg</gi>, and <gi>l</gi>. This addition has greatly increased the use of <gi>lem</gi> and <gi>rdg</gi> for encoding real-life textual variation.</p>
        <p>One tough problem remains, however, when textual variation occurs on a structural level. For example, if you look closely at the facsimiles of the TEI Guidelines above (see <ptr type="crossref" target="#figure1 #figure2 #figure3 #figure4"/>), you’ll notice that there is a paragraph shift at the sentence starting with <q>Historically, the word markup has been used </q>:
          <list rend="bulleted">
            <item>in the <ident>p2</ident> and <ident>p3</ident> versions, this sentence starts the third paragraph</item>
            <item>in the <ident>p4</ident> and <ident>p5</ident> versions, this sentence is part of the second paragraph</item>
          </list>
        </p>
        <p>This poses a harder encoding problem, as it involves markup itself (i.e., the end and start tag of the third paragraph are the subject of variation). As XML requires proper nesting of elements, this is a problem in any XML representation of this kind of structural variation. Again, two strategies could be followed (none of which is ideal, however): 
          <list rend="bulleted">
            <item>Encode structural variants as variant structures. However, this may obscure their alignment.</item>
            <item>Encode structural variants using milestone elements instead of full-blown XML structures. However, depending on your view on the texts, this could be considered a less orthodox approach, as it implies some notion of a base text that determines the encoding of the others.</item>
          </list>
        </p>
        <p>The first option would compare the individual transcriptions of these text witnesses, some of which spread more or less the same textual contents over 3 paragraphs, while others use only 2 paragraphs. In a parallel segmented apparatus, this might look as follows:
          <figure xml:id="example29">
            <egXML xmlns="http://www.tei-c.org/ns/Examples">
              <app>
                <rdg wit="#p2_p #p3_p">
                  <p>SGML is an international standard for the description of marked-up electronic text. More exactly, SGML is a <app>
                                            <rdg wit="#p2_p">metalanguage</rdg>
                                            <rdg wit="#p3_p">
                                                <hi>metalanguage</hi>
                                            </rdg>
                                        </app>, that is, a means of formally describing a language, in this case, a <app>
                                            <rdg wit="#p2_p">markup language</rdg>
                                            <rdg wit="#p3_p">
                                                <hi>markup language</hi>
                                            </rdg>
                                        </app>. Before going any further we should define these terms.</p>
                </rdg>
                <rdg wit="#p4 #p5"/>
              </app>
              <p>
                                <app>
                                    <rdg wit="#p4">XML is an extensible markup language used for the description of marked-up electronic text. More exactly, XML is a <hi>metalanguage</hi>, that is, a means of formally describing a language, in this case, a <hi>markup language</hi>.</rdg>
                                    <rdg wit="#p5">Strictly speaking, XML is a metalanguage, that is, a language used to describe other languages, in this case, markup languages.</rdg>
                                    <rdg wit="#p2_p #p3_p"/>
                                </app>Historically, the word<!-- ... -->
              </p>
            </egXML>
            <head type="legend">Encoding structural variants as variant structures.</head>
          </figure>
        </p>
        <p>This approach treats the shifting paragraph as a variant in its own right, that is present in some witnesses (<ident>p2</ident> and <ident>p3</ident>), while absent in the others (<ident>p4</ident> and <ident>p5</ident>). The second apparatus entry then omits the text of <ident>p2</ident> and <ident>p3</ident>, while including the (corresponding) text of <ident>p4</ident> and <ident>p5</ident>. However, as this example illustrates, the alignment of the corresponding text fragments between both groups of witnesses (those starting a new paragraph and those that don’t) is lost: there is no way of telling how the phrases <q>SGML is an international standard <gap/> . More exactly, SGML <gap/>
                    </q> (in <ident>p2</ident> and <ident>p3</ident>) and <q>XML is an extensible markup language <gap/> . More exactly, XML <gap/>
                    </q> correspond. This kind of encoding could be less problematic when <emph>generating</emph> an electronic critical edition (in which case the more complicated apparatus encoding could be generated by an automatic collation routine). When <emph>creating</emph> a digital edition, the construction of such a more complex apparatus entry could be less desirable.</p>
        <p>The other solution would be to encode the paragraph break in the <ident>p2</ident> and <ident>p3</ident> versions using an empty <soCalled>milestone</soCalled> marker: an empty element that indicates some kind of structural boundary in the text where it occurs, as in this parallel segmented example:
          <figure xml:id="example30">
            <egXML xmlns="http://www.tei-c.org/ns/Examples">
              <p>
                                <app>
                                    <rdg wit="#p2 #p3">SGML is an international standard for the description of marked-up electronic text. More exactly</rdg>
                                    <rdg wit="#p4">XML is an extensible markup language used for the description of marked-up electronic text. More exactly</rdg>
                                    <rdg wit="#p5">Strictly speaking</rdg>
                                </app>, <app>
                                    <rdg wit="#p2 #p3">SGML</rdg>
                                    <rdg wit="#p4 #p5">XML</rdg>
                                </app> is a <app>
                                    <rdg wit="#p2 #p5">metalanguage</rdg>
                                    <rdg wit="#p3 #p4">
                                        <hi>metalanguage</hi>
                                    </rdg>
                                </app>, that is, a <app>
                                    <rdg wit="#p2 #p3 #p4">means of formally describing a language</rdg>
                                    <rdg wit="#p5">language used to describe other languages</rdg>
                                </app>, in this case, <app>
                                    <rdg wit="#p2">a markup language</rdg>
                                    <rdg wit="#p3 #p4">a <hi>markup language</hi>
                                    </rdg>
                                    <rdg wit="#p5">markup languages</rdg>
                                </app>. <app>
                                    <rdg wit="#p2 #p3">Before going any further we should define these terms. <milestone unit="p"/>
                                    </rdg>
                                    <rdg wit="#p4 #p5"/>
                                </app>Historically, the word <!-- ... -->
                            </p>
            </egXML>
            <head type="legend">Encoding structural variation with <soCalled>milestone</soCalled> markers.</head>
          </figure>
        </p>
        <p>Since the milestone paragraph boundary marker (<tag type="empty">milestone unit="p"</tag>) removes the intrusive XML boundaries, this allows us to compare the text between all versions. However, this implies that the encoding of the third paragraph in the <ident>p2</ident> and <ident>p3</ident> versions is <emph>suppressed</emph>, in contrast to the other paragraphs in these text versions. This could be less a problem when <emph>creating</emph> an electronic critical edition, rather than when generating one. In the latter case, the milestone encoding would reflect a dependency on a base text (that does not have the paragraph break). Moreover, it presupposes some kind of structural alignment prior to the encoding of the individual texts.</p>
        <note type="summary">Problems can arise when the variation involves text structures as well, giving rise to problems of overlapping XML structures. This can be avoided by either ignoring the possible alignment of such structures in the apparatus, or paraphrasing some structural boundaries with empty milestone elements.</note>
      </div>
            <div xml:id="summary">
        <head>Summary</head>
        <p>This tutorial module has focused on the encoding of textual variation in different text witnesses. Although the determination of textual variation itself can depend on the editorial theories for the critical edition, and the TEI Guidelines offer many possibilities to encode textual variation, we’ll conclude with a possible encoding as a critical edition of the text samples we used in this tutorial module. In this example, we chose for a parallel segmented internal apparatus, which could look as follows:</p>
        <figure xml:id="example31">
          <egXML xmlns="http://www.tei-c.org/ns/Examples">
            <TEI>
              <teiHeader>
                <fileDesc>
                  <!-- ... -->
                  <sourceDesc>
                    <listWit>
                      <witness xml:id="p2">
                        <bibl>
                                                    <editor>Sperberg-McQueen, M.</editor>; <editor>Burnard, L.</editor> (eds.). <title>TEI P2 Guidelines for the Encoding and Interchange of Machine Readable Texts Draft P2</title> (published serially 1992-1993); Draft Version <date when="1993-04-02">2 of April 1993</date>: <extent>19 chapters</extent>. Available from <ptr target="https://tei-c.org/Vault/Vault-GL.html"/> (accessed October 2008)</bibl>
                      </witness>
                      <witness xml:id="p3">
                        <bibl>
                                                    <editor>Sperberg-McQueen, C.M.</editor>; <editor>Burnard, L.</editor> (eds.). <title>Guidelines for Electronic Text Encoding and Interchange. TEI P3. Revised reprint.</title>
                          <publisher>Text Encoding Initiative</publisher>: <pubPlace>Oxford</pubPlace>, <pubPlace>Providence</pubPlace>, <pubPlace>Charlottesville</pubPlace>, <pubPlace>Bergen</pubPlace>, <date when="1999">1999</date>
                        </bibl>
                      </witness>
                      <witness xml:id="p4">
                        <bibl>
                                                    <editor>Sperberg-McQueen, C.M.</editor>; <editor>Burnard, L.</editor> (eds.). <title>TEI P4: Guidelines for Electronic Text Encoding and Interchange. XML-compatible edition.</title>
                          <publisher>Text Encoding Initiative Consortium</publisher>: <pubPlace>Oxford</pubPlace>, <pubPlace>Providence</pubPlace>, <pubPlace>Charlottesville</pubPlace>, <pubPlace>Bergen</pubPlace>, <date when="2002">2002</date>
                        </bibl>
                      </witness>
                      <witness xml:id="p5">
                        <bibl>
                                                    <editor>Sperberg-McQueen, C.M.</editor>; <editor>Burnard, L.</editor> (eds.). <title>TEI P5: Guidelines for Electronic Text Encoding and Interchange. Revised and re-edited.</title>
                          <publisher>Text Encoding Initiative Consortium</publisher>: <pubPlace>Oxford</pubPlace>, <pubPlace>Providence</pubPlace>, <pubPlace>Charlottesville</pubPlace>, <pubPlace>Nancy</pubPlace>, <date when="2005">2005</date>
                        </bibl>
                      </witness>
                    </listWit>
                  </sourceDesc>
                </fileDesc>
                <!-- ... -->
                <encodingDesc>
                  <variantEncoding method="parallel-segmentation" location="internal"/>
                </encodingDesc>
                <!-- ... -->
              </teiHeader>
              <text>
                <body>
                  <app>
                    <rdg wit="#p2">
                      <pb n="2"/>
                    </rdg>
                    <rdg wit="#p3 #p4">
                      <pb n="13"/>
                    </rdg>
                    <rdg wit="#p5">
                      <pb n="xxxi"/>
                    </rdg>
                  </app>
                  <head>
                                        <app>
                                            <rdg wit="#p2 #p3">Chapter 2 <lb/>
                                            </rdg>
                                            <rdg wit="#p5">v <lb/>
                                            </rdg>
                                            <rdg wit="#p4">2</rdg>
                                        </app> A <app>
                                            <rdg wit="#p2">GENTLE INTRODUCTION TO SGML</rdg>
                                            <rdg wit="#p3">Gentle Introduction to SGML</rdg>
                                            <rdg wit="#p4 #p5">Gentle Introduction to XML</rdg>
                                        </app>
                                    </head>
                  <app>
                    <rdg wit="#p4">
                      <note type="disclaimer">As originally published in previous editions of the Guidelines, this chapter provided a gentle introduction to 'just enough' SGML for anyone to understand how the TEI used that standard. Since then, the Gentle Guide seems to have taken on a life of its own independent of the Guidelines, having been widely distributed (and flatteringly imitated) on the web. In revising it for the present draft, the editors have therefore felt free to reduce considerably its discussion of SGML-specific matters, in favour of a simple presentation of how the TEI uses XML.</note>
                    </rdg>
                    <rdg wit="#p2 #p3 #p5"/>
                  </app>
                  <p>The encoding scheme defined by these Guidelines <app>
                                            <rdg wit="#p2 #p3 #p5">is</rdg>
                                            <rdg wit="#p4">may be</rdg>
                                        </app> formulated <app>
                                            <rdg wit="#p4">either </rdg>
                                            <rdg wit="#p2 #p3 #p5"/>
                                        </app>as an application of <app>
                                            <rdg wit="#p2 #p3">a system known as the Standard Generalized</rdg>
                                            <rdg wit="#p4">the ISO Standard Generalized</rdg>
                                            <rdg wit="#p5">the Extensible</rdg>
                                        </app> Markup Language <app>
                                            <rdg wit="#p2">(SGML).<note place="foot">
                                                    <bibl>
                                                        <editor>International Organization for Standardization</editor>, <title>ISO 8879: Information processing--Text and office systems--Standard Generalized Mark-up Language (SGML)</title>, ([<pubPlace>Geneva</pubPlace>]: <publisher>ISO</publisher>, <date>1986</date>).</bibl> Although widely said to be short for the surnames of its progenitors, the official expansion of this abbreviation is "Standard Generalized Markup Language."</note> SGML is an international standard</rdg>
                                            <rdg wit="#p3">(SGML). <note place="foot">
                                                    <bibl>
                                                        <editor>International Organization for Standardization</editor>, <title>ISO 8879: Information processing - Text and office systems - Standard Generalized Markup Language (SGML)</title>, ([<pubPlace>Geneva</pubPlace>]: <publisher>ISO</publisher>, <date>1986</date>)</bibl>
                                                </note> SGML is an international standard</rdg>
                                            <rdg wit="#p4">(SGML)<note place="foot">
                                                    <bibl>
                                                        <editor>International Organization for Standardization</editor>, <title>ISO 8879: Information processing - Text and office systems - Standard Generalized Markup Language (SGML)</title>, ([<pubPlace>Geneva</pubPlace>]: <publisher>ISO</publisher>, <date>1986</date>)</bibl>
                                                </note>or of the more recently developed W3C Extensible Markup Language (XML)<note place="foot">
                                                    <bibl>
                                                        <editor>World Wide Web Consortium</editor> : <title>Extensible Markup Language (XML) 1.0</title>, available from <ref target="http://www.w3.org/TR/REC-xml">http://www.w3.org/TR/REC-xml</ref>
                                                    </bibl>
                                                </note>. Both SGML and XML are widely-used</rdg>
                                            <rdg wit="#p5">(XML) (Bray et al. (eds.) (2006)). XML is widely used</rdg>
                                        </app> for the definition of device-independent, system-independent methods of <app>
                                            <rdg wit="#p2 #p3">representing</rdg>
                                            <rdg wit="#p4 #p5">storing and processing</rdg>
                                        </app> texts in electronic form<app>
                                            <rdg wit="#p2 #p3">. This chapter presents a brief tutorial guide to its main features, for those readers who have not encountered it before. For a more technical account of TEI practice in using</rdg>
                                            <rdg wit="#p4">; XML being in fact a simplification or derivation of SGML. In the present chapter we introduce informally the basic concepts underlying such markup languages and attempt to explain to</rdg>
                                            <rdg wit="#p5">. It is now also the interchange and communication format used by many applications on the World Wide Web. In</rdg>
                                        </app> the <app>
                                            <rdg wit="#p2">SGML standard, see chapter 30, "TEI Conformance," [in separate fascicle]; for a more technical description of the subset of SGML</rdg>
                                            <rdg wit="#p3">SGML standard, see chapter 28, "Conformance," on page 727. For a more technical description of the subset of SGML</rdg>
                                            <rdg wit="#p4">reader encountering them for the first time how they are actually used in the TEI scheme. Except where the two are explicitly distinguished, references to XML in what follows may be understood to apply equally well to the TEI usage of SGML. a more technical account of For TEI practice see chapter 28 <hi>Conformance</hi> ; for a more technical description of the subset of SGML</rdg>
                                            <rdg wit="#p5">present chapter we informally introduce some of its concepts and attempt to explain to the reader encountering them basic for the first time how and why they are</rdg>
                                        </app> used <app>
                                            <rdg wit="#p2 #p3 #p4">by</rdg>
                                            <rdg wit="#p5">in</rdg>
                                        </app> the TEI <app>
                                            <rdg wit="#p2 #p3 #p4">encoding</rdg>
                                            <rdg wit="#p5"/>
                                        </app> scheme<app>
                                            <rdg wit="#p2">, see chapter 39, "Formal Grammar for the TEI-Interchange-Format Subset of SGML," [in separate fascicle]</rdg>
                                            <rdg wit="#p3">, see chapter 39, "Formal Grammar for the TEI-Interchange-Format Subset of SGML," on page 1247</rdg>
                                            <rdg wit="#p4">, see chapter 39 <hi>Formal Grammar for the TEI-Interchange-Format Subset of SGML</hi>
                                            </rdg>
                                            <rdg wit="#p5">. More detailed technical accounts of TEI practice in this respect are provided in chapters <hi>23. Using the TEI</hi>, <hi>1. The TEI Infrastructure</hi>, and <hi>22. Documentation Elements</hi> of these Guidelines</rdg>
                                        </app>.</p>
                  <p>
                                        <app>
                                            <rdg wit="#p2 #p3">SGML is an international standard for the description of marked-up electronic text. More exactly</rdg>
                                            <rdg wit="#p4">XML is an extensible markup language used for the description of marked-up electronic text. More exactly</rdg>
                                            <rdg wit="#p5">Strictly speaking</rdg>
                                        </app>, <app>
                                            <rdg wit="#p2 #p3">SGML</rdg>
                                            <rdg wit="#p4 #p5">XML</rdg>
                                        </app> is a <app>
                                            <rdg wit="#p2 #p5">metalanguage</rdg>
                                            <rdg wit="#p3 #p4">
                                                <hi>metalanguage</hi>
                                            </rdg>
                                        </app>, that is, a <app>
                                            <rdg wit="#p2 #p3 #p4">means of formally describing a language</rdg>
                                            <rdg wit="#p5">language used to describe other languages</rdg>
                                        </app>, in this case, <app>
                                            <rdg wit="#p2">a markup language</rdg>
                                            <rdg wit="#p3 #p4">a <hi>markup language</hi>
                                            </rdg>
                                            <rdg wit="#p5">markup languages</rdg>
                                        </app>. <app>
                                            <rdg wit="#p2 #p3">Before going any further we should define these terms. <milestone unit="p"/>
                                            </rdg>
                                            <rdg wit="#p4 #p5"/>
                                        </app>Historically, the word <app>
                                            <rdg wit="#p2 #p5">markup</rdg>
                                            <rdg wit="#p3 #p4">
                                                <hi>markup</hi>
                                            </rdg>
                                        </app> has been used to describe annotation or other marks within a text intended to instruct a compositor or typist how a particular passage should be printed or laid out. Examples include wavy underlining to indicate boldface, special symbols for passages to be omitted or printed in a particular <app>
                                            <rdg wit="#p2 #p3 #p4">font</rdg>
                                            <rdg wit="#p5">font,</rdg>
                                        </app> and so forth. As the formatting and printing of texts was automated, the term was <app>
                                            <rdg wit="#p2">extend-ed</rdg>
                                            <rdg wit="#p3 #p4 #p5">extended</rdg>
                                        </app> to cover all sorts of special <app>
                                            <rdg wit="#p2">markup codes</rdg>
                                            <rdg wit="#p3">
                                                <hi>markup codes</hi>
                                            </rdg>
                                            <rdg wit="#p4 #p5">codes</rdg>
                                        </app> inserted into electronic texts to govern formatting, printing, or other processing.</p>
                </body>
              </text>
            </TEI>
        </egXML>
          <head type="legend">A parallel segmented encoding of the different text witnesses of the example.</head>
        </figure>
      </div>
            <div xml:id="textcrit.further">
        <head>What’s Next?</head>
        <p>You have reached the end of this tutorial module covering an introduction to critical editing with TEI. You can now either 
          <list rend="bulleted">
            <item>proceed with <ref target="../modules/">other TEI by Example modules</ref>
                        </item>
            <item>have a look at the <ref target="../examples/TBED07v00.htm">examples section</ref> for the critical editing module.</item>
            <item>take an interactive test. This comes in the form of a set of multiple choice questions, each providing a number of possible answers. Throughout the quiz, your score is recorded and feedback is offered about right <hi rend="italic">and</hi> wrong choices. Can you score 100%? Test it <ref target="../tests/TBED07v00.htm">here</ref>!</item>
          </list>
        </p>
      </div>
        </body>
    <back>
      <div type="bibliography">
        <listBibl>
          <bibl xml:id="vanhoutte2009">
                        <author>Vanhoutte, Edward</author>, and <author>Ron Van den Branden</author>. <date>2009</date>. <title level="a">Describing, Transcribing, Encoding, and Editing Modern Correspondence Material: a Textbase Approach</title>. <title level="j">Literary and Linguistic Computing</title> <biblScope unit="volume">24</biblScope> (<biblScope unit="issue">1</biblScope>): <biblScope unit="page">77–98</biblScope>. <idno type="DOI">10.1093/llc/fqn035</idno>.</bibl>
        </listBibl>
      </div>
    </back>
  </text>
  <!--
    $Date: 2020-11-16 12:48:08 +0100 (Mon, 16 Nov 2020) $
    $Id: TBED07v00.xml 462 2020-11-16 11:48:08Z ron.vandenbranden $  -->
</TEI>