Critical Apparatus
Author: TEI,Humanities Computing Unit, 13 Banbury Road, Oxford OX2 6NN, United Kingdom

| ## Text Encoding Initiative
### The XML Version of the TEI Guidelines # 19 Critical Apparatus

Up: Contents Previous: 18 Transcription of Primary Sources Next: 20 Names and Dates

| Scholarly editions of texts, especially texts of great antiquity or importance, often record some or all of the known variations among different witnesses to the text. Witnesses to a text may include authorial or other manuscripts, printed editions of the work, early translations, or quotations of a work in other texts. Information concerning variant readings of a text may be accumulated in highly structured form in a critical apparatus of variants. This chapter defines an additional tag set for use in encoding such an apparatus of variants, which may be used in conjunction with any of the base tag sets defined in these Guidelines. It also defines an element class which provides extra attributes for some elements of the core tag set when this additional tag set is selected. This tag set is selected as described in 3.3 Invocation of the TEI DTD; in a document which uses the markup described in this chapter, the document type declaration should contain the following declaration of the entity TEI.textcrit, or an equivalent one:
    <!ENTITY % TEI.textcrit 'INCLUDE'>
The entire document type declaration for an XML document using this additional tag set together with the base tag set for prose might look like this:
    <!DOCTYPE TEI.2 PUBLIC "-//TEI P4//DTD Main Document Type//EN" "tei2.dtd" [
        <!ENTITY % TEI.XML       'INCLUDE' >
        <!ENTITY % TEI.prose     'INCLUDE' >
        <!ENTITY % TEI.textcrit  'INCLUDE' >
     ]>
The overall document type declaration for this additional tag set has the following structure. First, the file teitc2.ent defines some element classes relevant to this tag set:
    <!-- 19.: Entity classes for text criticism-->
    <!--Text Encoding Initiative Consortium:
    Guidelines for Electronic Text Encoding and Interchange.
    Document TEI P4, 2002.
    Copyright (c) 2002 TEI Consortium. Permission to copy in any form
    is granted, provided this notice is included in all copies.
    These materials may not be altered; modifications to these DTDs should
    be performed only as specified by the Guidelines, for example in the
    chapter entitled 'Modifying the TEI DTD'
    These materials are subject to revision by the TEI Consortium. Current versions
    are available from the Consortium website at http://www.tei-c.org-->
    <!ENTITY % x.fragmentary "" >
    <!ENTITY % m.fragmentary "%x.fragmentary; %n.lacunaEnd; |
    %n.lacunaStart; | %n.witEnd; | %n.witStart;">
    <!ENTITY % a.fragmentary '
          wit CDATA #IMPLIED'>
    <!ENTITY % a.readings '
          wit CDATA #IMPLIED
          type CDATA #IMPLIED
          cause CDATA #IMPLIED
          varSeq CDATA #IMPLIED
          resp CDATA %INHERITED;
          hand IDREF %INHERITED;'>
    <!-- end of 19.-->
The file teitc2.dtd defines the elements themselves:
    <!-- 19.: Tags for text criticism-->
    <!--Text Encoding Initiative Consortium:
    Guidelines for Electronic Text Encoding and Interchange.
    Document TEI P4, 2002.
    Copyright (c) 2002 TEI Consortium. Permission to copy in any form
    is granted, provided this notice is included in all copies.
    These materials may not be altered; modifications to these DTDs should
    be performed only as specified by the Guidelines, for example in the
    chapter entitled 'Modifying the TEI DTD'
    These materials are subject to revision by the TEI Consortium. Current versions
    are available from the Consortium website at http://www.tei-c.org-->
    [declarations from 19.1.1: Apparatus entry inserted here ]

    [declarations from 19.1.2: Readings inserted here ]

    [declarations from 19.1.3: Reading Groups inserted here ]

    [declarations from 19.1.4.1: Witness Details inserted here ]

    [declarations from 19.1.4.2: Source-text Witness Lists in Apparatus
    inserted here ]

    [declarations from 19.1.4.3: Witness Lists in Front Matter inserted here ]

    [declarations from 19.1.5: Fragmentary witnesses inserted here ]
    <!-- end of 19.-->
- Information about variant readings (whether or not represented by a critical apparatus in the source text) may be recorded in a series of apparatus entries, each entry documenting one variation, or set of readings, in the text. Tags for the apparatus entry and readings, and for the documentation of the witnesses whose readings are included in the apparatus, are described in section 19.1 The Apparatus Entry, Readings, and Witnesses. Special tags for fragmentary witnesses are described in section 19.1.5 Fragmentary Witnesses. The available methods for embedding the apparatus in the rest of the text, or for linking an external apparatus to the base text, are described in section 19.2 Linking the Apparatus to the Text. Finally, several extra attributes for some tags of the core tag set, made available when the additional tag set for text criticism is selected, are documented in section 18.1.1 Use of Core Tags for Transcriptional Work. Many examples given in this chapter refer to the following texts of the opening (usually just line 1) of Chaucer's Wife of Bath's Prologue: El Ellesmere, Huntingdon Library 26.C.9: Experience though noon Auctoritee / Were in this world, were right ynogh to me / To speke of wo that is in mariage; ... Hg Hengwrt, National Library of Wales, Aberystwyth, Peniarth 392D: Experience thogh noon Auctoritee / Were in this world, is right ynogh for me / To speke of wo that is in mariage; ... La British Library Lansdowne 851: Experiment thouh none auctorite / Were in this world, is right ynohe for me / To speke of wo that is in mariage; ... Ra2 Bodleian Library Rawlinson Poetic 149: Eryment though none auctorite / Were in this world, it is right ynow for me / To speke of wo that is in mariage; ... #### 19.1 The Apparatus Entry, Readings, and Witnesses This section introduces the fundamental markup methods used to encode textual variations: the `<app>` element for entries in the critical apparatus: see section 19.1.1 The Apparatus Entry. elements for identifying individual readings: see section 19.1.2 Readings. ways of grouping readings together: see section 19.1.3 Indicating Subvariation in Apparatus Entries. methods of identifying which witnesses support a particular reading, and for describing the witnesses included in the apparatus: see section 19.1.4 Witness Information. elements for indicating which portions of a text are covered by fragmentary witnesses: see section 19.1.5 Fragmentary Witnesses. ##### 19.1.1 The Apparatus Entry Individual textual variations are encoded using the `<app>` element, which groups together all the readings constituting the variation. The identification of discrete textual variations or apparatus entries is not a purely mechanical process; different editors may group readings differently. No rules are given here as to how to group readings into apparatus entries; the tags given here may be used to group readings in whatever way the editor finds most perspicuous or useful. The individual apparatus entry is encoded with the `<app>` element: <app> contains one entry in a critical apparatus, with an optional lemma and at least one reading.
  type | classifies the variation contained in this element according to some convenient typology.
  from | identifies the beginning of the lemma in the base text, if necessary.
  to | identifies the endpoint of the lemma in the base text, if necessary.
  loc | (location) indicates the location of the variation, when the location-referenced method of apparatus markup is used.
The attributes `loc`, `from`, and `to`, are used to link the apparatus entry to the base text. Several methods may be used for such linkage, each involving a slightly different usage for these attributes. Linkage between text and apparatus is described below in section 19.2 Linking the Apparatus to the Text. Each `<app>` element comprises one or more readings, which in turn are encoded using the `<rdg>` or other elements, as described in the next section. A very simple partial apparatus for the first line of the Wife of Bath's Prologue might take a form something like this:
    <app>
       <rdg wit="El">Experience though noon Auctoritee</rdg>
       <rdg wit="La">Experiment thogh noon Auctoritee</rdg>
       <rdg wit="Ra2">Eryment though none auctorite</rdg>
    </app>
Of course, in practice the apparatus will be somewhat more complex. Specifically, it may be desired to record more obviously that manuscripts El and La agree on the words ‘noon Auctoritee’, to indicate a preference for one reading, etc. The following sections on readings, subvariation, and witness information describe some of the more important complications which can arise. The structure of an `<app>` element is formally defined as follows:
    <!-- 19.1.1: Apparatus entry-->
    <!ELEMENT app %om.RO;  ( (%m.Incl;)*, (lem, (%m.Incl;)*, (wit,
    (%m.Incl;)*)? )?,
                            ( (rdg, (%m.Incl;)*, (wit, (%m.Incl;)*)? )
                            | (rdgGrp, (%m.Incl;)*, (wit, (%m.Incl;)*)? ) )+)>
    <!ATTLIST app
          %a.global;
          type CDATA #IMPLIED
          from IDREF #IMPLIED
          to IDREF #IMPLIED
          loc CDATA #IMPLIED
          TEIform CDATA 'app'  >
    <!-- end of 19.1.1-->
- ##### 19.1.2 Readings Individual readings are the crucial elements in any critical apparatus of variants. The following elements should be used to tag individual readings within an apparatus entry: <lem> contains the lemma, or base text, of a textual variation.
  No attributes other than those globally available (see definition for a.global)
- <rdg> contains a single reading within a textual variation.
  No attributes other than those globally available (see definition for a.global)
N.B. the term lemma is used here in the text-critical sense of ‘the reading accepted as that of the original or of the base text’ — it is not to be confused with ‘the heading of an entry in a reference book, especially a dictionary,’ nor with ‘a subsidiary proposition introduced in the proof of some other proposition; a helping theorem.’ In recording readings within an apparatus entry, the `<rdg>` element may always be used; each `<app>` must contain at least one `<rdg>`. The `<lem>` element may also be used, under some circumstances, to record the base text of the source edition, to mark the readings of a base witness, to indicate the preference of an editor or encoder for a particular reading, or to make clear, in cases of ambiguity, precisely which portion of the main text the variation applies to. Those who prefer to work without the notion of a base text may prefer not to use it at all. How it is used depends in part on the method chosen for linking the apparatus to the text; for more information, see section 19.2 Linking the Apparatus to the Text. Readings may be encoded individually, or grouped for perspicuity using the `<rdgGrp>` element described in section 19.1.3 Indicating Subvariation in Apparatus Entries. As members of the attribute class readings, both of these elements inherit the following attributes. Some of these attributes are intelligible only if the reading is ascribed to a single witness; others have no such restriction.
`wit` | contains a list of one or more sigla indicating the witnesses which attest to a given reading.
`type` | classifies the reading according to some useful typology.
`cause` | classifies the reading as original or non-original, according to some typology of possible origins.
`varSeq` | provides a number indicating the position of this reading in a sequence, when there is reason to presume a sequence to the variants on any one lemma.
`hand` | signifies the hand responsible for a particular reading in the witness.
`resp` | identifies the editor responsible for asserting a particular reading in the witness.
The `wit` attribute identifies the witnesses which have the reading in question. It is required if the apparatus gathers together readings from different witnesses, but may be omitted in an apparatus recording the readings of only one witness, e.g. substitutions, divergent opinions on what is in the witness or on how to expand abbreviations, etc. Even in such a one-witness apparatus, however, the `wit` attribute may still be useful when it is desired to record the occurrence of a particular reading in some other witness. For other methods of identifying the witnesses to a reading, see section 19.1.4 Witness Information. The `type` attribute allows the encoder to classify readings in any convenient way, for example as substantive variants of the lemma:
    <app>
       <lem wit="El Hg">Experience</lem>
       <rdg wit="La" type="substantive">Experiment</rdg>
       <rdg wit="Ra2" type="substantive">Eryment</rdg>
    </app>
or as orthographic variants:
    <app>
       <lem wit="El Ra2">though</lem>
       <rdg wit="Hg" type="orthographic">thogh</rdg>
       <rdg wit="La" type="orthographic">thouh</rdg>
    </app>
The `varSeq` and `cause` attributes may be used to convey information on the sequence and cause of variation. In the following apparatus fragment, the reading ‘Eryment' is tagged as sequential to (derived from) the reading ‘Experiment', and the cause is given as loss of the abbreviation for ‘per'.
    <app>
       <rdg wit="La" varSeq="1">Experiment</rdg>
       <rdg wit="Ra2" cause="abbreviation loss" varSeq="2">Eryment</rdg>
    </app>
If a manuscript is written in several hands, and it is desired to report which hand wrote a particular reading, the `hand` attribute should be used. For example, in the Munich manuscript containing the Carmina Burana, the word ‘alle' has been changed to ‘allen':
    <l>Swaz hi g&acirc;t umbe</l>
    <l>daz sint alle megede,</l>
    <l>die wellent &acirc;n man</l>
    <l>
       <app>
          <rdg wit="M" varSeq="1" hand="m1">alle</rdg>
          <rdg wit="M" cause="nachgetragen" varSeq="2" hand="m2">allen</rdg>
       </app>
    disen sumer g&acirc;n.</l>
Similarly, if a witness is hard to decipher, it may be desired to indicate responsibility for the claim that a particular reading is supported by a particular witness. In line 2212a of Beowulf, for example, the manuscript is read in different ways by different scholars; the editor Klaeber prints one text, and records in the apparatus two different accounts of the manuscript reading, by Zupitza and Chambers:153
    <l>se &eth;e on
      <app>
         <rdg wit="Kl">hea(um) h(&aelig;&th;)e</rdg>
         <rdg wit="MS" resp="Z">hea&eth;o hl&aelig;we</rdg>
         <rdg wit="MS" resp="Cha">heaum hope</rdg>
      </app></l>
    <l>hord beweotode,</l>
The `hand` and `resp` attributes are intelligible only on an element recording a reading from a single witness, and should not be used if more than one witness is given on the same `<rdg>` or `<lem>` element. If more than one witness is given for the reading, they are undefined. To convey this information when the witness is one among several, the `<witDetail>` element should be used; see section 19.1.4 Witness Information. Where there is a greater weight of editorial discussion and interpretation than can conveniently be expressed through the attributes provided on these tags (e.g. multiple causes for a single reading; multiple editorial responsibility for an emendation) this information can be attached to the apparatus in a note, or recorded in the feature structure notation defined in chapter 16 Feature Structures. In particular, such recurring text-critical situations as palaeographic confusion of particular letters, or homoeoarchy or homoeoteleuton involving specific character groups, may lend themselves to feature structure treatment. Information concerning these recurrent situations may be encoded into database-like fragments within the text which would then be available to sophisticated computer-assisted analysis. Further work remains to be done on such mechanisms, however, and so no examples are given here of the use of feature structures in text-critical apparatus. The `<note>` element may also be used to record the specific wording of notes in the apparatus of the source edition, as here in a transcription of Friedrich Klaeber's note on Beowulf 2207a:
    <l n="2207a">sy&eth;&eth;an Beowulfe
    <note resp="Kl" place="app">Fol. 179a <mentioned>beowulfe</mentioned>.
      Folio 179, with the last page (Fol. 198b), is the worst part of the
      entire MS. It has been freshened up by a later hand, but not always
      correctly. Information on doubtful readings is in the notes of
      Zupitza and Chambers.</note></l>
    <l n="2207b">brade rice</l>
    <!-- ... -->
Notes providing details of the reading of one particular witness should be encoded using the specialized `<witDetail>` element described in section 19.1.4 Witness Information. Encoders should be aware of the distinct fields of use of the attribute values `wit`, `hand`, and `resp`. Broadly, `wit` identifies the physical entity in which the reading is found (manuscript, clay tablet, papyrus, printed edition); `hand` refers to the agent responsible for inscribing that reading in that physical entity (scribe, author, inscriber, hand 1, hand 2); `resp` indicates the scholar responsible for asserting the existence of that reading in that physical entity. In some cases, the categories may blur: a scholar may produce an edition introducing readings for which he or she is responsible; that edition may itself become a witness in a later critical apparatus. Thus, readings introduced as corrections in the earlier edition will be seen in the later apparatus as witnessed by the earlier edition. As observed in the discussion concerning the discrimination of `hand` and `resp` in transcription of primary sources in section 18.2.2 Hand, Responsibility, and Certainty Attributes, the division of layers of responsibility through various scholars for particular aspects of a particular reading may require the more complex mechanisms for assigning responsibility described in chapter 17 Certainty and Responsibility. The formal declaration of the `<rdg>` and `<lem>` elements is this:
    <!-- 19.1.2: Readings-->
    <!ELEMENT lem %om.RO;  ( #PCDATA | %m.phrase; | %m.inter; |
                             %m.Incl; | %m.fragmentary; )* >
    <!ATTLIST lem
          %a.global;
          %a.readings;
          TEIform CDATA 'lem'  >
    <!ELEMENT rdg %om.RO;  ( #PCDATA | %m.phrase; | %m.inter; |
                             %m.Incl; | %m.fragmentary; )* >
    <!ATTLIST rdg
          %a.global;
          %a.readings;
          TEIform CDATA 'rdg'  >
    <!-- end of 19.1.2-->
- ##### 19.1.3 Indicating Subvariation in Apparatus Entries The `<rdgGrp>` element may be used to group readings, either because they have identical values on one or more attributes, or because they are seen as forming a self-contained variant sequence, or for some other reason. This grouping of readings is entirely optional: no such grouping of readings is required. <rdgGrp> within a textual variation, groups two or more readings perceived to have a genetic relationship or other affinity.
  No attributes other than those globally available (see definition for a.global)
The `<rdgGrp>` element is a member of class readings and therefore can carry the `wit`, `type`, `cause`, `varSeq`, `hand`, and `resp` attributes described in the preceding section. When values for any of these attributes are given on a `<rdgGrp>` element, the values given are inherited by the `<rdg>` or `<lem>` elements nested within the reading group, unless overridden by a new specification on the individual reading element. To indicate that both Hg and La vary only orthographically from the lemma, one might tag both readings `<rdg type='orthographic'>`, as shown in the preceding section. This fact can be expressed more perspicuously, however, by grouping their readings into a `<rdgGrp>`, thus:
    <app>
       <lem wit="El Ra2">though</lem>
       <rdgGrp type="orthographic">
          <rdg wit="Hg">thogh</rdg>
          <rdg wit="La">thouhe</rdg>
       </rdgGrp>
    </app>
Similarly, `<rdgGrp>` may be used to organize the substantive variants of an apparatus entry. Editors may need to indicate that each of a group of witnesses may be taken as all supporting a particular reading, even though there may be variation concerning the exact form of that reading in, or the degree of support offered by, those witnesses. For example: one may identify three substantive variants on the first word of Chaucer's Wife of Bath's Prologue in the manuscripts: these might be expressed in regularized spelling as ‘Experience', ‘Experiment', and ‘Eriment'. In fact, the manuscripts display many different spellings of these words, and a scholar may wish both to show that the manuscripts have all these variant spellings and that these variant spellings actually support only the three regularized spelling forms. One may term these variant spellings as `subvariants' of the regularized spelling forms. This subvariation can be expressed within an `<app>` element by gathering the readings into three groups according to the normalized form of their reading. All the readings within each group may be accounted subvariants of the main reading for the group, which may be indicated by tagging it `<lem>` or `<rdg type='group base'>`. In this example, the different subvariants on ‘Experience', ‘Experiment', and ‘Eriment' are held within three `<rdgGrp>` elements nested within the enclosing `<app>` element:
    <app type='substantive'>
        <rdgGrp type='subvariants'>
            <lem wit='El Hg'>Experience</lem>
            <rdg wit='Ha4'>Experiens</rdg>
        </rdgGrp>
        <rdgGrp type='subvariants'>
            <lem wit='Cp Ld1'>Experiment</lem>
            <rdg wit='La'>Ex&p-underbar;iment</rdg>
        </rdgGrp>
        <rdgGrp type='subvariants'>
            <lem wit='[unattested]'>Eriment</lem>
            <rdg wit='Ra2'>Eryment</rdg>
        </rdgGrp>
    </app>
From this, one may deduce that the regularized reading ‘Experience' is supported by all three manuscripts El Hg Ha4, although the spelling differs in Ha4, and that the regularized reading ‘Eriment' is supported by Ra2, even though the form differs in that manuscript. Accordingly, an application which recognizes that these apparatus entries show subvariation may then assign all the witnesses instanced as attesting the sub-variants on that lemma as actually supporting the reading of the lemma itself at a higher level of classification. Thus, Ha4 here supports the reading ‘Experience' found in El and Hg, even though it is spelt slightly differently in Ha4. Reading groups may nest recursively, so that variants can be classified to any desired depth. Because apparatus entries may also nest, the `<app>` element might also be used to group readings in the same way. The example above is substantially identical to the following, which uses `<app>` instead of `<rdgGrp>`:
    <app id="a1" type="substantive">
       <rdg wit="El Hg Ha4">
          <app id="a2" type="orthographic">
             <lem wit="El Hg">Experience</lem>
             <rdg wit="Ha4">Experiens</rdg>
          </app>
       </rdg>
       <rdg wit="Cp Ld1 La">
          <app id="a3" type="orthographic">
             <lem wit="Cp Ld1">Experiment</lem>
             <rdg wit="La">Ex&p-underbar;iment</rdg>
          </app>
       </rdg>
       <rdg wit="Ra2">
          <app id="a4" type="orthographic">
             <lem wit="[unattested]">Eriment</lem>
             <rdg wit="Ra2">Eryment</rdg>
          </app>
       </rdg>
    </app>
This expresses even more clearly than the previous encoding of this material that at the highest level of classification (apparatus entry A1), this variation has three normalized readings, and that the first of these is supported by manuscripts El, Hg, and Ha4; the second by Cp, Ld1, and La; and the third by Ra2. Some encoders may find the use of nested apparatus entries less intuitive than the use of reading groups, however, so both methods of classifying the readings of a variation are allowed. Reading groups may also be used to bring together variants which form an apparent developmental sequence, and to make clear that other readings are not part of that sequence, as in the following example, which makes clear that the variant sequence ‘experiment' to ‘eriment' says nothing about the relative priority of ‘experiment' and ‘experience':
    <app type='substantive'>
        <rdgGrp type='subvariants'>
            <lem wit='El Hg'>Experience</lem>
            <rdg wit='Ha4'>Experiens</rdg>
        </rdgGrp>
        <rdgGrp type='sequence'>
            <rdgGrp varSeq='1' type='subvariants'>
                <lem wit='Cp Ld1'>Experiment</lem>
                <rdg wit='La'>Ex&p-underbar;iment</rdg>
            </rdgGrp>
            <rdgGrp varSeq='2' cause='loss of abbrev for PER' resp='PR'>
                <lem wit='[unattested]'>Eriment</lem>
                <rdg wit='Ra2'>Eryment</rdg>
            </rdgGrp>
        </rdgGrp>
    </app>
Reading groups are defined formally as follows:
    <!-- 19.1.3: Reading Groups-->
    <!ELEMENT rdgGrp %om.RO; ((%m.Incl;)*, ( (rdgGrp, (%m.Incl;)*)
                         | (rdg, (%m.Incl;)*, (wit, (%m.Incl;)*)?) )+) >
    <!ATTLIST rdgGrp
          %a.global;
          %a.readings;
          TEIform CDATA 'rdgGrp'  >
    <!-- end of 19.1.3-->
- ##### 19.1.4 Witness Information A given reading is associated with the set of witnesses attesting it by listing the witnesses in the `wit` attribute on the `<rdg>`, `<lem>`, or `<rdgGrp>` element. Special mechanisms, described in the following sections, are needed to associate annotation on a reading with one specific witness among several (section 19.1.4.1 Witness Detail Information), to transcribe witness information verbatim from a source edition (section 19.1.4.2 Witness Information in the Source), and to identify the formal lists of witnesses typically provided in the front matter of critical editions (section 19.1.4.3 The Witness List). ###### 19.1.4.1 Witness Detail Information When it is desired to give additional information about a particular witness or witnesses for the reading, the information may be given in a `<witDetail>` element, pointing to the identifier for that reading and signalling in the value of its `wit` attribute the witnesses or witnesses to which the additional information relates. <witDetail> gives further information about a particular witness, or witnesses, to a particular reading.
  target | indicates the identifier for the reading, or readings, to which the witness detail refers.
  wit | indicates the sigil or sigla for the witnesses to which the detail refers.
The `<witDetail>` element is a specialized form of `<note>`, which adds to the attributes of that element the specialized attribute `wit`, which indicates which witness in particular is being described. Like `<note>`, `<witDetail>` can be included in the text at the point of attachment, or can point to the reading(s) being annotated with its `target` attribute. To indicate, on the authority of editor PR, that the Ellesmere manuscript has an ornamental capital in the word ‘Experience', for example, one might write:
    <app type='substantive'>
        <rdgGrp type='subvariants'>
            <lem id='W026' wit='El Hg'>Experience</lem>
            <rdg wit='Ha4'>Experiens</rdg>
        </rdgGrp>
        <!-- ... -->
    </app>

    <!-- elsewhere in the text, perhaps in a separate section of notes ... -->
    <witDetail target='W026' resp='PR' wit='El'>Ornamental capital.</witDetail>
This encoding makes clear that the ornamental capital mentioned is in the Ellesmere manuscript, and not in Hengwrt or Ha4. Like `<note>`, `<witDetail>` may be used to record the specific wording of information in the source text, even when the information itself is captured in some more formal way elsewhere. The example from the Carmina Burana above (section 19.1.2 Readings), for example, might be extended thus, to record the wording of the note explaining the variant:
    <l>Swaz hi g&acirc;t umbe</l>
    <l>daz sint alle megede,</l>
    <l>die wellent &acirc;n man</l>
    <l>
       <app>
          <rdg wit="M" hand="m1">alle</rdg>
          <rdg id="anon.6.4" wit="M" hand="m2">allen</rdg>
       </app>
    disen sumer g&acirc;n.</l>
    <!-- ... -->
    <witDetail target="anon.6.4" wit="M">
       <ref>allen</ref>
       <mentioned>n</mentioned> nachgetragen.
    </witDetail>
Observe that a single witness detail element may be linked to several different readings (noting, for example, a recurrent phenomena in a particular manuscript) by having the `target` attribute point at all the readings in question. Similarly, feature structures containing information about the text in a witness (whether retroversion, regularization, or other) can also be linked to specific `<lem>` and `<rdg>` instances. See chapter 16 Feature Structures. The `<witDetail>` element is formally declared thus:
    <!-- 19.1.4.1: Witness Details-->
    <!ELEMENT witDetail %om.RO; %paraContent;>
    <!ATTLIST witDetail
          %a.global;
          target IDREFS #REQUIRED
          resp CDATA #IMPLIED
          wit CDATA #REQUIRED
          type CDATA #IMPLIED
          place CDATA "apparatus"
          TEIform CDATA 'witDetail'  >
    <!-- end of 19.1.4.1-->
- ###### 19.1.4.2 Witness Information in the Source In the transcription of printed critical editions, it may be desirable to retain for future reference the exact form in which the source edition records the witnesses to a particular reading; this is particularly important in cases of ambiguity in the information, or uncertainty as to the correct interpretation. The `<wit>` element may be used to transcribe such lists of witnesses to a particular reading. <wit> contains a list of one or more sigla of witnesses attesting a given reading, in a textual variation.
  No attributes other than those globally available (see definition for a.global)
The `<wit>` list may appear following a `<rdg>`, `<rdgGrp>`, or `<lem>` element in any apparatus entry, and should be used only to transcribe the witness information in the form found in the source. The advantage of holding witness information in the `wit` attribute of `<lem>` or `<rdg>` is that this may make it more convenient for an application to check that every sigil identifier has been declared elsewhere in the document. By giving the `wit` attribute a declared value of `IDREFS`, for example, one could more easily ensure that readings are assigned only to witness sigla given as `ID` values for witnesses in a `<witList>` element (see section 19.1.4.3 The Witness List). Such checking is somewhat more difficult for witness sigla held as the content of a `<wit>` element: an application program can check them, but parsers will not. For this reason, it is recommended that encoders always hold witness information in the `wit` attribute of `<lem>` and `<rdg>`, where possible. Thus, as in the examples below, even when a reference to a witness is exactly reproduced in the `<wit>` element, the corresponding sigil for that witness can be written into the wit attribute of the matching `<rdg>` or `<lem>`. However, in cases where it is uncertain how the witness reference contained in the `<wit>` element should be interpreted, the `wit` attribute on the matching `<rdg>` or `<lem>` may be left empty.
    <lg type='stanza'>
        <l id='Diet1.1'>Sl&a-;fest du, vriedel ziere?</l>
        <l id='Diet1.2'>wan wecket uns leider schiere;</l>
        <l id='Diet1.3'>ein vogell&i-;n s&o-; wol get&a-;n</l>
        <l id='Diet1.4'>daz ist der linden an daz zw&i-; geg&a-;n.</l>
        </lg>
    <!-- ... -->
    <app type='secondary' loc='Diet.1.1'>
        <rdg wit='K Ba'>sl&a-;fst</rdg> <wit>K(Ba)</wit>
        </app>
    <app type='secondary' loc='Diet.1.2'>
        <rdg wit='K V'>Man</rdg> <wit>K(V)</wit>
        <rdg wit='K Wa'>weckt</rdg> <wit>K (Wackernagel 401)</wit>
        <rdg wit='Ju'>Ich waen ez taget uns schiere</rdg>
        <wit><bibl>Jungbluth, Festschr. Pretzel 1963, 122.</bibl></wit>
        </app>
    <!-- ... -->
    <!-- (The non-standard entities &a-; &o-; and &i-; are used   -->
    <!-- here to indicate vowels with circumflexes.)              -->
    <!-- The edition in question has two apparatus:  one of       -->
    <!-- manuscript readings, and one of readings from editions   -->
    <!-- and the secondary literature; hence the attribute        -->
    <!-- value type='secondary'.                                  -->
Of course, the sigla used for different witnesses need not be the same in the source and the `wit` attribute, as shown particularly in the apparatus for the second line of the poem (Diet.1.2). The formal declaration for `<wit>` is as follows:
    <!-- 19.1.4.2: Source-text Witness Lists in Apparatus-->
    <!ELEMENT wit %om.RO;  %paraContent;>
    <!ATTLIST wit
          %a.global;
          TEIform CDATA 'wit'  >
    <!-- end of 19.1.4.2-->
- ###### 19.1.4.3 The Witness List In the front matter of the edition, a list of all witnesses may be given if desired, in the form of a witness list, held within a `<witList>` element. This witness list must contain a series of `<witness>` elements. Each `<witness>` element may optionally contain text describing that witness in detail and must have an attibute holding as its value the sigil (siglum) or identifier for a particular witness. <witList> contains a list of all the witnesses referred to in wit elements or wit attributes within the critical apparatus.
  No attributes other than those globally available (see definition for a.global)
- <witness> contains either a description of a single witness referred to within the critical apparatus, or a list of witnesses which is to be referred to by a single sigil.
  sigil | indicates the sigil for one witness or for one group of witnesses to which readings are assigned in a critical apparatus.
  included | indicates which other witnesses are included in a witness group.
The minimal information provided by a witness list is thus the set of sigla for all the witnesses named in the apparatus. For example, a simple list of the four Chaucer manuscripts used in the examples of this chapter could appear thus:
    <witList>
       <witness sigil="El">    </witness>
       <witness sigil="Hg">    </witness>
       <witness sigil="La">    </witness>
       <witness sigil="Ra2">   </witness>
    </witList>
It is common, however, for witness lists to be somewhat more informative: each `<witness>` element may contain a prose description of the witness, or a bibliographic citation:
    <witList>
      <witness sigil="El">Ellesmere, Huntingdon Library 26.C.9</witness>
      <witness sigil="Hg">Hengwrt, National Library of Wales,
        Aberystwyth, Peniarth 392D</witness>
      <witness sigil="La">British Library Lansdowne 851</witness>
      <witness sigil="Ra2">Bodleian Library Rawlinson Poetic 149</witness>
    </witList>
In some cases, the witness list contains a whole paragraph of commentary for each witness:
    <witList>
       <witness sigil="A">die sog. <soCalled>Kleine (oder alte)
          Heidelberger Liederhandschrift</soCalled>.
          <bibl>Universit&auml;tsbibliothek Heidelberg col. pal.
          germ. 357. Pergament, 45 Fll. 18,5 &times; 13,5 cm.</bibl>
          Wahrscheinlich die &aelig;lteste der drei gro&szlig;en Hss. Sie
          <q>datiert aus dem 123. Jahrhundert, etwa um 1275. Ihre Sprache
          weist ins Elsa&szlig;, evtl. nach Stra&szlig;burg. Man geht wohl nicht
          fehl, in ihr eine Sammlung aus dem Stadtpatriziat zu sehen</q>
          (<bibl><author>Blank</author>, [vgl. <ref>Lit. z. Hss. Bd. 2,
          S. 39</ref>] S. 14</bibl>). Sie enth&aelig;lt 34 namentlich
          genannte Dichter. <q>Zu den Vorz&uuml;gen von A geh&ouml;rt, da&szlig;
          sie kaum je bewu&szlig;t ge&aelig;ndert hat, so da&szlig; sie f&uuml;r
          manche Dichter ... oft den besten Text liefert</q> (so wohl mit
          Recht <bibl><author>v. Kraus</author></bibl>).</witness>
       <witness sigil="a">Bezeichnung <bibl><author>Lachmann</author>
          </bibl>s f&uuml;r die von einer 2. Hand auf bl. 40&ndash;43
          geschriebenen Strophen der Hs. A.</witness>
       <witness sigil="B">die <soCalled>Weingartner (Stuttgarter)
          Liederhandschrift</soCalled>. <bibl>W&uuml;rttembergische
          Landesbibliothek Stuttgart, HB XIII poetae germanici 1.
          Pergament, 156 Bll. 15 &times; 11,5 cm; 25 teils ganzseitig,
          teils halbseitige Miniaturen.</bibl> Kaum vor 1306 in Konstanz
          geschrieben. Sie enth&aelig;lt Lieder von 25 namentlich genannten
          Dichtern. (Dazu kommen Gedichte von einigen ungenannten
          bzw. unbekannten Dichtern, ein Marienlobpreis und eine
          Minnelehre.)</witness>
       <!-- ... -->
    </witList>
It is common, in text-critical work, to refer to frequently occurring groups of witnesses by means of a single common sigil. Such sigla may be documented as pseudo-witnesses in their own right by including, in the witness list, a `<witness>` element giving the sigil for the group and listing the other witnesses included in the group in the value of the `included` attribute. In this example, the group of manuscripts of the Canterbury Tales which make up `Constant Group c' are themselves first allocated sigla in individual `<witness>` elements, and then those sigla are given as the `included` value of a further `<witness>` element. All the manuscripts of this group may thereafter be referred to as c:
    <witList>
       <witness sigil="Cp">Corpus Christi Oxford MS 198</witness>
       <witness sigil="La">British Library Lansdowne 851</witness>
       <witness sigil="Sl2">British Library Sloane MS 1686</witness>
       <witness sigil="c" included="Cp La Sl2">Constant Group c</witness>
    </witList>
That the reading ‘Experiment' occurs in all three manuscripts can now be indicated simply as follows:
    <rdg wit="c">Experiment</rdg>
Situations commonly arise where there are many more or less fragmentary witnesses, such that there may be quite distinct groups of witnesses for different parts of a text or collection of texts. One may treat this with distinct `<witList>` elements for each different part. Alternatively, one may have a single `<witList>` element at the beginning of the file listing all the witnesses, partial and complete, for the text, with the attestation of fragmentary witnesses indicated within the apparatus by use of the `<witStart>` and `<witEnd>` elements described in section 19.1.5 Fragmentary Witnesses. If a witness list is provided, it may be unnecessary to give, in each apparatus entry, an exhaustive list of the witnesses which agree with the base text. An application program can — in principle — compare the witnesses given for each variant found with those given in the full list of witnesses, subtracting from this list all the witnesses not active at this point (perhaps because of lacuna, or because they contain a variation on a different, overlapping lemma) and thence calculate all the manuscripts agreeing with the base text. In practice, encoders may find it less error-prone to list all witnesses explicitly in each apparatus entry. The formal declaration of `<witList>` and `<witness>` is as follows:
    <!-- 19.1.4.3: Witness Lists in Front Matter-->
    <!ELEMENT witList %om.RO; ((%m.Incl;)*, (witness, (%m.Incl;)*)+)>
    <!ATTLIST witList
          %a.global;
          TEIform CDATA 'witList'  >
    <!ELEMENT witness %om.RO; %paraContent;>
    <!ATTLIST witness
          %a.global;
          sigil CDATA #REQUIRED
          included CDATA #IMPLIED
          TEIform CDATA 'witness'  >
    <!-- end of 19.1.4.3-->
- ##### 19.1.5 Fragmentary Witnesses If a witness is incomplete (whether a single fragment, a series of fragments, or a relatively complete text with one or more lacunae), it is usually desirable to record explicitly where its preserved portions begin and end. The following empty tags, which may occur within any `<lem>` or `<rdg>` element, indicate the beginning or end of a fragmentary witness or of a lacuna within a witness: <witStart> indicates the beginning, or resumption, of the text of a fragmentary witness.
  No attributes other than those globally available (see definition for a.global)
- <witEnd> indicates the end, or suspension, of the text of a fragmentary witness.
  No attributes other than those globally available (see definition for a.global)
- <lacunaStart> indicates the beginning of a lacuna in the text of a mostly complete textual witness.
  No attributes other than those globally available (see definition for a.global)
- <lacunaEnd> indicates the end of a lacuna in a mostly complete textual witness.
  No attributes other than those globally available (see definition for a.global)
All are members of the model class fragmentary. Suppose a fragment of a manuscript X of the Wife of Bath's Prologue has a physical lacuna, and the text of the manuscript begins with ‘auctorite'. In an apparatus this might appear thus, distinguished from the reading of other manuscripts by the presence of the `<lacunaEnd>` element:
    <app>
       <lem wit="El Hg">Auctoritee</lem>
       <rdg wit="La Ra2">auctorite</rdg>
       <rdg wit="X"><lacunaEnd/>auctorite</rdg>
    </app>
In some cases, the apparatus in the source may commence recording the readings for a particular witness without its being clear whether the previous absence of readings for this witness is due to a lacuna, or to some other reason. The `<witStart>` element may be used in this circumstance:
    <app>
       <lem wit="El Hg">Auctoritee</lem>
       <rdg wit="La Ra2">auctorite</rdg>
       <rdg wit="X"><witStart/>auctorite</rdg>
    </app>
The formal declarations for these elements are these:
    <!-- 19.1.5: Fragmentary witnesses-->
    <!ELEMENT witStart %om.RO;  EMPTY>
    <!ATTLIST witStart
          %a.global;
          %a.fragmentary;
          TEIform CDATA 'witStart'  >
    <!ELEMENT witEnd %om.RO;  EMPTY>
    <!ATTLIST witEnd
          %a.global;
          %a.fragmentary;
          TEIform CDATA 'witEnd'  >
    <!ELEMENT lacunaStart %om.RO;  EMPTY>
    <!ATTLIST lacunaStart
          %a.global;
          %a.fragmentary;
          TEIform CDATA 'lacunaStart'  >
    <!ELEMENT lacunaEnd %om.RO;  EMPTY>
    <!ATTLIST lacunaEnd
          %a.global;
          %a.fragmentary;
          TEIform CDATA 'lacunaEnd'  >
    <!-- end of 19.1.5-->
- #### 19.2 Linking the Apparatus to the Text Three different methods may be used to link a critical apparatus to the text: the location-referenced method, the double-end-point-attached method, and the parallel segmentation method. Both the location-referenced and the double end-point methods may be used with either in-line or external apparatus, the former dispersed within the base text, the latter held in some separate location, within or outside the document with the base text. The parallel segmentation method does not use the concept of a base text and may only be used for in-line apparatus. Any document containing `<app>` elements requires a `<variantEncoding>` declaration in the `<editorialDecl>` element of its TEI header, thus: <variantEncoding> declares the method used to encode text-critical variants.
  method | indicates which method is used to encode the apparatus of variants.
  location | indicates whether the apparatus appears within the running text or external to it.
For examples of this element, see the following sections. The formal declaration is given in section 5.3.3 The Editorial Practices Declaration. ##### 19.2.1 The Location-referenced Method The location-referenced method of encoding apparatus provides a convenient method for encoding printed apparatus; in this method as in most printed editions, the apparatus is linked to the base text by indicating explicitly only the block of text on which there is a variant (noted usually by a canonical reference scheme, or by line number in the edition, such as `A 137` or ‘Page 15 line 1'). If the location-referenced method is used for an apparatus stored externally to the base text, the TEI header must have the declaration:
    <variantEncoding method="location-referenced" location="external"/>
In the `<body>` of the document, the base text (here El) will appear:
    <text>
      <body>
        <!-- ... -->
        <div n='WBP' type="prologue">
          <head>The Prologe of the Wyves Tale of Bathe</head>
          <l n='1'>Experience though noon Auctoritee</l>
          <l>Were in this world ...</l>
          <!-- ... -->
        </div>
      </body>
    </text>
Elsewhere in the document, or in a separate file, the apparatus will appear. On each `<app>` element, the `loc` attribute should be specified to indicate where the variant occurs in the base text.
    <app loc="WBP 1">
       <rdg wit="La">Experiment</rdg>
       <rdg wit="Ra2">Eryment</rdg>
    </app>
If the same text is encoded using in-line storage, the apparatus is dispersed through the base text block to which it refers. In this case, the location of the variant can be read from the line in which it occurs.
    <!-- in <editorialDecl> in <encodingDesc> in <teiHeader>: -->
    <variantEncoding method='location-referenced' location='internal'/>
    <!-- ... -->
    <!-- later, in <div> in <body> in <text>: -->
    <l n='1'>Experience
      <app>
        <rdg wit='La'>Experiment</rdg>
        <rdg wit='Ra2'>Eryment</rdg>
      </app>
      though noon Auctoritee</l>
    <l>Were in this world ...</l>
Since the location is not required to be exact, the apparatus for a line might also appear at the end of the line:
    <l n="1">Experience though noon Auctoritee
      <app>
        <rdg wit="La"> Experiment</rdg>
        <rdg wit="Ra2"> Eryment</rdg>
      </app></l>
    <l>Were in this world ...</l>
When the apparatus is linked to the text by means of location references, as shown here, it is not possible to find automatically the precise portion of text varied by the readings. In order to show explicitly what portion of the base text is replaced by the variant readings, the `<lem>` element may be used:
    <l n="1">Experience though noon Auctoritee
      <app>
        <lem wit="El">Experience</lem>
        <rdg wit="La">Experiment</rdg>
        <rdg wit="Ra2">Eryment</rdg>
      </app></l>
    <l>Were in this world ...</l>
Often the lemma will have no attributes, being simply the `base-text reading' and requiring no qualification, but it may optionally carry the normal attributes, as shown here. Some text critics prefer to abbreviate or elide the lemma, in order to save space or trouble; such practice is not forbidden by these Guidelines, but no recommendations are made for conventions of abbreviating the lemma, whether abbreviation of each word, or suppression of all but the first and last word, etc. Where it is intended that the apparatus be complete enough to allow the reconstruction of the witnesses (or at least of their non-orthographic variations), the location-reference method should be avoided in favor of one of the other two methods, which allow the unambiguous reconstruction of the lemma from the encoding. ##### 19.2.2 The Double End-Point Attachment Method In the double end-point attachment method, the beginning and end of the lemma in the base text are both explicitly indicated. It thus differs from the location-referenced method, in which only the larger span of text containing the lemma is indicated. Double end-point attachment permits unambiguous matching of each variant reading against its lemma. It or the parallel-segmentation method should be used in all cases where this is desired, for example where the apparatus is intended to enable full reconstruction of the text, or of the substantives, of every witness. When the double endpoint attachment method is used, the `from` and `to` attributes of the `<app>` element are used to indicate the beginning and ending points of the reading in the base text: their values are identifiers which occur at the locations in question. If no other markup is present there, the beginning and ending points should be marked using the `<anchor>` element defined in chapter 14 Linking, Segmentation, and Alignment. In cases where it is not possible to insert anchors within the base text (e.g. where the text is on a read-only medium) the beginning and end of the lemma may be indicated by using the `indirect pointing' mechanisms discussed in chapter 14 Linking, Segmentation, and Alignment. Explicit anchors are more likely to be reliable, and are therefore to be preferred. The double end-point attachment method may be used with in-line or external apparatus. In the latter case, the base text (here El) will appear with `<anchor>` elements inserted at every place where a variant begins or ends (unless some element with an identifier already begins or ends at that point):
    <TEI.2>
      <teiHeader>
        <!-- ... -->
        <variantEncoding method='double-end-point' location='external'/>
        <!-- ... -->
      </teiHeader>
      <text>
        <body>
          <!-- ... -->
          <div n='WBP' type='prologue'><head>The Prologe ... </head>
            <l n='1' id='WBP.1'>Experience<anchor id='A2'/> though noon Auctoritee</l>
            <l>Were in this world ...</l>
            <!-- ... -->
          </div> </body> </text> </TEI.2>
The apparatus will be separately encoded:
    <app from="WBP.1" to="A2">
       <rdg wit="La">Experiment</rdg>
       <rdg wit="Ra2">Eryment</rdg>
    </app>
No `<anchor>` element is needed at the beginning of the line, since the `from` attribute can use the identifier for the line as a whole; the lemma is assumed to run from the beginning of the element indicated by the `from` attribute, to the end of that indicated by the `to` attribute. If no value is given for `to`, the lemma runs from the beginning to the end of the element indicated by the `from` attribute. When the apparatus is encoded in-line, it is dispersed through the base text. Only the beginning of the lemma need be marked with an `<anchor>`, since the `<app>` is inserted at the end of the lemma, and itself therefore marks the end of the lemma.
    <!-- in <editorialDecl> in <encodingDesc> in <teiHeader>: -->
    <variantEncoding method='double-end-point' location='internal'/>
    <!-- ... -->
    <l n='1' id='WBP.1'>Experience
       <app from='WBP.1'>
          <rdg wit='La'>Experiment</rdg>
          <rdg wit='Ra2'>Eryment</rdg>
       </app>
       though noon Auctoritee</l>
    <l>Were in this world ...</l>
The lemma need not be repeated within the `<app>` element in this method, as it may be extracted reliably from the base text. If an exhaustive list of witnesses is available, it will also not be necessary to specify just which manuscripts agree with the base-text to enable reconstruction of witnesses. An application will be able to determine the manuscripts that witness the base reading, by noting which witnesses are attested as having a variant reading, and inferring the base-text reading for all others after adjusting for fragmentary witnesses and for witnesses carrying overlapping variant readings. Alternatively, if it is desired to make an explicit record of the attestation of the base text the `<lem>` element may be embedded within `<app>`, carrying the witnesses to the base. Thus
    <app from="WBP.1" to="A2">
       <lem wit="El Hg">Experience</lem>
       <rdg wit="La">Experiment</rdg>
       <rdg wit="Ra2">Eryment</rdg>
    </app>
This method is designed to cope with `overlapping lemmata'. For example, at line 117 of the Wife of Bath's Prologue, the manuscripts Hg (Hengwrt), El (Ellesmere), and Ha4 (British Library Harleian 7334) read: Hg And of so parfit wys a wight ywroght El And for what profit was a wight ywroght Ha4 And in what wise was a wight ywroght In this case, one might wish to record ‘in what wise was' in Ha4 as a single variant for ‘of so parfit wys' in Hg, and ‘was a wight' in El and H4 as a variant on ‘wys a wight' in Hg. This method can readily cope with such difficult situations, typically found in large and complex traditions:
    <l id="wbp.117" n="117"> And
      <anchor id="a117.1"/> of so parfit
      <anchor id="a117.2"/> wys
      <anchor id="a117.3"/> a wight
      <anchor id="a117.4"/> ywroght
      <app from="a117.1" to="a117.3">
        <lem wit="Hg">of so parfit wys</lem>
        <rdg wit="Ha4">in what wise was</rdg>
      </app>
      <app from="a117.2" to="a117.4">
        <lem wit="Hg">wys a wight</lem>
        <rdg wit="El Ha4">was a wight</rdg>
      </app></l>
The parallel segmentation method, to be discussed next, cannot handle overlaps among variants, and would require the individual variants to be split into pieces. Because creation and interpretation of double end-point attachment apparatus will be lengthy and difficult it is likely that they will usually be created and examined by scholars only with mechanical assistance. ##### 19.2.3 The Parallel Segmentation Method This method differs from the double end-point attachment method in that all variants at any point of the text are expressed as variants on one another. In this method, no two variations can overlap, although they may nest. Thus, the concepts of a base text and of a lemma become unnecessary: the texts compared are divided into matching segments all synchronized with one another. This permits direct comparison of any span of text in any witness with that in any other witness. It is also very easy with this method for an application to extract the full text of any one witness from the apparatus. This method will (by definition) always be satisfactory when there are just two texts for comparison (assuming they are in the same language and script). It will also be useful where editors do not wish to privilege a text as the `base' or when editors wish to present parallel texts. It will become less convenient as traditions become more complex and tension develops between the need to segment on the largest variation found and the need to express the finest detail of agreement between witnesses. In the parallel segmentation method, each segment of text on which there is variation is marked by an `<app>` element; each reading is given in a `<rdg>` element; if it is desired to single out one reading as preferred, it may be tagged `<lem>`:
    <!-- in <editorialDecl> in <encodingDesc> in <teiHeader>: -->
    <variantEncoding method='parallel-segmentation' location='internal'/>
    <!-- ... -->
      <l n='1'>
        <app><lem wit='El Hg'>Experience</lem>
             <rdg wit='La'>Experiment</rdg>
             <rdg wit='Ra2'>Eryment</rdg></app>
        though noon Auctoritee</l>
      <l>Were in this world ...</l>
This method cannot be used with external apparatus: it must be used in-line. Note that apparatus encoded with this method may be translated into the double end-point attachment method and back without loss of information. Where double-end-point-attachment encodings have no overlapping lemmata, translation of these to the parallel segmentation encoding and back will also be possible without loss of information. For economy, the witnesses to the reading most widely attested need not be stated. Since all manuscripts must be represented in all apparatus entries, it will be possible for an application to read a `<witList>` declaring all the witnesses to the text and then calculate which witnesses have not been named. In the example below, only La and Ra2 are identified explicitly with a reading; an application might successfully infer from this that ‘Experience', whose witnesses are not given, must be attested by El and Hg. To avoid confusion, however, witnesses may be omitted only for a single reading.
    <l n="1">
       <app>
          <lem>Experience</lem>
          <rdg wit="La">Experiment</rdg>
          <rdg wit="Ra2">Eryment</rdg>
       </app>
       though noon Auctoritee</l>
    <l>Were in this world ...</l>
Alternatively, the witnesses for every reading may be stated, as in the first example. As noted, apparatus entries may nest in this method: if an imaginary fifth manuscript of the text read ‘Auctoritee, though none experience', the variation on the individual words of the line would nest within that for the line as a whole:
    <l n="1">
       <app>
          <rdg wit="Chi3">Auctoritee, though none experience</rdg>
          <rdg>
             <app>
                <rdg wit="El Hg">Experience</rdg>
                <rdg wit="La">Experiment</rdg>
                <rdg wit="Ra2">Eryment</rdg>
             </app>
             <app>
                <rdg wit="El Ra2">though</rdg>
                <rdg wit="Hg">thogh</rdg>
                <rdg wit="La">thouh</rdg>
             </app>
             <app>
                <rdg wit="El Hg">noon Auctorite</rdg>
                <rdg wit="La Ra2">none auctorite</rdg>
             </app>
          </rdg>
       </app>
    </l>
Parallel segmentation cannot, however, deal very gracefully with variants which overlap without nesting: such variants must be broken up into pieces in order to keep all witnesses synchronized. #### 19.3 Using Apparatus Elements in Transcriptions It is often desirable to record different transcriptions of the one stretch of text. These variant transcriptions may be grouped within a single `<app>` element. An application may then construct different `views' of the transcription by extraction of the appropriate variant readings from the apparatus elements embedded in the transcription. For example, alternative expansions can be recorded in several different `<expan>` elements, all grouped within an `<app>` element. Consider, for example, the three different transcriptions given below of line 105 of the Hengwrt manuscript of Chaucer's The Wife of Bath's Prologue. The last word of the line ‘Virginite is grete perfection' is written ‘perfectio' followed by two minims over which a bar has been drawn, which has been read in different ways by different scholars. The first transcription, by Elizabeth Solopova, represents the two minims with bar above by reference to an entity i-i. This transcription notes this as a mark of abbreviation but gives no expansion for it. A second transcriber, F. J. Furnivall, regards the bar as an abbreviation of ‘u', reading the two minims as an ‘n'. A third transcriber, P. G. Ruggiers, regards the bar as an abbreviation of ‘n', reading the minims as ‘u'. This information may be held within an `<app>` structure, as follows:
    Virginite is grete
    <app>
      <rdg resp="ES" >perfectio<abbr>&i-i;</abbr></rdg>
      <rdg resp="FJF">perfectio<expan>u</expan>n</rdg>
      <rdg resp="PGR">perfectiou<expan>n</expan></rdg>
    </app>
This example illustrates the adaptation of the `<rdg>` element for use within the transcription of a particular witness. The `wit` attribute, which may be compulsory in recording variant readings of many witnesses within a critical apparatus, is redundant when recording variant readings relating to a single witness. However, it may be desirable to specify the editorial responsibility for a particular reading within a transcription. For all three readings, the `resp` attribute on `<rdg>` assigns this responsibility. Using this system, it will be straightforward for an application to extract from the one file the three different transcriptions done by these scholars. To do this, the application need look only at the `resp` attribute on each `<rdg>` element. Observe too that in this example the `resp` attribute is attached to the outer `<rdg>` element and is not repeated for the inner `<expan>` elements. There is no need for repetition of the `resp` attribute values, as the `<expan>` elements contained within each `<rdg>` element will inherit the value of the `resp` from the outer `<rdg>` element. Thus, the processor will know that the responsibility for the expansion `perfectioun` lies with FJF, as FJF was responsible for the reading containing this expansion. This simplifies the processing of the information, as the application has only to look at the attribute values for each reading in turn and not for those for elements nested within. Editorial notes may also be attached to `<app>` structures within transcriptions. Here, editorial preference for Ruggiers' expansion and an explanation of that preference is given:
    Virginite is grete
    <app>
      <rdg           resp="ES" >perfecti<abbr>o&i-i;</abbr></rdg>
      <rdg id="f105" resp="FJF">perfectio<expan>u</expan>n</rdg>
      <rdg id="r105" resp="PGR">perfectiou<expan>n</expan></rdg>
    </app>
    <!-- ... <note> appearing elsewhere in the document ... -->
    <note target="r105 f105">Furnivall's expansion implies that the bar
      is an abbreviation for 'u'. There are no certain instances of
      this mark as an abbreviation for 'u' in these MSS and it is
      widely used as an abbreviation for 'n'. Ruggiers' expansion is to
      be accepted.</note>
In most cases, elements used to indicate features of a primary textual source may be represented within an `<app>` structure simply by nesting them within its readings, just as the `<abbr>` and `<expan>` elements are nested within the `<rdg>` elements in the example just given. However, in cases where the tagged feature extends across a span of text which might itself contain variant readings which it is desired to represent by `<app>` structures, some adaptation of the tagging may be necessary. For example, a span of text may be marked in the transcription of the primary source as a single deletion but it may be desirable to represent just a few words from this source as individual deletions within the context of a critical apparatus drawing together readings from this and several other witnesses. In this case, the tagging of the span of words as one deletion may need to be decomposed into a series of one-word deletions for encoding within the apparatus. If it is important to record the fact that all were deleted by the same act, the markup may use the `<join>` element or the `next` and `prev` attributes defined by chapter 14 Linking, Segmentation, and Alignment.

Up: Contents Previous: 18 Transcription of Primary Sources Next: 20 Names and Dates