# DHARMA Encoding Guide for Critical Editions

Arlo Griffiths, Axelle Janiak

► To cite this version:

Arlo Griffiths, Axelle Janiak. DHARMA Encoding Guide for Critical Editions. EFEO - École française d'Extrême-Orient; CASE - Centre Asie du Sud-Est; CESAH - Centre d'études sud asiatiques et himalayennes. 2023. hal-04085137

HAL Id: hal-04085137

https://hal.science/hal-04085137

Submitted on 28 Apr 2023

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
Encoding Guide
for Critical Editions

<figure><img src="image_2.png" /></figure>

dharma

Release Version 1, 2023

Arlo Griffiths & Axelle Janiak
Version History

<table><thead><tr><td>Author(s), Contributor(s)</td><td>Version</td><td>Changes</td><td>Date</td></tr></thead><tbody><tr><td>Arlo Griffiths, Giulia Buriola, Axelle Janiak</td><td>0.1</td><td>Redaction of the first version</td><td>2020-2023</td></tr><tr><td>Arlo Griffiths, Axelle Janiak</td><td>1</td><td>Release of first version</td><td>2023</td></tr></tbody></table>

The DHARMA project has received funding from the European Research Council (ERC) under the European Union's Horizon 2020 research and innovation programme (grant agreement no. 809994).
Table of Content

<table><tr><td>Table of Content</td><td>2</td></tr><tr><td>Preliminaries</td><td>8</td></tr><tr><td>Acknowledgments</td><td>10</td></tr><tr><td>1. Structure of a DHARMA Critical Edition</td><td>10</td></tr><tr><td>2. &lt;teiHeader&gt; — Recording Metadata</td><td>13</td></tr><tr><td>2.1 &lt;fileDesc&gt; — Describing the XML file</td><td>13</td></tr><tr><td>2.1.1 &lt;titleStmt&gt; — Titles and people involved</td><td>13</td></tr><tr><td>2.1.1.1 &lt;title&gt; and &lt;author&gt; — Declaring the title of the work and the name of its author</td><td>13</td></tr><tr><td>2.1.1.2 &lt;editor&gt; and &lt;respStmt&gt; — Identifying scholarly responsibilities</td><td>15</td></tr><tr><td>2.1.2 &lt;publicationStmt&gt; — Metadata on the digital publication</td><td>17</td></tr><tr><td>2.1.3 &lt;sourceDesc&gt; — Identifying and describing your sources</td><td>18</td></tr><tr><td>2.1.3.1 Declaring an individual witness</td><td>18</td></tr><tr><td>2.1.3.2 Declaring a family of witnesses</td><td>20</td></tr><tr><td>2.1.3.3 Declaring an archetype or a hyparchetype</td><td>21</td></tr><tr><td>2.1.3.4 Describing witnesses</td><td>24</td></tr><tr><td>2.1.3.5 &lt;handDesc&gt; — Encoding the hand(s) with its/their script(s)</td><td>31</td></tr><tr><td>2.1.4 Shortcut for citing sigla and hands</td><td>33</td></tr><tr><td>2.2 &lt;encodingDesc&gt; — Documenting your work</td><td>33</td></tr><tr><td>2.2.1 &lt;projectDesc&gt; — Describing the project</td><td>34</td></tr><tr><td>2.2.1.1 &lt;editorialDecl&gt; — Recording specificities of your own work</td><td>35</td></tr><tr><td>2.2.1.2 &lt;samplingDecl&gt; — Explaining the sources chosen for your edition</td><td>36</td></tr><tr><td>2.2.1.3 &lt;schemaRef&gt; — Declaring the schema</td><td>36</td></tr><tr><td>2.2.1.4 &lt;variantEncoding&gt; — Declaring the method used for building your apparatus</td><td>37</td></tr><tr><td>2.2.2 &lt;profileDesc&gt; — Providing descriptive elements</td><td>37</td></tr><tr><td>2.2.3 &lt;revisionDesc&gt; — Keeping track of file History</td><td>38</td></tr><tr><td>3. Text</td><td>39</td></tr><tr><td>3.1 &lt;text&gt; — Structuring the text</td><td>39</td></tr><tr><td>3.2 &lt;div&gt; — Sections of text</td><td>40</td></tr><tr><td>3.2.1 &lt;head&gt; — Section titles</td><td>41</td></tr><tr><td>3.2.2 Declaring prosody for a canto</td><td>42</td></tr><tr><td>3.2.3 Identifying prosodic groups</td><td>43</td></tr><tr><td>3.3 Prose Containers</td><td>44</td></tr><tr><td>3.3.1 &lt;p&gt; — Paragraphs</td><td>44</td></tr></table>
<table>
  <tbody>
    <tr>
      <td>3.3.2 &lt;ab&gt; – Anonymous blocks</td>
      <td>44</td>
    </tr>
    <tr>
      <td>3.3.2.1 Invocations and colophons</td>
      <td>45</td>
    </tr>
    <tr>
      <td>3.3.2.2 Speaker indications</td>
      <td>46</td>
    </tr>
    <tr>
      <td>3.4 Verse Containers</td>
      <td>46</td>
    </tr>
    <tr>
      <td>3.4.1 &lt;lg&gt; – stanzas</td>
      <td>47</td>
    </tr>
    <tr>
      <td>3.4.2 @met – metrical patterns</td>
      <td>48</td>
    </tr>
    <tr>
      <td>3.4.3 &lt;I&gt; – metrical lines</td>
      <td>48</td>
    </tr>
    <tr>
      <td>3.4.4 @real – deviant metrical patterns</td>
      <td>49</td>
    </tr>
    <tr>
      <td>3.4.5 @enjamb – enjambment</td>
      <td>49</td>
    </tr>
    <tr>
      <td>3.5 Spoken Text</td>
      <td>51</td>
    </tr>
    <tr>
      <td>3.5.1 Dramatic elements</td>
      <td>51</td>
    </tr>
    <tr>
      <td>3.5.2 Direct speech</td>
      <td>51</td>
    </tr>
    <tr>
      <td>3.5.3 Dialogue</td>
      <td>52</td>
    </tr>
    <tr>
      <td>3.6 Mixed prose and verse</td>
      <td>52</td>
    </tr>
    <tr>
      <td>3.7 Quotation made by author of the text being edited</td>
      <td>53</td>
    </tr>
    <tr>
      <td>3.8 Numbering the text units of the edition</td>
      <td>53</td>
    </tr>
    <tr>
      <td><b>4. Base text and dependent text</b></td>
      <td><b>54</b></td>
    </tr>
    <tr>
      <td>4.1 Base text embedded in dependent text</td>
      <td>55</td>
    </tr>
    <tr>
      <td>4.2 Several sections of base text for one section of dependent text</td>
      <td>56</td>
    </tr>
    <tr>
      <td>4.3 Base text absent in dependent text</td>
      <td>57</td>
    </tr>
    <tr>
      <td>4.4 Encoding base text ignored in the dependent text</td>
      <td>58</td>
    </tr>
    <tr>
      <td>4.5 Dependent text without base text</td>
      <td>61</td>
    </tr>
    <tr>
      <td>4.6 Dependent text implies base text that is unknown</td>
      <td>62</td>
    </tr>
    <tr>
      <td>4.7 Base text reconstructible from dependent text</td>
      <td>62</td>
    </tr>
    <tr>
      <td>4.7.1 Prose interrupted by dependent prose</td>
      <td>63</td>
    </tr>
    <tr>
      <td>4.7.2 Stanzas interrupted by dependent prose</td>
      <td>64</td>
    </tr>
    <tr>
      <td>4.8 Lemmas of base text in dependent text</td>
      <td>67</td>
    </tr>
    <tr>
      <td><b>5. Critical apparatus</b></td>
      <td><b>67</b></td>
    </tr>
    <tr>
      <td>5.1 Structural overview</td>
      <td>68</td>
    </tr>
    <tr>
      <td>5.2 Which variant readings to record and which to ignore</td>
      <td>71</td>
    </tr>
    <tr>
      <td>5.2.1 Recording variant readings positively</td>
      <td>71</td>
    </tr>
    <tr>
      <td>5.2.2 Ignoring insignificant variant readings</td>
      <td>71</td>
    </tr>
    <tr>
      <td>5.2.3 Hiding insignificant variants readings without deleting them</td>
      <td>72</td>
    </tr>
    <tr>
      <td>5.2.4 Strategies to encode apparatus entries across block boundaries</td>
      <td>73</td>
    </tr>
    <tr>
      <td>5.3 The lemma</td>
      <td>73</td>
    </tr>
    <tr>
      <td>5.3.1 Extent of the lemma</td>
      <td>74</td>
    </tr>
    <tr>
      <td>5.3.1.1 Ellipsis in the lemma's display</td>
      <td>74</td>
    </tr>
    <tr>
      <td>5.3.1.2 Truncation</td>
      <td>76</td>
    </tr>
    <tr>
      <td>5.3.2 @type values usable with &lt;lem&gt;</td>
      <td>77</td>
    </tr>
  </tbody>
</table>
<table>
  <tbody>
    <tr>
      <td>5.4 Recording witnesses</td>
      <td>78</td>
    </tr>
    <tr>
      <td>5.5 Variant readings</td>
      <td>79</td>
    </tr>
    <tr>
      <td>5.5.1 Quote witnesses as diplomatically as possible</td>
      <td>79</td>
    </tr>
    <tr>
      <td>5.5.2 Highlighting segments affected by variation</td>
      <td>80</td>
    </tr>
    <tr>
      <td>5.5.3 Encoding causes of variance of reading</td>
      <td>80</td>
    </tr>
    <tr>
      <td>5.5.4. Grouping variant readings</td>
      <td>81</td>
    </tr>
    <tr>
      <td>5.5.5 Encoding readings ante and post correctionem</td>
      <td>82</td>
    </tr>
    <tr>
      <td>5.5.6 Encoding a rejected branch of transmission</td>
      <td>84</td>
    </tr>
    <tr>
      <td>5.5.6.1 Adopting the formulation from one branch but a reading from another</td>
      <td>85</td>
    </tr>
    <tr>
      <td>5.5.6.2 Adopting the formulation from one branch but a reading from another across boundaries</td>
      <td>86</td>
    </tr>
    <tr>
      <td>5.5.6.3 Encoding the intended reading of a rejected branch of transmission</td>
      <td>87</td>
    </tr>
    <tr>
      <td>5.5.7 Encoding (segments of) a reading as unclear</td>
      <td>88</td>
    </tr>
    <tr>
      <td>5.5.8 Encoding (segments of) a reading as illegible</td>
      <td>89</td>
    </tr>
    <tr>
      <td>5.5.9 Text of lemma absent from a witness due to scribal omission</td>
      <td>90</td>
    </tr>
    <tr>
      <td>5.5.10 Text of lemma absent from a witness due to physical deficiency</td>
      <td>92</td>
    </tr>
    <tr>
      <td>5.5.10.1 Text absent from a witness due to physical deficiency but with known meter</td>
      <td>93</td>
    </tr>
    <tr>
      <td>5.5.11 Absence of a witness for a lemma due to larger physical lacuna</td>
      <td>94</td>
    </tr>
    <tr>
      <td>5.5.11.1 Textual loss within a block-level container</td>
      <td>94</td>
    </tr>
    <tr>
      <td>5.5.11.2 Textual loss across boundaries between block-level containers</td>
      <td>95</td>
    </tr>
    <tr>
      <td>5.5.12 Absence of a witness for a lemma due to larger scribal omission</td>
      <td>96</td>
    </tr>
    <tr>
      <td>5.5.12.1 Textual loss within a block-level container</td>
      <td>96</td>
    </tr>
    <tr>
      <td>5.5.12.2 Textual loss across boundaries between block-level containers</td>
      <td>97</td>
    </tr>
    <tr>
      <td>5.5.13 Reporting scribal additions and deletions</td>
      <td>99</td>
    </tr>
    <tr>
      <td>5.5.13.1 &lt;add&gt; – Additions</td>
      <td>99</td>
    </tr>
    <tr>
      <td>5.5.13.2 &lt;del&gt; – Deletions</td>
      <td>100</td>
    </tr>
    <tr>
      <td>5.5.13.3 Combining additions and deletions</td>
      <td>102</td>
    </tr>
    <tr>
      <td>5.6 Reporting extraneous text segments (interpolations)</td>
      <td>102</td>
    </tr>
    <tr>
      <td>5.6.1 Extraneous text block with @type="interpolation"</td>
      <td>103</td>
    </tr>
    <tr>
      <td>5.6.2 Extraneous text in &lt;rdg&gt; (optionally with &lt;seg type="interpolation"&gt;)</td>
      <td>103</td>
    </tr>
    <tr>
      <td>5.6.3 &lt;surplus&gt; – identifying small segments of extraneous text</td>
      <td>104</td>
    </tr>
    <tr>
      <td>5.6.4 &lt;secl&gt; – misplaced text segments</td>
      <td>105</td>
    </tr>
    <tr>
      <td>5.7 Supplying untransmitted text or indicating your inability to supply lost text</td>
      <td>105</td>
    </tr>
    <tr>
      <td>5.7.1 Reporting a locus of suspected textual loss</td>
      <td>107</td>
    </tr>
    <tr>
      <td>5.7.2 Marking up lacunae with known meter</td>
      <td>107</td>
    </tr>
    <tr>
      <td>5.8 Encoding transposition of text</td>
      <td>108</td>
    </tr>
    <tr>
      <td>5.8.1 Transposition of text segments within a single block</td>
      <td>108</td>
    </tr>
    <tr>
      <td>5.8.2 Transposition through physical displacement</td>
      <td>109</td>
    </tr>
  </tbody>
</table>
<table>
  <tbody>
    <tr>
      <td>5.8.3 Transposition of the lines of a stanza</td>
      <td>109</td>
    </tr>
    <tr>
      <td>5.8.4 Discontinuous transposition</td>
      <td>111</td>
    </tr>
    <tr>
      <td>5.9 Marking an irreparably corrupt segment as crux</td>
      <td>114</td>
    </tr>
    <tr>
      <td>5.10 Annotations in apparatus</td>
      <td>115</td>
    </tr>
    <tr>
      <td>5.10.1 &lt;note&gt; - Apparatus Notes</td>
      <td>115</td>
    </tr>
    <tr>
      <td>5.10.2 &lt;witDetail&gt; - Witnesses Notes</td>
      <td>115</td>
    </tr>
    <tr>
      <td><b>6. Editorial material applied to entire blocks of text</b></td>
      <td><b>116</b></td>
    </tr>
    <tr>
      <td>6.1 Text critical notes</td>
      <td>116</td>
    </tr>
    <tr>
      <td>6.2 Parallel passages: quotations, testimonia, etc.</td>
      <td>117</td>
    </tr>
    <tr>
      <td>6.2.1 Associating a known parallel to a whole block of text</td>
      <td>117</td>
    </tr>
    <tr>
      <td>6.2.2 &lt;note&gt; — Empty or with Contents</td>
      <td>120</td>
    </tr>
    <tr>
      <td>6.2.3 &lt;note&gt; — Attributes</td>
      <td>123</td>
    </tr>
    <tr>
      <td>6.2.3.1 @sameAs and @copyOf — Declaring an identical parallel passage</td>
      <td>123</td>
    </tr>
    <tr>
      <td>6.2.3.2 @corresp — Declaring a non-identical parallel text</td>
      <td>124</td>
    </tr>
    <tr>
      <td>6.2.4 Associating a parallel to a segment of a stanza or paragraph</td>
      <td>124</td>
    </tr>
    <tr>
      <td>6.2.4.1 Declaring a parallel for a segment within a text block</td>
      <td>124</td>
    </tr>
    <tr>
      <td>6.2.4.2 Declaring a segment of text using &lt;anchor&gt;</td>
      <td>125</td>
    </tr>
    <tr>
      <td>6.2.5 Associating parallel texts that are implied but unknown</td>
      <td>126</td>
    </tr>
    <tr>
      <td>6.3 Encoding an external apparatus stanza-by-stanza</td>
      <td>126</td>
    </tr>
    <tr>
      <td><b>7. Referencing and cross-referencing</b></td>
      <td><b>128</b></td>
    </tr>
    <tr>
      <td>7.1 Links based on prefixes</td>
      <td>128</td>
    </tr>
    <tr>
      <td>7.1.1 part: — Referring to other DHARMA team members</td>
      <td>128</td>
    </tr>
    <tr>
      <td>7.1.2 bib: — Referring to items in the DHARMA Zotero Group Library</td>
      <td>129</td>
    </tr>
    <tr>
      <td>7.1.3 txt: — Referring to editions of other texts</td>
      <td>129</td>
    </tr>
    <tr>
      <td>7.1.3.1 Entries in the txt: authority file</td>
      <td>129</td>
    </tr>
    <tr>
      <td>7.1.3.2 Quoting entries from the txt: authority file</td>
      <td>131</td>
    </tr>
    <tr>
      <td>7.1.3.3 Shortcuts for citing texts</td>
      <td>133</td>
    </tr>
    <tr>
      <td>7.1.3.4 Automatic retrieval?</td>
      <td>134</td>
    </tr>
    <tr>
      <td>7.2 Other links</td>
      <td>134</td>
    </tr>
    <tr>
      <td>7.2.1 Making links inside your edition using identifiers</td>
      <td>134</td>
    </tr>
    <tr>
      <td>7.2.1.1 Identifying patterns for block-level containers</td>
      <td>134</td>
    </tr>
    <tr>
      <td>7.2.1.2 Identifying patterns for other containing elements</td>
      <td>135</td>
    </tr>
    <tr>
      <td>7.2.1.3 File internal links</td>
      <td>136</td>
    </tr>
    <tr>
      <td>7.2.1.4 Shortcuts for citing a part of the edition</td>
      <td>136</td>
    </tr>
    <tr>
      <td>7.2.2 Making links with resources outside the edition</td>
      <td>136</td>
    </tr>
    <tr>
      <td>7.2.2.1 Create a link between two DHARMA editions</td>
      <td>136</td>
    </tr>
    <tr>
      <td>7.2.2.2 Making a hyperlink</td>
      <td>137</td>
    </tr>
    <tr>
      <td><b>8. Encoding additional information in the edition</b></td>
      <td><b>137</b></td>
    </tr>
    <tr>
      <td>8.1 Milestone elements: pages, folios and lines</td>
      <td>137</td>
    </tr>
  </tbody>
</table>
<table>
  <tbody>
    <tr>
      <td>8.1.1 Lines and pages for printed editions</td>
      <td>138</td>
    </tr>
    <tr>
      <td>8.1.2 Folios</td>
      <td>138</td>
    </tr>
    <tr>
      <td>8.2 Notes</td>
      <td>139</td>
    </tr>
    <tr>
      <td>8.3 Quotations</td>
      <td>140</td>
    </tr>
    <tr>
      <td>8.3.1 &lt;cit&gt; and &lt;quote&gt; – Cited Quotation</td>
      <td>140</td>
    </tr>
    <tr>
      <td>8.3.2 &lt;q&gt; – Quoted Material</td>
      <td>141</td>
    </tr>
    <tr>
      <td>8.4 Bibliographic References</td>
      <td>141</td>
    </tr>
    <tr>
      <td>8.4.1 Bibliographic citations with Zotero</td>
      <td>141</td>
    </tr>
    <tr>
      <td>8.4.2 &lt;title&gt; – Encoding titles</td>
      <td>143</td>
    </tr>
    <tr>
      <td>8.5 @resp – Attributing responsibility</td>
      <td>144</td>
    </tr>
    <tr>
      <td>8.6 Encoding diplomatic features</td>
      <td>144</td>
    </tr>
    <tr>
      <td>8.7 Encoding indexables</td>
      <td>144</td>
    </tr>
    <tr>
      <td>8.8 About formatting</td>
      <td>145</td>
    </tr>
    <tr>
      <td>8.8.1 &lt;hi&gt; – Typographical formatting</td>
      <td>145</td>
    </tr>
    <tr>
      <td>8.8.2 &lt;list&gt; – Encoding lists</td>
      <td>145</td>
    </tr>
    <tr>
      <td>8.9 Marking metri causa spellings or word forms</td>
      <td>146</td>
    </tr>
    <tr>
      <td>8.10 About languages</td>
      <td>146</td>
    </tr>
    <tr>
      <td>8.10.1 @xml:lang – identifying languages</td>
      <td>146</td>
    </tr>
    <tr>
      <td>8.10.2 Tagging text segments in another language</td>
      <td>147</td>
    </tr>
    <tr>
      <td>8.11 Validation and review process</td>
      <td>148</td>
    </tr>
    <tr>
      <td><b>9. Encoding translations</b></td>
      <td><b>149</b></td>
    </tr>
    <tr>
      <td>9.1 &lt;teiHeader&gt; for translations</td>
      <td>149</td>
    </tr>
    <tr>
      <td>9.2 Structuring the translation</td>
      <td>151</td>
    </tr>
    <tr>
      <td>9.2.1 &lt;text&gt; and &lt;body&gt; elements</td>
      <td>151</td>
    </tr>
    <tr>
      <td>9.2.2 &lt;div&gt; – Sections of translations</td>
      <td>151</td>
    </tr>
    <tr>
      <td>9.2.3 Structural organization of the translation</td>
      <td>152</td>
    </tr>
    <tr>
      <td>9.3 Identifying correspondence with editions</td>
      <td>152</td>
    </tr>
    <tr>
      <td>9.3.1 Parallelism with the edited text</td>
      <td>152</td>
    </tr>
    <tr>
      <td>9.3.2 Declaring the authorship of on a translated segment of text</td>
      <td>153</td>
    </tr>
    <tr>
      <td>9.4 Markup available with a &lt;p&gt; of translation</td>
      <td>153</td>
    </tr>
    <tr>
      <td>9.4.1 Additions into the translated text</td>
      <td>153</td>
    </tr>
    <tr>
      <td>9.4.2 Lacunae</td>
      <td>154</td>
    </tr>
    <tr>
      <td>9.4.3 Expressing doubts and flagging problems</td>
      <td>154</td>
    </tr>
    <tr>
      <td>9.4.4 Indicating bitextuality</td>
      <td>154</td>
    </tr>
    <tr>
      <td>9.4.5 Providing notes</td>
      <td>155</td>
    </tr>
    <tr>
      <td><b>10. Encoding published books</b></td>
      <td><b>155</b></td>
    </tr>
    <tr>
      <td>10.1 &lt;front&gt; – Front Matter</td>
      <td>155</td>
    </tr>
    <tr>
      <td>10.2 &lt;back&gt; – Back Matter</td>
      <td>156</td>
    </tr>
    <tr>
      <td><b>Appendix A: Editorial Conventions</b></td>
      <td><b>157</b></td>
    </tr>
  </tbody>
</table>
<table><tr><td>1. How to represent punctuation?</td><td>157</td></tr><tr><td>2. Spelling normalization in editing Indonesian texts</td><td>157</td></tr><tr><td>3. Variant readings deemed insignificant in Indonesian texts</td><td>158</td></tr><tr><td><strong>Appendix B: Language Codes</strong></td><td><strong>160</strong></td></tr></table>
# Preliminaries

This guide is primarily intended for use by scholars who are preparing a *digital* critical edition of a so-far unedited text.<fnref n="1" /> The encoding strategies offered here also attempt to take into account the situation where a new edition of a previously edited text is envisaged, and will in most cases even be applicable for encoding a published critical (or even a not-so-critical) edition. However, this Guide is explicitly not intended for diplomatic editions based on single manuscripts. The method to be deployed for editing texts, especially texts written in vernacular languages, based on a *codex unicus* — whether to maintain two separate files with diplomatic/unnormalized text in one, and critical/normalized text in another, or both combined in one file — is a matter of case-by-case appreciation and something that needs to be experimented with more than we have so far had the time to do. For the time being, we only have experience with keeping the diplomatic edition of a *codex unicus* separate from that of the critical edition based on it.

We assume that the purpose of a critical edition is to transcend the state of a given text as transmitted to us in available manuscripts and to give readers access to an earlier state of the text, from which the extant transmission derives.<fnref n="2" /> To evoke the useful distinction made by G. Thomas Tanselle in his beautiful essay *A Rationale for Textual Criticism*,<fnref n="3" /> a critical edition is thus a hypothesis concerning the text of a work in the abstract, while a diplomatic edition aims to present the text of a concrete document.

The DHARMA project is never concerned with texts accessible in autograph manuscripts, and always with texts that have been transmitted over centuries of copying from one manuscript to the other, even though only a single witness may survive. The manuscripts we have are always characterized by some degree of difference from the text as it was intended to be read at the time of composition. The task of the critical editor is to present as much evidence as is necessary for establishing a scholarly hypothesis as to the text of the work being edited — and to reduce the volume of the evidence presented as much as possible. It is necessary to sift between evidence that is pertinent and evidence that is only a distraction. This Guide aims to enable you to present the edition of the text and the evidence on which your

<footnote n="1">¹ We will not dwell here on the reasons why a scholar might prefer to edit a text digitally. On this subject, see Roberto Alessi & Marcello Vitali-Rosati (eds.), *Les éditions critiques numériques*, Montréal: Presses de l'Université de Montréal, https://pum.umontreal.ca/catalogue/les_editions_critiques_numériques, 2023. In specific relationship to Sanskrit philology and related fields, we may refer to Birgit Kellner, "On Editing Sanskrit Texts Digitally – Tools, Methods and Implications", in *Sanskrit Manuscripts in China III: Proceedings of a Panel at the 2016 Beijing International Seminar on Tibetan Studies*, August 1 to 4, edited by Birgit Kellner, Xuezhu Li, and Jowita Kramer, 93–106, Beijing: China Tibetology Publishing House, 2020.
(https://www.oew.ac.at/ikga/publikationen/sachgebiete/tibetologie/sanskrit-manuscripts-in-china-iii)</footnote>

<footnote n="2">² The reconstructive aims that underlie critical editions vary from case to case. For instance, the aim may be to reconstruct the text of the work as written by its author, the text of the work as it was known by a given commentator, the state of the text that the witnesses allow to reconstruct, etc.</footnote>

<footnote n="3">³ Tanselle, G. Thomas. 1989. *A Rationale of Textual Criticism*. University of Pennsylvania Press. https://www.jstor.org/stable/j.ctt3fhcwk.</footnote>
choices of reading are based, while also furnishing suggestions that may help you to reduce the volume of the evidence by weeding out what is not essential.

Because the aim of the critical edition is to facilitate access to the abstract content of the text of the work in question, and because trivial orthographic variation, that potentially distracts from accessing the intellectual contents, is inherent in all manuscript traditions with which we are concerned, just as it must have been even in any hypothetical autograph manuscripts now lost to us, your critical edition is expected to make use of **loose transliteration** (or **transcription**) as intended in the *DHARMA Transliteration Guide*.

Digital editions of the DHARMA project will be represented in XML files and comply with the encoding standards of the Text Encoding Initiative (TEI).<fnref n="4" /> The TEI guidelines offer a very broad range of options for how to encode the kinds of information that the scholar making a critical edition needs to represent. The present *DHARMA Encoding Guidelines for Critical Editions* documents the choices made by the DHARMA project from among these options.<fnref n="5" /> It is in some cases a specialization of the *DHARMA Encoding Guide for Diplomatic Editions* written by Dániel Balogh & Arlo Griffiths and in some others a complement to it. For this reason, some parts of the present document will be referring to this first guide. Other guides created and curated for the specific needs of the DHARMA project will also be referred to. Some of the recurring ones have been given an abbreviated form that you can find in the following list with the link to the latest release.

EGC DHARMA Encoding Guide for Critical Editions

EGD [DHARMA Encoding Guide for Diplomatic Editions](#)

FNC [DHARMA Files Naming Conventions](#)

PVG [DHARMA Prosody and Verse Forms Guide](#)

STS [DHARMA Symbol Taxonomy Supplement](#)

TG [DHARMA Transliteration Guide](#)

ZG [DHARMA Zotero Guide](#)

To conclude these preliminaries, we wish to explain that the DHARMA project treats readings from manuscripts and published editions on equal footing. This position, which may appear counterintuitive to some, is based on both theoretical and practical considerations. Theoretically, it seems problematic to make a distinction between the two types of sources because premodern scribes often worked in a manner analogous to modern-age editors, basing a new copy on the consultation of multiple available manuscripts. Practically, it is in many situations

<footnote n="4">⁴ For a very easy introduction, we recommend Lou Burnard's *What Is the Text Encoding Initiative? How to Add Intelligent Markup to Digital Resources*, OpenEdition, 2014, https://doi.org/10.4000/books.oep.426, 2014.</footnote>

<footnote n="5">⁵ In making our choices, we have made use of the following guides in ascending order of frequency:
* <https://digitallatin.github.io/guidelines/LDLT-Guidelines.html>
* <https://www.digitalmanuscripts.eu/wp-content/uploads/2017/09/04-Textual-variants-MB.pdf>
* <https://betamasaheft.eu/Guidelines>
* <https://sarit.indology.info/sarit-pm/docs/encoding-guidelines-simple.html>
* <https://sarit.indology.info/sarit-pm/docs/encoding-guidelines-full.html>
* <https://pta.bbw.de/pta/project/encoding-guidelines#building-a-digital-edition-according-to-tei></footnote>
impossible to make a distinction, because many published editions give no information about
the manuscripts consulted, and even if they do, the manuscripts used by previous editors will
often not be available to us, making it impossible for us to distinguish between cases where an
editor accurately read his manuscript(s) and those where he misread them. This problem is
further aggravated by the fact that many editors have not even attempted to indicate in which
manuscripts the readings they adopted were observed, and indeed whether they observed them
in any manuscript at all, or whether they consciously resorted to alteration of the transmitted
text. We have no choice but to take the editor's readings as what they are: readings reflecting
the editor's idea about how the text was formulated. The concrete implication of this position is
that both manuscripts and printed editions will be declared as witnesses (<witness>) in the
metadata section (<teiHeader>) of each file, where relevant in interaction with bibliographic data
stored in the project's Zotero Group Library.<fnref n="6" />

Acknowledgments

This Guide is the product of three years of often intensive collaboration between the authors, in
interaction with a group of scholars each involved, to some degree, in digitally editing texts from
premodern India or Indonesia, some of them on the basis of the guidelines formulated here. We
would like to express our thanks to Aditia Gunawan, Giulia Buriola (who has written drafts of a
number of paragraphs included here), Martina Dello Buono, Dominic Goodall, Csaba Kiss,
Andrew Ollett, Marine Schoettel, Amandine Wattelier-Bricout (who has furnished contents for
one section) and Zakariya Pamuji Aminullah.

1. Structure of a DHARMA Critical Edition

The contents of DHARMA critical editions will be encoded in several files: the main file contains
the edition itself, while translations form a secondary set of files linked to the first one. The main
sections of this guide concern the edition, but you can nonetheless find information on how to
deal with metadata and translations, respectively under §2. <teiHeader> — Recording Metadata
and §9. Translation.

Templates for these files are provided in the project-documentation repository of the
DHARMA project.<fnref n="7" /> All of them have a <TEI> element as root with the TEI namespace declared
with @xmlns="http://www.tei-c.org/ns/1.0" as well as the default declaration of language set to
English with @xml:lang="eng". You first need to add an @xml:id for the edition file. An @xml:id
provides a unique identifier for the element bearing the attribute, and it may contain only
alphanumeric characters from the ASCII tables. Moreover, @xml:id are case-sensitive:
uppercase and lowercase letters are distinguished. Then, add an attribute @corresp link to this
identifier on other files and prefix it with "#", to establish the correspondence between the files

<footnote n="6">⁶ For the latest release of the ZG, check the GitHub project-documentation github repository.</footnote>

<footnote n="7">⁷ Currently, two templates in their first version are available in the templates folder, under
CriticalEditions-mss.</footnote>
you want to link together. Finally, provide an attribute @type with the value "edition" or "translation" on this root.

Example 1.A

```xml
<TEI
    xmlns="http://www.tei-c.org/ns/1.0"
    xml:id="svayambhu" xml:lang="eng" type="edition">
```

```xml
<TEI xmlns="http://www.tei-c.org/ns/1.0" xml:lang="eng"
      type="translation" corresp="#svayambhu">
```

Most of this content and preceding elements like the XML declaration and the processing instructions will be given in the templates and you won't have to fill them in. However, please note that the first one should always be formed with the attributes @version="1.0" and @encoding="UTF-8". This part of the will remain stable, unlike the processing instructions containing the URI of the validation schema.<fnref n="8" />

The following example is a shortened version of the general structure of any edition file. More information is provided all through the present guide.

Example 1.B

```xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="https://raw.githubusercontent.com/erc-dharma/project-documentation/master/schema/latest/DHARMA_CritE dSchema.rng" schematypens="http://relaxng.org/ns/structure/1.0"?>
<?xml-model href="https://raw.githubusercontent.com/erc-dharma/project-documentation/master/schema/latest/DHARMA_CritE dSchema.rng" schematypens="http://purl.oclc.org/dsdl/schematron"?>
<?xml-model href="https://raw.githubusercontent.com/erc-dharma/project-documentation/master/schema/latest/DHARMA_CritE dSQF.sch" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?>
<TEI xmlns="http://www.tei-c.org/ns/1.0" xml:lang="eng" xml:id="id" type="edition">
<teiHeader>
<fileDesc>
<titleStmt>
<caption type="main">Encoding Template for Critical Editions</caption>
<caption type="sub">Digital Critical Edition of...</caption>
<editor ref="part:jodo">
<forename>John</forename>
<surname>Doe</surname>
</editor>
<respStmt>
<resp>creation of the file</resp>
<persName ref="part:jodo">
<forename>John</forename>
<surname>Doe</surname>
</persName>
</teiHeader>
```

<footnote n="8">⁸ Critical editions are validated with one RelaxNg file containing embedded schematron rules and one schematron file with some Quick Fixes for the most common cases.</footnote>
```xml
</respStmt>
</titleStmt>
<publicationStmt>
<authority>DHARMA</authority>
<pubPlace>Paris</pubPlace>
<idno type="filename">DHARMA_templateCriticalEdition_v01</idno>
<availability>
<licence target="https://creativecommons.org/licenses/by/4.0/">
<p>This work is licenced under the Creative Commons Attribution 4.0 Unported Licence. To view a
copy of the licence, visit https://creativecommons.org/licenses/by/4.0/ or send a letter to Creative Commons, 444
Castro Street, Suite 900, Mountain View, California, 94041, USA.</p>
<p>Copyright (c) 2019-2025 by John Doe.</p>
</licence>
</availability>
<date from="2019" to="2025">2019-2025</date>
</publicationStmt>
<sourceDesc>
<listWit>
<witness xml:id="id">
 <!-- Elements about a witness -->
</witness>
</listWit>
</sourceDesc>
</fileDesc>
<encodingDesc>
<projectDesc>
<p>This project has received funding from the European Research Council (ERC) under the European
Union's Horizon 2020 research and innovation programme (grant agreement no 809994).</p>
</projectDesc>
<schemaRef type="guide" key=" EGCv01" url="https://docs.google.com/document/d/15HFxHJTOzIU1UDyVrB2yQYJ5wl6JyEshEkYgg5qwj8M/edit#"/>
</encodingDesc>
<profileDesc>
<langUsage>
 <!-- choose the language(s) of your text, remove the others -->
</langUsage>
<textClass>
<keywords>
 <!-- In due course we will can use this element to declare keywords as <term>s, but at the moment
please ignore <keywords> -->
</keywords>
</textClass>
</profileDesc>
<revisionDesc>
<change who="part:axja" when="2020-01-06" status="draft">Creation of the template</change>
 <!-- replace this by a line that has you as @who, that has the @date on which you finished the first basic
encoding of the file, and that has the following description of what was finished on that date: "Initial encoding of the
file." Then add a <change> entry for each significant change to the file. -->
</revisionDesc>
```
```xml
</teiHeader>
<text xml:space="preserve" xml:lang="lg-code"> <!-- update the language code -->
    <body>
        <!-- Structure as necessary with <div>, <p>, <ab>, <lg> depending the nature of the text -->
    </body>
</text>
</TEI>
```

## 2. <teiHeader> — Recording Metadata

As editors of digital editions, we need to produce machine-readable information of the manuscripts or witnesses, editions and bibliographic references we are working with. These details should be encoded within the <teiHeader>, which works as a container for all the metadata regarding the materials in use for a digital edition. Note that a TEI-XML file without metadata does not have any value outside of the project. However, you will not need to build the <teiHeader> yourself, since the DHARMA project provides its own ready-made template for critical editions. We will now describe in sequence all TEI elements foreseen within the template.

### 2.1 <fileDesc> — Describing the XML file

The first element <fileDesc> is mandatory. It contains a description about the XML file itself, such as its title and the persons responsible for its content. The first, mandatory, child element of <fileDesc> is the <titleStmt>; as will be explained below, the <titleStmt> provides information on the title and those responsible for its content.

#### 2.1.1 <titleStmt> — Titles and people involved

The <titleStmt> contains the title given to your digital edition as well as one or more optional statements of responsibility such as encoders, editors, authors, compilers and so on.

##### 2.1.1.1 <title> and <author> — Declaring the title of the work and the name of its author

The element <title> indicates the title for the web publication of the digital edition. Following the TEI guidelines, we recommend that you indicate the title of the work being edited in its original language, if possible with a translation of the same into English, and a subtitle that should at least describe the nature of your edition, but may also contain words that describe the nature of the original text being edited.<fnref n="9" />

Use an element <title> with @type="main" to state the title of the original work in the original language — but feel free to use stem forms of Sanskrit words — and add @xml:lang

<footnote n="9">⁹ This will allow a distinction between the electronic work and the source text in citations and in catalogs which contain descriptions of both types of material.</footnote>
with the relevant ISO language code.<fnref n="10" /> To this can be added a corresponding `<title type="alt">` for its English translation, no `@xml:lang` being required for it because English is set as our default language on the `<TEI>` root element in our template for critical editions.<fnref n="11" /> Finally, it is recommended to work with a `<title type="sub">` to state a subtitle that may include further description of the text and of the edition, in plain English. If the name of the work's author is known, you can encode it with `<author>`, after all the `<title>` elements. We recommend you use a normalized form of the name when possible.<fnref n="12" />

As the following two examples show, you should minimally give one `<title type="main" xml:lang="...">` and one `<title type="sub">`, while you may optionally use a `<title type="alt" xml:lang="...">` to translate the title of the original text.

Example 2.1.1.1.A

```xml
<titleStmt>
  <title type="main" xml:lang="kaw-Latn">Svayambhu</title>
  <title type="sub">Digital Critical Edition and Translation of an Old Javanese Juridical Text</title>
</titleStmt>
```

Example 2.1.1.1.B

```xml
<titleStmt>
  <title type="main" xml:lang="san-Latn">Naimittikakriyānusandhāna</title>
  <title type="alt">Exposition of Occasional Rites</title>
  <title type="sub">Digital Critical Edition and Translation of a Śaiva Ritual Manual</title>
  <author>Brahmaśambhu</author>
</titleStmt>
```

Even though we recommend keeping the usage of `<title>` elements simple, it is possible to work with more than one `<title>` element to provide a title for a base text and one or more dependent texts. In this situation, which should only occur if you are in fact editing base and dependent text in integrated form, the attribute `@type="main"` is still expected, but an attribute `@subtype="base-text"` or `@subtype="commentary"` must be added to connect the respective titles to the corresponding segments of the edition. When there is more than one dependent text, you need to add an extra `@n` attribute, in order to link the title to the text concerned.<fnref n="13" />

Example 2.1.1.1.C

```xml
<titleStmt>
```

<footnote n="10">¹⁰ See EGD §10.3 and Appendix D.</footnote>

<footnote n="11">¹¹ See §8.9.1 for more on use of `@xml:lang`.</footnote>

<footnote n="12">¹² It might be worth considering adding the author in the authority list of the project, as well as linking it to international reference frameworks. Consult the XML-TEI Data Manager about this.</footnote>

<footnote n="13">¹³ To deal with the different titles, we are reusing the solution established for SARIT, and available in their Guidelines §4.1.1.</footnote>
```xml
<title type="main" subtype="base-text" xml:lang="san-Latn">Aṣṭāṅgahṛdayasaṁhitā</title>
<title type="main" subtype="commentary" xml:lang="san-Latn" n="1">Sarvāṅgasundarā</title>
<title type="main" subtype="commentary" xml:lang="san-Latn" n="2">Āyurvedarasāyana</title>
<title type="sub">Digital Critical Edition of a Sanskrit Medical Text with two Commentaries</title>
</titleStmt>
```

When you have a case in which several titles are provided, corresponding to base text and dependent texts, the different `<author>` elements can be associated with their respective works using their attribute `@role`, recommended values being “base-author” and “commentator”. Once again, when there is more than one dependent text, you need to add the extra `@n` attribute.<fnref n="14" />

<caption>Example 2.1.1.1.D</caption>

```xml
<titleStmt>
<title type="main" subtype="base-text" xml:lang="san-Latn">Aṣṭāṅgahṛdayasaṁhitā</title>
<title type="main" subtype="commentary" xml:lang="san-Latn" n="1">Sarvāṅgasundarā</title>
<title type="main" subtype="commentary" xml:lang="san-Latn" n="2">Āyurvedarasāyana</title>
<title type="sub" subtype="editorial">Digital Critical Edition of a Sanskrit Medical Text with two Commentaries</title>
<author role="base-author">Vāgbhaṭa</author>
<author role="commentator" n="1">Aruṇadatta</author>
<author role="commentator" n="2">Hemādri</author>
</titleStmt>
```

### 2.1.1.2 <editor> and <respStmt> — Identifying scholarly responsibilities

The `<editor>` element is allowed to record the editors of the critical edition. Any person identified as editor and member of the project should be identified using the attribute `@ref`. Its value is built with the prefix `:part:` followed by the identifier of the person. All the identifiers are given in the <reference list> stored in the project-documentation repository.

If you need to add as editor any colleague who cannot be considered as project participant, and is thus not present within the reference list, assign this `<editor>` an `@xml:id` and a `@ref` using the person's VIAF permalink as value.<fnref n="15" /> Use the first two letters of her/his forename followed by the first two letters of the surname in the case of western names, and the two first letters of each part of the name in the case of non-western names.

In all cases, specify the editor's names inside the `<editor>` element, using the elements `<forename>` and `<surname>` for western names, but only with `<name>` when such a division doesn't apply.

<caption>Example 2.1.1.2.A</caption>

<footnote n="14">¹⁴ This example is taken from SARIT Guidelines §4.1.1.</footnote>

<footnote n="15">¹⁵ To find a person's VIAF permalink, go to http://viaf.org/.</footnote>
```xml
<editor ref="part:anac">
    <forename>Andrea</forename>
    <surname>Acri</surname>
</editor>
<editor ref="part:adgu">
    <name>Aditia Gunawan</name>
</editor>
<editor xml:id="coedes" ref="http://viaf.org/viaf/66465311">
    <forename>George</forename>
    <surname>Cœdès</surname>
</editor>
```

For any other responsibility, use the `<respStmt>`. This element must include an element `<resp>`, which can be used to describe a person's role. The name of the person is then given with the element `<persName>` with the attribute `@ref`. If the person has already been encoded above, then use `@ref` in the same way as shown above under `<editor>` for project members, but for others use `@ref=#ID` using the value of the `@xml:id` previously defined. The name of the person should be encoded with both elements `<forename>` and `<surname>`, or simply `<name>`, as necessary.

Example 2.1.1.2.B

```xml
<respStmt>
    <resp>EpiDoc encoding</resp>
    <persName ref="part:anac">
        <forename>Andrea</forename>
        <surname>Acri</surname>
    </persName>
    <persName ref="part:adgu">
        <name>Aditia Gunawan</name>
    </persName>
    <persName ref="#coedes">
        <forename>George</forename>
        <surname>Cœdès</surname>
    </persName>
</respStmt>
```

If several aspects of responsibility need to be distinguished, every `<resp>` must be wrapped in a separated element `<respStmt>`. In other words, repeat `<respStmt>` as many times as you need, with a single `<resp>` in each one.

Example 2.1.1.2.C

```xml
<respStmt>
```
<resp>diplomatic edition of the codex unicus</resp>
<persName ref="part:argr">
<forename>Arlo</forename>
<surname>Griffiths</surname>
</persName>
<persName ref="part:tilu">
<forename>Timothy</forename>
<surname>Lubin</surname>
</persName>
</respStmt>
<respStmt>
<resp>encoding of the edition</resp>
<persName ref="part:argr">
<forename>Arlo</forename>
<surname>Griffiths</surname>
</persName>
</respStmt>

## 2.1.2 <publicationStmt> — Metadata on the digital publication

The element **<publicationStmt>** contains metadata concerning the publication of the digital critical edition. It is a formal recommendation of the TEI that elements supplying information about publication place, address, identifier, availability and date be given following the name of the publisher, distributor or authority concerned, and preferably in that order.

In most cases, the element **<authority>** should at least identify the DHARMA project. Feel free to add elements regarding your specific situation, if your edition is associated with another project, institution or other, when necessary.

Please fill in the name of the city (or names of the cities) where you (and your co-editors) work. As you see in the example below, editors based in different locations may include the respective publication places in one **<pubPlace>**.

The element **<idno>** provides the name of the file itself for archiving purposes, since it helps keeping track of the record after the project. The template furnished the attribute @type with the mandatory value "filename". Follow the [File Naming Conventions (FNC)](https://www.w3.org/TR/FNC/)<fnref n="16" /> established for DHARMA, but do not keep the extension of the filename.

The **<availability>** is set by default to a Creative Commons licence identifying the author. It will only require your intervention in the second paragraph, where you will have to state the name(s) of the copyright holder(s).

<caption>Example 2.1.2.A</caption>

<publicationStmt>
<authority>DHARMA</authority>

<footnote n="16">¹⁶ Available at the following link: https://bit.ly/2JytLbz.</footnote>
<pubPlace>Lyon (France) and Lexington, VA (USA)</pubPlace>

<idno type="filename">DHARMA_CritEdSvayambhu</idno>

<availability>

<licence target="https://creativecommons.org/licenses/by/4.0/">

<p>This work is licenced under the Creative Commons Attribution 4.0 Unported Licence. To view a
copy of the licence, visit https://creativecommons.org/licenses/by/4.0/ or send a letter to Creative Commons, 444
Castro Street, Suite 900, Mountain View, California, 94041, USA.</p>

<p>Copyright © 2019-2025 by Arlo Griffiths and Tim Lubin.</p>

</licence>

</availability>

<date from="2019" to="2025">2019-2025</date>

</publicationStmt>

2.1.3 <sourceDesc> — Identifying and describing your sources

Inside the <sourceDesc>, you can record details about the original manuscripts and printed
texts used as witnesses in establishing your critical edition. Start with a <listWit>, which is the
container for all the witnesses that you will be referring to in the critical apparatus.

2.1.3.1 Declaring an individual witness

Each individual witness has to be declared with its own tag <witness>. The declaration requires, notably, the definition of a machine-readable siglum for each witness in the form of an @xml:id. As previously stated, the value of any @xml:id serves as a unique identifier for the element bearing the attribute; it can contain only alphanumeric characters from the ASCII tables and is case-sensitive.

Any specific information on the typographical rendering (e.g. use of superscript; see §8.8.1), symbols or non Latin characters can be given for the display using the <abbr> (abbreviation) element as shown in the example with the attribute @type="siglum". It should always be the first child of <witness>.

<figure><img src="image_3.png" /><figcaption>Example 2.1.3.1.A</figcaption></figure>
<abbr type="siglum">Ed<hi rend="superscript">P</hi></abbr>
<bibl><ptr target="bib:Pollock1993_01"/></bibl>
</witness>
</listWit>
</sourceDesc>

The @xml:id's defined here will be used while encoding the critical apparatus, as explained in §5.4.

If you need to cite the readings of any published edition among your witnesses, note that you must furnish the bibliographic references within <witness> using the tags <bibl> and <ptr> as shown above. Should you need to limit the scope of the reference to certain specific parts or pages, etc, of the publication in question, use <citedRange> in the manner exhaustively presented in §8.4.1.

A single witness can be associated with more than one specific presentation of its text. This might be the case, for instance, when the witness is a work that presents what is intended to be the same edition in two scripts, such as the Raghu Vira edition presented in ex. 2.1.3.1.B with Balinese and Devanāgarī versions. The main <witness> is here given its @xml:id to record readings that are identical in both scripts. However, we have added in this main <witness> element a <listWit> in order to add two more <witness> elements representing the respective scripts with their respective @xml:id's and <abbr> elements to allow differentiation if differences need to be reported. To create the @xml:id, reproduce the main one and add the code to represent the script after a hyphen.

<caption>Example 2.1.3.1.B</caption>

<witness xml:id="EdRV">
<abbr type="siglum">Ed<hi rend="superscript">RV</hi></abbr>
<desc>Global siglum for the Balinese- and Devanāgarī-script editions</desc>
<listBibl>
  <bibl>
    <ptr target="bib:RaghuVira1962_01"/>
  </bibl>
</listBibl>
<listWit>
  <witness xml:id="EdRV-bal">
    <abbr type="siglum">Ed<hi rend="superscript">RV</hi><hi rend="subscript">bal</hi></abbr>
  </witness>
  <witness xml:id="EdRV-dev">
    <abbr type="siglum">Ed<hi rend="superscript">RV</hi><hi rend="subscript">dev</hi></abbr>
  </witness>
</listWit>
</witness
### 2.1.3.2 Declaring a family of witnesses

Should you desire to regroup several witnesses because you identify them as belonging to the same branch of transmission, i.e. you consider them a family of sorts, open an element `<listWit>` inside which you will declare an element `<witness>` for every witness you wish to associate with this group of manuscripts. Since such a family is a concept rather than a physical object, the `@xml:id` to identify the group as a whole should be recorded at the `<listWit>` level.<fnref n="17" />

The TEI model doesn't foresee the possibility of providing an `<abbr>` element directly as a first child of `<listWit>`, as it does for `<witness>`, so you must use an element `<head>` to give a name to the family and add at the end, in an `<abbr type="siglum">`, the relevant encoding for its typographical rendering. If you want to explain your motivation behind the gathering of several witnesses, you can use the element `<desc>`.<fnref n="18" />

<caption>Example 2.1.3.2.A</caption>

```xml
<listWit xml:id="msj">
  <head>The Javanese Manuscripts (<abbr type="siglum">J</abbr>)</head>
  <desc><!-- possible explanation --></desc>
  <witness xml:id="msja"><abbr type="siglum">J</hi rend="subscript">1</hi></abbr>
  <msDesc>
    <msIdentifier>
      <settlement>Jakarta</settlement>
      <institution>Perpustakaan Nasional Republik Indonesia</institution>
      <collection>Koleksi Naskah Nusantara</collection>
      <idno>L631</idno>
    </msIdentifier>
  </msDesc>
</witness>
<witness xml:id="msjb"><abbr type="siglum">J</hi rend="subscript">2</hi></abbr>
  <msDesc>
    <msIdentifier>
      <settlement>Jakarta</settlement>
      <institution>Perpustakaan Nasional Republik Indonesia</institution>
      <collection>Koleksi Naskah Nusantara</collection>
      <idno>L298</idno>
    </msIdentifier>
  </msDesc>
</witness>
<witness xml:id="msjc">
  <abbr type="siglum">J</hi rend="subscript">3</hi></abbr>
  <msDesc>
    <msIdentifier>
      <settlement>Jakarta</settlement>
      <institution>Perpustakaan Nasional Republik Indonesia</institution>
    </msIdentifier>
  </msDesc>
</witness>
```

<footnote n="17">¹⁷ On this matter, DHARMA follows the model of the Digital Latin Library, §7.3.1.1.</footnote>

<footnote n="18">¹⁸ The use of `<desc>` is constrained and has the disadvantage of not being able to contain structuring elements such as `<p>` and `ab`. See the possibilities in the TEI Guidelines: https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-desc.html.</footnote>
<collection>Koleksi Naskah Nusantara</collection>
<idno>L241</idno>
</msIdentifier>
</msDesc>
</witness>
</listWit>

This representation of the witnesses allows you to refer to both the branch of transmission and the witnesses that belong to it, as per convenience. With reference to the above example, referring in your apparatus to the identifier "msj" would be considered a shortcut to quoting the three witnesses at once, i.e. J would be equal to J₁, J₂ and J₃. Declaring the family doesn't limit the possibility of quoting the witnesses J₁, J₂ and J₃ on their own.

Although there are no limits regarding the possibility of sub-categorizing the witnesses, we recommend you to limit yourself to the most meaningful ones. Please note that a witness can only be declared once. If you expect it to be associated to more than one family, one or several <listWit> will have to be used to internally structure those groups.

### 2.1.3.3 Declaring an archetype or a hyparchetype

An archetype represents the most recent common ancestor of known manuscripts while a hyparchetype is to be understood as the ancestor of a family of manuscripts. Though they are no longer surviving, you can still make it possible to encode the reading they are inferred to have had with the element <witness>. In theory such a transmissional situation could be represented using the family encoding described in §2.1.3.2. That solution lists the different witnesses both inferred and surviving without implying their relationships. However, if describing the relationships between branches of transmission is one of your preoccupations, you can embed a <listWit> inside a <witness>.<fnref n="19" />

For example, for the critical edition of the Skandapurāṇa, the editors use three manuscripts forming the recension S, meaning that they descend from to the same archetype: S1, S2 and S3/4. Yokochi had demonstrated that S1 stems from another hyparchetype than the common ancestor of S2 and S3/4.<fnref n="20" /> The latter is in fact a single witness that has become separated over two collections. (See §2.1.3.4 on this kind of scenario.) The manuscripts can be analyzed into two families that stem from two hyparchetypes, to which Yokochi has assigned the sigla α and β. The latter has two branches, β1 and β2. The diagram below shows how Yokochi visualized the relationship between the witnesses.

<footnote n="19">¹⁹ On this matter, DHARMA follows the model of the Digital Latin Library, §7.3.1.2. The example below is taken from that source.</footnote>

<footnote n="20">²⁰ Yuko Yokochi (2013), *The Skandapurāṇa: the Vindhyavāsinī Cycle*, Leiden: Brill, figure 2, p. 51 and p. 58.</footnote>
<figure><img src="image_4.png" /><figcaption>Figure 2 Revised Stemma Codicum of the S recension</figcaption></figure>

If presented in the form of a list of witnesses, the result could be as follows, with the
corresponding TEI code shown in the following example:

Archetype S: ancestor of the hyparchetypes α and β

- hyparchetype α

- S1 National Archives, Kathmandu, MS2-229. (AD 810/811)

- hyparchetype β: ancestor of β1 β2

- hyparchetype β1

- S2 National Archives, Kathmandu MS 1-831 (Undated)

- hyparchetype β2

- S3 Bodleian Library, Oxford, MS Sanskrit.a.14 (R). (Undated)

- S4 National Archives, Kathmandu, MS4-2260. (Undated)

Example 2.1.3.3.A

<listWit>
  <witness xml:id="S">
    <!-- archetype manuscript S -->
    <abbr type="siglum">S</abbr>
    <desc>Archetype S: ancestor of the hyparchetypes α and β</desc>
    <listWit>
      <witness xml:id="α">
        <abbr type="siglum">α</abbr>
        <desc>Hyparchetype α</desc>
      </listWit>
      <witness xml:id="S1">
        <abbr type="siglum">S</abbr>
        <msDesc>
          <msIdentifier>
            <settlement>Kathmandu</settlement>
            <repository>National Archives</repository>
            <idno>MS2-229</idno>
          </msIdentifier>
        </msDesc>
      </witness>
    </listWit>
  </witness>
</listWit>
<msFrag xml:id="S4">
  <head>
    <abbr type="siglum">S<hi rend="subscript">4</hi></abbr></head>
    <msIdentifier>
      <settlement>Kathmandu</settlement>
      <repository>National Archives</repository>
      <idno>MS4-2260</idno>
    </msIdentifier>
    <!-- msContents and other elements possible -->
  </head>
  <body>
    <!-- listWit witnesses -->
    <listWit>
      <witness>
        <!-- End of hyparchetype S -->
      </witness>
    </listWit>
  </body>
</msFrag>

### 2.1.3.4 Describing witnesses

Within each `<witness>` element that concerns a manuscript, you can supply a description of it, using the element `<msDesc>`. The description should furnish the basic information needed to identify the witness, such as its location, both geographical and institutional, and its identifier (shelfmark or identification pattern used by the holder), and should also furnish metadata on the script(s) deployed in the witness.

The `<msDesc>` is itself composed of four elements:

1. `<msIdentifier>`

2. `<msContents>`

3. `<physDesc>`

4. `<history>`

All four will be furnished in the encoding template and may not be removed, though it is not mandatory to fill in any contents for `<msContents>` and `<history>`. By contrast, `<physDesc>` must always be filled in, and `<msIdentifier>` must contain at least an `<idno>`, if the manuscript is kept in an institution, while it may contain other elements as well, such as `<settlement>` and `<repository>`. The encoding of `<settlement>` becomes mandatory if you are describing a manuscript kept in a private collection for which no identifier can be specified with `<idno>`.

In case of multi-text manuscripts it may be interesting to record which texts have been copied along with the edited text (and perhaps the foliation marking the beginning and end of this text). The element `<msContents>` offers the possibility to describe the content of any manuscript or part of it, and provides the `<summary>` element that is also used in the DHARMA project for encoding inscriptions. Note that if you associate a `<summary>` element with a
specific witness, this means that you need to provide a summary of the contents of your witness and not of your edition.

If your manuscript contains several texts or textual units, not all of which are covered by your edition, and you wish to make explicit which texts have been copied along with the text(s) you are editing, use the element `<msItem>` for each individual work within it. You can record basic information such as the author, the title, the location in the manuscript with folio references, the language of the text and others, respectively with the elements `<author>`, `<title>`, `<locus>` and `<textLang>`. Inside `<msItem>`, you may add the element `<filiation>` to provide information on the relationship between the manuscript and other surviving manuscripts of the same text, either specifically or in a general way. You can use `<summary>` to formulate any remark that pertains to the contents of the manuscript as a whole.<fnref n="21" />

Example 2.1.3.4.A

```
<msContents>
```

```
<summary>This is a multi-text manuscript. The constituent parts show distinct hands and three separate foliation ranges in Balinese script. Continuous pagination has been applied by pencil in a Roman hand. Both Balinese and Roman numberings show irregularities.</summary>
```

```
<msItem n="1">
  <locus>fol. 1r-29v, p. 1-57</locus>
  <title>Vratiśāsana</title>
</msItem>
<msItem n="2">
  <locus>fol. 1v-11r, p. 61-80</locus>
  <title>R şiśāsana</title>
</msItem>
<msItem n="3">
  <locus>fol. 11r-21v, p. 80-106</locus>
  <title>Śaivaśāsana</title>
</msItem>
<msItem n="4">
  <locus>fol. 1v-5r, p. 109-115</locus>
  <title>Śīlakrama</title>
</msItem>
</msContents>
```

We furnish below (example 2.1.3.4.G) an alternative method for encoding composite manuscripts with `<msPart>` that allows a focused codicological description of the constituent parts.

Finally, you may also provide a `<colophon>` element to record any colophon. It should be structured with one or more `<quote>` elements on which you must provide an attribute `@type` with one of the following values: "diplomatic", "normalized" or "translation". Note that the `@type="translation"` can only be used if another type of `<quote>`, either "diplomatic" or "normalized", is also present. The element `<quote>` can contain tags typically used in a

<footnote n="21">²¹ https://www.tei-c.org/release/doc/tei-p5-doc/en/html/examples-msContents.html</footnote>
diplomatic edition, such as <unclear>, <add>, <del>, <gap/>, <supplied> etc. The element
<note> should only be used at the end of the <quote>, as the last child. Finally, you should
specify an attribute @xml:lang with the corresponding language code (see §Appendix B for the
list of codes used in the project). Use <colophon> only for scribal statements not shared
between your different witnesses; for text-final colophons that are a common part of the
transmission, use the solution given in §3.3.2.2.

Example 2.1.3.4.B

<msContents>
<msItem>
<colophon>
<quote xml:lang="kaw-Latn" type="normalized">iti tatva bima svarga, lulukatan parisamapta</quote>
</colophon>
</msItem>
</msContents>

Example 2.1.3.4.C

<msContents>
<msItem>
<colophon>
<quote xml:lang="osn-Latn" type="diplomatic">Itiḥ kahuvusan·niẓm putaka bima Ḍpas· harani :ka,
sam·map·ta sam·pun· sinurata <gap reason="lost" unit="character" quantity="1"/> Iń vulan· kasa, sań anurat·
panadaAn· sakapat· pun·, qəñcu nu ńaheraẓm bukit· cikuray· samapun</quote>
</colophon>
</msItem>
</msContents>

The element <physDesc> is used to record metadata about the physical aspects of each of your witnesses, notably the script(s) that they use, encoded with the child element <handDesc>. It is possible to include in <physDesc> a simple free-text paragraph in a <p>; it is also possible to include such a <p> in more specialized child elements that can be part of <physDesc>. The simplest case is shown in the following examples:

Example 2.1.3.4.D

<physDesc>
<p>Generic descriptive prose on the support on which this copy of the text is written.</p>
<handDesc>...</handDesc>
</physDesc>
Although as a general rule it is not recommended in TEI to combine unstructured prose descriptions with the usage of more specialized elements, it may not always be possible to avoid combining specialized and generic elements that may be combined in a single `<physDesc>`.<fnref n="22" /> Note that, for the document to be valid, all generic elements (i.e. `<p>`) must precede the first specialized element in the description, as in the following slightly more elaborate example:

<caption>Example 2.1.3.4.E</caption>

```xml
<physDesc>
  <p>Generic descriptive prose.</p>
  <objectDesc>
    <p>Generic descriptive prose on the support on which this copy of the text is written.</p>
  </objectDesc>
  <handDesc>...</handDesc>
</physDesc>
```

Among the numerous elements that can be nested inside your `<physDesc>`, the only one that is mandatory is `<handDesc>` (see §2.1.3.1), which can be used to describe the different hands used in the given manuscript but must be used to state the script that is used, even if there is only one hand. However, if you wish to provide details related to the artefact itself, use an element `<objectDesc>`. It is not mandatory that you structure it, so you can simply use a `<p>` element to encode relevant information such as dimensions, folio and so on. But if you need a finer structure, try to follow this model:

<caption>Example 2.1.3.4.F</caption>

```xml
<physDesc>
  <objectDesc form="concertina">
    <supportDesc>
      <support>Tree-bark</support>
      <extent>27 folios</extent>
      <dimensions scope="all" type="folio" unit="cm">
        <height>27</height>
        <width>24</width>
      </dimensions>
    </supportDesc>
    <extent></extent>
  </objectDesc>
  <layoutDesc>
    <layout>The texts run from folio A1 to A27, and from B1 to B26, B27 is left blank. The beginning of a
```

<footnote n="22">²² There might be some circumstances in which avoiding the usage of such a mixed approach is not possible. This could happen, for instance, (1) if the description you are writing already exists in a prose form, where some of the specialized topics are treated together in paragraphs of prose, but others are treated distinctly; (2) if some parts of the description cannot be mapped to a pre-existing specialized element, although all parts of the description are clearly distinguished.</footnote>
text is preceded by the <foreign>bindu na godang</foreign> <g type="B1"/> whereas the division into smaller
sections of the texts is stressed by the <foreign>bindu na metmet</foreign> <g type="B2"/>. From B1 to B9 the
internal divisions of the text are stressed by another type of <foreign>bindu na metmet</foreign> in which its upper
right-side has been elongated shaping a single black line <g type="BL"/>. The black line precedes and runs
parallel to the first line of the text, until the right-side margin. On these same folios, each small section of text is
accompanied by a drawing, representing different anthropomorphic figures.</layout>

In the case of a manuscript composed of parts that were originally separate and that have been
bound together at a later stage, it is possible, after describing the artefact as a whole in its
present condition in <physDesc> to furnish an element <msPart> for the constituents, making it
possible to formulate focused descriptions of the physical characteristic (dimensions, hands,
etc.) of each part. The following example is an alternative to the approach illustrated in
2.1.3.4.A:

<caption>Example 2.1.3.4.G</caption>
```xml
<msIdentifier>
<settlement>Leiden, the Netherlands</settlement>
[...]
<idno>Or. 3632 (2)</idno>
</msIdentifier>
<msContents>
<msItem>
<locus>fol. 1r-29v, pp. 1-57</locus>
<title>Vratišāsana</title>
</msItem>
</msContents>
<physDesc>
<p>...</p>
<handDesc>
<p/>
 <!--<handNote xml:id="A_H2" scriptRef="11111"/>-->
</handDesc>
</physDesc>
</msPart>
</msDesc>
```

Conversely, if your text is transmitted in a fragmented manuscript, you can declare this with `<msFrag>`. This element works like `<msPart>`, but is used to emphasize the prior context of the manuscript, typically as a description of a virtual reconstruction of a manuscript or other objects whose fragments have been cataloged separately. This approach, more concerned by the physical aspect and history of the manuscript, is not mandatory. The choice of encoding these aspects or not is left to the encoder's discretion.

Example 2.1.3.4.H

```xml
<witness xml:id="S3-S4">
<abbr type="siglum">S<hi rend="subscript">3</hi>/S<hi rend="subscript">4</hi></abbr>
<msDesc>
<msIdentifier><!-- instead of <msIdentifier>, you can also use <altIdentifier><idno n="..."/></altIdentifier> -->
<msName>Constituent parts of S3/S4</msName>
</msIdentifier>
<msFrag xml:id="S3">
<head><abbr type="siglum">S<hi rend="subscript">3</hi></abbr></head>
<msIdentifier>
<settlement>Oxford</settlement>
<repository>Bodleian Library</repository>
<idno>MS Sanskrit.a.14 (R)</idno>
</msIdentifier>
 <!-- msContents and other elements possible -->
</msFrag>
<msFrag xml:id="S4">
<head><abbr type="siglum">S<hi rend="subscript">4</hi></abbr></head>
```
<msIdentifier>
  <settlement>Kathmandu</settlement>
  <repository>National Archives</repository>
  <idno>MS4-2260</idno>
</msIdentifier>
<!-- msContents and other elements possible -->
</msFrag>
</msDesc>
</witness>

Finally, the element <history> can be used to supply a brief history of the manuscript as a
physical artifact. If, within <history>, you wish to tag the date and place of creation of your
manuscript, you can do so by incorporating the elements <origDate> and <origPlace> inside the
free-text that makes up the <p>. Remember that all the information you store in these
specialized elements must, in turn, be contained in <p>.

Here is a fully-fledged example:

<figure><img src="image_5.png" /><figcaption>Example 2.1.3.4.1²³</figcaption></figure>

<footnote n="23">23 This is largely compiled from https://sarit.indology.info/vadanyayatika.xml?view=div, but since that manuscript does allow illustrating the full range of elements that can be used in <msIdentifier>, we have made up that part and some other details of the example.</footnote>
```xml
<p>Palm-leaf manuscript. 89 leaves in Siddhamāṭrōkā script.</p>
</objectDesc>
<handDesc>
  <handNote xml: id="A1_H1" scriptRef="class:38774 maturity:83213">
    <abbr type="hand">A</hi rend="superscript">1</hi>H<hi rend="subscript">1</hi></abbr>
  </handNote>
</handDesc>
</physDesc>
<history>
  <p>The manuscript was apparently written in <origDate when="1152">1152 CE</origDate> and found, in June 1934, by Rāhula Sāṅkṛtyāyana in the monastery of Kun-de-ling (Lhasa).</p>
</history>
</msDesc>
</witness>
<witness xml: id="A2">...</witness>
<witness xml: id="B">...</witness>
</listWit>
</sourceDesc>
```

You might need to record metadata in even more detail than the above; in this case, contact the project's XML-TEI Data Manager.

### 2.1.3.5 <handDesc> — Encoding the hand(s) with its/their script(s)

As briefly introduced in §<sourceDesc>, the script(s) used in a manuscript must be encoded in <handDesc>. Below, we will offer a more detailed description of how to do so. The same element <handDesc> will be used if multiple hands are identifiable within the manuscript. If you need to refer to individual hands in your critical apparatus, then you should encode each hand as a child of <handDesc>. If you want to record and describe more than one hand, you must add the attribute @hands in <handDesc>; its value, which must be numerical, will indicate the total amount of encoded hands. Note that we consider each different script found within a single witness to represent a distinct hand.

<caption>Example 2.1.3.4.A</caption>

```xml
<witness xml: id="A1">
  <abbr> A<hi rend="superscript">1</hi></abbr>
  <msDesc>
    <msIdentifier>
      <settlement>Leiden</settlement>
    </msIdentifier>
    [...]
  </msDesc>
  <handDesc hands="3">
    [...]
  </handDesc>
</witness>
```
```xml
</physDesc>
</witness>
```

Within `<handDesc>` you will record one `<handNote>` per hand: each of them will bear a unique `@xml:id`, an abbreviation encoded in `<abbr>` and a free-text description of the hand-type itself in a `<p>`. The main hand of the manuscript comes first:

Example 2.1.3.4.B

```xml
<witness xml:id="A1">
  <abbr>A<hi rend="superscript">1</hi></abbr>
  <msDesc>
    <msIdentifier>
      <settlement>Leiden</settlement>
    </msIdentifier>
    [...]
  </msDesc>
  <physDesc>
    <handDesc hands="3">
      <handNote xml:id="A1_H1" scriptRef="class:57470 maturity:83215">
        <abbr type="hand">A<hi rend="superscript">1</hi>H<hi rend="subscript">1</hi></abbr>
        <p>main hand of the manuscript, black ink, Sundanese script</p>
      </handNote>
      <handNote xml:id="A1_H2" scriptRef="class:57470 maturity:83215">
        <abbr type="hand">A<hi rend="superscript">1</hi>H<hi rend="subscript">2</hi></abbr>
        <p>generally in red ink, placed on the margins of the manuscript, Sundanese script</p>
      </handNote>
      <handNote xml:id="A1_H3" script="Latn">
        <abbr type="hand">A<hi rend="superscript">1</hi>H<hi rend="subscript">3</hi></abbr>
        <p>generally in blue ink, Roman script; interlinear transcriptions of selected words</p>
      </handNote>
    </handDesc>
  </physDesc>
  <msDesc>
    <p></p>
  </msDesc>
</witness>
```

The `@xml:id` representing the hands shall be constructed as follows:

* hand 1 (the main hand) = `siglum-of-the-manuscript_H1`

* hand 2 = `siglum-of-the-manuscript_H2`, etc.

You will thus be able to refer to these hands by adding an attribute `@hand` to the relevant element within your edition (§5.5.13). The value of `@hand` will correspond to the value of the `@xml:id` you have chosen to represent that specific hand with. Note that the main hand is always understood to be active unless stated otherwise. This means that, in practice, you will rarely, if at all, be needing the `xml:id` for hand 1.
Unless you are dealing with a Latin-script hand, as in A1_H3 in the example above, the script should be provided with the attribute @scriptRef on each <handNote>. The content shall refer to DHARMA controlled vocabularies established for script classification as well as maturity, using a prefix to identify one of the two lists, and should be followed by the code associated to the concept.<fnref n="24" /> The list established for script classification shall be prefixed with “class:”, while a script maturity will be introduced with “maturity:”. Note that both values are required to identify a script and should be separated by a blank space. As shown above, for exceptional cases like a Latin-script hand, you should use @script instead of @scriptRef, and use the script suffixes defined by ISO 15924,<fnref n="25" /> i.e., in most cases -Latn.

### 2.1.4 Shortcut for citing sigla and hands

If you need to cite a witness in free-text sections, as in a <p> or in a <note>, where the @wit cannot be used (§5.4), you can use a <ptr/> tag as a shortcut to name the witness. See the following examples:

<caption>Example 2.1.4.A</caption>

```xml
<app>
  <lem type="emn">sakesi</lem>
  <rdg wit="#A2">sakeṁsi</rdg>
  <rdg wit="#A1">sakiṁsi</rdg>
  <note>A second hand has crossed out the <foreign>anusvāra</foreign> in <ptr target="#A2"/></note>
</app>

<note>While <ptr target="#A1_H1"/> appears accidentally to have left the ligature <foreign>ktya</foreign> incomplete, <ptr target="#A1_H2"/> has furnished the missing <foreign>y</foreign> element.</note>
```

The empty elements `<ptr target="#A2"/>` and `<ptr target="#A1_H2"/>` work as pointers to the `@xml:id` of the manuscript A² and the hand A¹H₂ as defined in the `<teiHeader>`.

## 2.2 <encodingDesc> — Documenting your work

The `<encodingDesc>` follows the `<fileDesc>` and can contain several sub-elements. This element serves (1) to describe the project context in which your edition is being produced, (2) to keep a record of your editorial policies, and (3) to clarify the relationship between any external files and your digital edition, especially if there may be uncertainty or ambiguity related to the representation of the sources. The DHARMA template for critical editions will contain the following basic `<encodingDesc>`:

<caption>Example 2.2.A</caption>

<footnote n="24">²⁴ See https://opentheso.huma-num.fr/opentheso/?idt=th347 to access DHARMA controlled vocabularies.</footnote>

<footnote n="25">²⁵ https://unicode.org/iso15924/iso15924-codes.html</footnote>
```xml
<encodingDesc>
```

```xml
<projectDesc>
```

```xml
<p>The project DHARMA has received funding from the European Research Council (ERC) under the European Union's Horizon 2020 research and innovation programme (grant agreement no 809994).</p>
```

```xml
</projectDesc>
```

```xml
<schemaRef type="guide" key="EGCv01" url="supplied_in_template"/>
```

```xml
<!-- UPDATE the link once the release is made official -->
```

```xml
<listPrefixDef>
```

```xml
<prefixDef ident="bib" matchPattern="([a-zA-Z0-9\_]+)" replacementPattern="supplied_in_template"/>
```

```xml
<p>Public URIs with the prefix bib to point to a Zotero Group Library named ERC-DHARMA whose data are open to the public.</p>
```

```xml
</prefixDef>
```

```xml
<prefixDef ident="part" matchPattern="([a-z]+)" replacementPattern="supplied_in_template"/>
```

```xml
<p>Internal URIs using the part prefix to point to person elements in the
<ref>DHARMA_IdListMembers_V01.xml</ref> file.</p>
```

```xml
<prefixDef ident="txt" matchPattern="([a-zA-Z0-9]+)" replacementPattern="supplied_in_template"/>
```

```xml
<p>Internal URIs using the txt prefix to point to text-titles in the <ref>DHARMA_IdListTexts_V01.xml</ref> file.</p>
```

```xml
</prefixDef>
```

```xml
</listPrefixDef>
```

```xml
</encodingDesc>
```

The section of `<listPrefixDef>` is mandatory, since it provides the correct paths to each external file containing the bibliographic references (as managed in the Zotero Group Library), the participants, and the textual sources for parallels, as will be further explained in §7.1 and sub-sections. As you see, each prefix definition contains (i) an attribute `@ident`, which provides the term that will function as the prefix for an abbreviated pointing scheme; (ii) an attribute `@matchPattern` that, supplies “a regular expression against which the values of other attributes can be matched”; (ii) `@replacementPattern`, which provides “the skeleton of a relative or absolute URI containing references to groups in the @matchPattern which, once subpattern substitution has been performed, complete the URI”. The `<p>` is added for clarity, and simply explains in free-text what the encoding pattern does.

## 2.2.1 `<projectDesc>` — Describing the project

The `<encodingDesc>` should minimally have the sub-element `<projectDesc>`. This is used to explain, in one or two `<p>` elements of free-text, the context of the creation of the file. The first paragraph must be about DHARMA. A second paragraph can be used in any edition made in the framework of a personal research project such as a PhD.

<caption>Example 2.2.1.A</caption>

```xml
<encodingDesc>
```

```xml
<projectDesc>
```

```xml
<p>The project DHARMA has received funding from the European Research Council (ERC) under the European Union's Horizon 2020 research and innovation programme (grant agreement no 809994).</p>
```

```xml
<p>It has been carried out as part of my research towards a PhD thesis defended on the DDth of
```
MM, YYYY<fnref n="26" /> at the École Pratique des Hautes Études, Paris.</p>
</projectDesc>
</encodingDesc>

### 2.2.1.1 <editorialDecl> — Recording specificities of your own work

The element `<editorialDecl>`, a child-element of `<encodingDesc>`, can be used for formulating methodological choices underlying your edition. It is especially useful if you need to give more detail than, or need to make exceptions from, what is stated in the present guide, its Appendices and the DHARMA project's [Transliteration Guide](https://en.wikipedia.org/wiki/Transliteration_Guide).<fnref n="27" /> We envisage the possibility that you, as editor, use one or more of the following elements to take notes during the editing process, and postpone till the final phase of your editing work which information, if any, are to be maintained in the digital publication.

The element `<editorialDecl>` may contain free-text descriptions wrapped in any number of `<p>`. Alternatively, the TEI offers a number of sub-elements that can be used to further structure the contents of `<editorialDecl>`, of which you may want to use: (1) `<correction>`, (2) `<normalization>`, (3) `<punctuation>` or (4) `<interpretation>`. The free-text contents of these sub-elements must likewise be wrapped in `<p>`.

1. The sub-element `<correction>` can be used to give specifications regarding the correction principles within your edition. It allows you to explain the logic applied for omission, truncation, correction, alternate readings and so forth, and to state whether such cases are handled silently or with mark-up.

2. The sub-element `<normalization>` can be used to explain the extent of normalization and regularization applied on the text as critically edited. You can use this element to document the specificities of your text and the way you have dealt with them as editor, regarding such topics as non-standard (dialectal) forms or non-standard spellings.

3. The sub-element `<punctuation>` can be used to explain the degree of correspondence between punctuation of your constituted text and the punctuation found in the witnesses — whether punctuation is entirely or largely editorial, whether you generally attempt to follow punctuation of the witnesses or whether issues of punctuation can trigger creation of an apparatus entry.

4. The sub-element `<interpretation>` can be used to describe any additions you are making to the text edition that relate to issues of analysis or interpretation.<fnref n="28" /> This may be the place to describe what editorial hyphenation you implement.

Example 2.2.1.1.A

<footnote n="26">²⁶ The TEI guidelines allow a more in-depth encoding of such information, for example through the addition of a `<date>` with `@when="YYYY-MM-DD"` in case one wants to encode the date of publication of a bibliographic reference within a `<p>` in `<projectDesc>`. However, we do not advise our editors to do so.</footnote>

<footnote n="27">²⁷ The relevant document is available on [HAL-SHS](https://www.cineca.fr/en/research-and-education/harcourt-hal-shs).</footnote>

<footnote n="28">²⁸ Note that for this element a by-default paragraph about asterisk will be added in the template and should be reproduced in all the editions, Others could be added at a later stage, especially to record any practices that may not have been explicitly explained in one of the guides of the DHARMA project.</footnote>
<figure><img src="image_6.png" /></figure>

### 2.2.1.2 `<samplingDecl>` — Explaining the sources chosen for your edition

Inside the `<encodingDesc>`, the `<editorialDecl>` is followed by the element `<samplingDecl>`. It is used to record free-text information about inclusion or omission of portions of the text, manuscripts, or witnesses. It is here that you may explain, for example, the reasons behind favoring one witness above others in your choice of readings or, to give another example, the fact that you wholly or partly omit from your collation the readings of a given witness because it is too damaged to be collated for all or a portion of the text.

<figure><img src="image_7.png" /><figcaption>Example 2.2.1.2.A</figcaption></figure>

### 2.2.1.3 `<schemaRef>` — Declaring the schema

The element `<schemaRef>` can point to any external customization file of the TEI. We will use it to record the URL of the latest version of this encoding guide. More than one `<schemaRef>` can be provided, and we will do so, eventually, to link to the relevant ODD.<fnref n="29" />

The element works with the attributes `@type`, `@key` and `@url`. The first attribute characterizes the content (e.g. guide, schema or ODD). The second provides an identifier

<footnote n="29">²⁹ An ODD (“One Document Does it All”) is a TEI XML file that states the set of elements used in a project, as well as the prose and reference documentation linked to it; the ODD documentation is, then, used to generate a relevant schema. A schema, in its turn, validates the “grammar” of the XML files according to constraints written for a project.</footnote>
concerning the guide itself, normally the acronym established within the project (e.g. EGC), and
the number of its version expressed according to rules stated in the [File Naming Conventions](https://en.wikipedia.org/wiki/File_Naming_Conventions),<fnref n="30" />
e.g. v01 for the first version.

Example 2.2.1.3.A

<schemaRef type="guide" key="EGCv01" url="supplied_in_template"/>

2.2.1.4 `<variantEncoding>` — Declaring the method used for building your apparatus

To comply with the TEI, it is obligatory to declare the methodology chosen to encode the
apparatus, and notably the variant readings, especially since DHARMA works methodologies to
accommodate all the practices of the project.

Depending on the method you have chosen to encode your apparatus, you will need to
update the attribute @method in the <variantEncoding/> element.<fnref n="31" /> To sum it up
straightforwardly, if you are encoding your apparatus with the inline method (which is
recommended for prose texts), you will select @method="parallel-segmentation", but if you opt
for an apparatus coming at the end of the sections of your edition (which is really only an option
in verse texts), you must select @method="location-referenced". For more on this topic, see §5
as well as §6.3.

Example 2.2.1.4.A

Inline apparatus as described in §5

<variantEncoding method="parallel-segmentation" location="internal"/>

Apparatus after text as described in §6.3

<variantEncoding method="location-referenced" location="internal"/>

2.2.2 `<profileDesc>` — Providing descriptive elements

The element `<profileDesc>` serves to provide metadata related to non-bibliographic aspects of
the text. In DHARMA, it will mostly be used to record language usage and classificatory
keywords.

The element `<langUsage>` is the mandatory container for `<language>`. This element
serves to record the languages used in the text. In the attribute @ident, we shall indicate the
ISO 693-3 **language codes** as listed in §Appendix B.<fnref n="32" /> However, since the element
<langUsage> cannot be used to indicate the *actual* distribution of languages within the text you
are editing, your digital edition will have to declare `@xml:lang="eng"` as base language for your

<footnote n="30">³⁰ Available at the following link: https://bit.ly/2JytLbz.</footnote>

<footnote n="31">³¹ You will find both methods provided in the template, and you will need to select the method that will be adopted in your edition.</footnote>

<footnote n="32">³²See also EGD §10.3 and Appendix D.</footnote>
file (§1) and then mark containers for portions of text distinguishing the respective languages by the attribute @xml:lang with the values from the same list of language codes (see §8.10.1). This kind of encoding must be adopted, for instance, in the case of a Sanskrit *mūla* with gloss or commentary in another language.

The element `<textClass>` shall be used to contain the element `<keywords>`. Each one shall be encoded inside an element `<term>` and selected from the project's closed list of terms that will eventually be drawn up.

<caption>Example 2.2.2.A</caption>

```xml
<profileDesc>
  <langUsage>
    <!-- choose the language(s) of your text, remove the others -->
    <language ident="san-Latn">Sanskrit, romanized</language>
    <language ident="kaw-Latn">Old Javanese, romanized</language>
    <language ident="ori-Latn">Oriya, romanized</language>
    <language ident="osn-Latn">Old Sundanese, romanized</language>
    <language ident="tam-Latn">Tamil, romanized</language>
    <language ident="kan-Latn">Kannada, romanized</language>
    <language ident="tel-Latn">Telugu, romanized</language>
  </langUsage>
  <textClass>
    <keywords>
      <!-- In due course we will can use this element to declare keywords as <term>, but at
           the moment please ignore <keywords> -->
      <term/>
      <!-- Ignore this element for the time being. -->
      <keywords/>
    </keywords>
  </textClass>
</profileDesc>
```

## 2.2.3 <revisionDesc> — Keeping track of file History

The history of the file, from filling in the template to the final review, is to be recorded in the last high-level element of the `<teiHeader>`, namely `<revisionDesc>`. Recording changes can be useful for the management and control of the files or to have a quick overview of the latest changes made when you return to work on a file after some time has passed. Each important change should be encoded in an element `<change>` — the latest of which should always be added at the very top of the list — with the mandatory attribute `@who`, the value of which shall be the personal identifier<fnref n="33" /> of the person(s) making the change, normally yours, with the prefix “part:” (as an abbreviated reference to the file listing participants of the project). It is possible to indicate more than one “part:” in one `@who`, distinguishing them with a blank space, as in the

<footnote n="33">³³ All identifiers are available in DHARMA's Members list.</footnote>
example below. The attribute @when is also expected, and should have as value the date of the
change in ISO format, that is YYYY-MM-DD.

You can use @status to help keep track of the major steps of your work through the
values: draft, candidate, approved, published and withdrawn. This attribute can be used on both
<change> and <revisionDesc>, but we recommend using it on <change> to begin with. We
foresee @status being used with <revisionDesc> for project steps involving all the members,
rather than just to document your own work. As long as you have not finalized your edition, the
expected value is "draft".

<caption>Example 2.2.3.A</caption>

<revisionDesc>
  <change when="2020-05-29" who="part:axja" status="draft">changing the structure: moving the @source content inside a note @type="parallels"</change>
  <change when="2020-04-23" who="part:argr part:tilu" status="draft">started encoding of the edition</change>
</revisionDesc>

At subsequent steps, the value of @status can be changed to one of the following values,
depending on discussion with other team members.

* "candidate"

* "approved"

* "published"

* "withdrawn"

3. Text

3.1 <text> – Structuring the text

The edition proper is contained in the <text> element, whose opening tag must bear the
attributes @xml:space with the value “preserve” and an @xml:lang. The value of the latter
should be the main language of your text (see §Appendix B, for the relevant language ISO
codes). This implies that, if not otherwise stated, textual data contained in your <text> will be in
the language thus declared. Therefore, whenever there is a linguistic divergence from the
declared main language (e.g. from Old Javanese to Sanskrit, if Old Javanese is the main
language in your text), this should be stated by adding an @xml:lang to the relevant element.
The `<text>` contains the mandatory element `<body>`, within which you will encode your editions, translations and so on.<fnref n="34" /> The basic layers of encoding within the `<body>` are provided by `<div>`, which will structure the various sections of your text.

Since project members are expected to work with separate XML files to respectively encode their edition and its translation, we have decided against employing a main `<div>` with `@type="edition", @type="translation"` and so forth, as is done in the case of EpiDoc editions for inscriptions. The following, then, represents the minimal containing structure for your critical edition:

<caption>Example 3.1.A</caption>

```xml
<text xml:space="preserve" xml:lang="san-Latn">
  <body>
    <div>EDITED TEXT</div>
    <div>EDITED TEXT</div>
  </body>
</text>
```

In the following paragraphs, we provide the lower-level textual units that you can use in your edition.

## 3.2 <div> – Sections of text

As previously stated, within your edition, textual divisions shall be wrapped in `<div>`. Such elements can be nested into one another, in order to represent the structure of your text. The level of the structure can be specified using the attribute `@type`, bearing values such as `"chapter"` and `"canto"`, making it easier for you to navigate inside the XML file. Bear in mind that the attribute `@type` is expected each time a change of level occurs. However, also bear in mind that a small number of special divisions, viz. invocations and colophons, do not bear `@type` on `<div>` but on a child `<ab>` (see §3.3.2).

The value `"chapter"` is meant as the default value, while `"canto"` (Skt. sarga) is to be understood as a chapter of a verse text, if changes in meter mark its chapter-level divisions. In the case of texts structured by a base text (Skt. mūla) in verse or in prose (whether transmitted as such or implied) and a dependent text that glosses/paraphrases the former we shall use a dedicated `<div>` with `@type="dyad"` to bind the base text and the dependent text together. See below for the type `"dyad"` (§4.1). In case of a text mainly structured in `<div type="dyad"`, any opening or closing `<div>` that consists only in prose can be given the value `"liminal"`.

<footnote n="34">³⁴The TEI foresees the possibility of working with `<front>` and `<back>` to encode respectively the front matter and the backmatter of published books. For this reason, the element `<body>` is a part of the mandatory structure of the file itself and must be retained, however redundant it might be for our natively digital editions.</footnote>
When verse text shows several changes of meters in the same chapter, you can use
@type="metrical" to group together in one <div> all the stanzas following the same prosodic
pattern. This <div type="metrical"> can only be used as a child of another <div>. See §3.2.3.

**Should you need any other types of divisions lower than chapter/canto but higher
than the individual paragraph or stanza, please let us know.**

To offer freedom to encoders in determining the numbering pattern best suited to the text
they are editing, the attribute @n, recording sequences, has not been made mandatory for any
of the structural levels of your edition. It seems difficult to give general rules, that's why we
recommend that you consult the project's XML-TEI Data Manager to decide what numbering
scheme works best for your text. See §3.8, to access a description of the transformation with
XSLT foreseen so far.

As for units below the <div> level, the mark-up will depend upon the characteristics of
your text. In all cases where one or more prose sentences are involved, the lowest textual unit
must be the <p> (paragraph), as explained in §3.3.1. Any stanzas contained in your text must
be wrapped in the element <lg> (line group), as explained in §3.4.1; in this case, the lower
textual unit within <lg> will be <l> (line), as explained in §3.4.3. Finally, in the case of chunks of
texts that do not satisfy the minimum definition of a sentence and can for that reason not be
contained by a <p>, you may use the element <ab>, as further explained in §3.3.2. In summary,
here is a list of the recommended values for @type with <div>:

* chapter

* canto

* dyad

* group

* interpolation

* liminal

* metrical

* section

3.2.1 <head> – Section titles

Although some printed text editions in our fields of scholarship do state the title of the work at
the top of the first page of the edition, we do not believe this ever reproduces anything similar
observed in the same position in the witnesses and it certainly is redundant besides the
declaration of the work's title in <titleStmt>. Therefore, we can limit ourselves here to headings
for textual components.

We assume that your edition will treat text-internal headings of the type *atha
śabdānuśāsanam* as regular sentences, perhaps forming a <p> on their own. Consequently, the
DHARMA project's critical editions will use the element <head> only to represent editorial
headers formulated in English. The element should always contain the @type="editorial" and
@xml:lang="eng".
Example 3.2.1.A

<div n="4" type="chapter">
  <head type="editorial" xml:lang="eng">Privileges: ownership of controlled types of property</head>
  <p>...</p>
</div>

It is not required for a <div> (or any other text component) to have a <head>. However, if a <head> element is necessary within a container, it should be encoded right after the opening part of the relevant element, as the first child of <div>.

3.2.2 Declaring prosody for a canto

You may use the attribute @met on a <div> element to represent metrical information concerning all its children elements <lg>. The list of names allowed is given in the prosodic patterns authority file, on which, see the PVG. The canto header displayed will be like this:

Example 3.2.2.A

<div type="canto" n="8" rend="met" met="śārdūlavikrīḍita" xml:id="candrakirana_04.01">
  <lg n="1">
    [...]
  </lg>
</div>

Display -

Canto 8

Śārdūlavikrīḍita: - - - - - - - - - - - - - - -

If you cannot give a name to the metrical pattern observed, enter the prosodic code as value in
the @met, following the XML conventions presented at the top of the prosodic patterns file. Note
that even in such cases, the pattern must be recorded in the mapping file, in the part for the
relevant number of syllables per pāda, and the heading displayed will be like this:

Example 3.2.2.B

<div type="canto" n="11" rend="met" met="--+--+--+--+--+--" xml:id="rt_12">
  <lg n="1">
    [...]
  </lg>
</div>

Display -

Canto 11
```html
</div>
<div type="metrical" met="drutavilambita">
    <lg xml:id="candrakirana_04.05" n="5"/>
    <lg xml:id="candrakirana_04.06" n="6"/>
</div>
<div type="metrical" met="pādānuṣṭubh">
    <lg xml:id="candrakirana_04.07" n="7"/>
    <lg xml:id="candrakirana_04.08" n="8"/>
    <lg xml:id="candrakirana_04.09" n="9"/>
    <lg xml:id="candrakirana_04.10" n="10"/>
</div>
</div>
```

## 3.3 Prose Containers

### 3.3.1 <p> – Paragraphs

The basic container element for any prose text is the paragraph <p>. Coherent groups of sentences together form the typical paragraph, but you can use this element even if it contains no more than one complete sentence. End the current <p> and begin a new one when a new paragraph begins, in the same manner as you would do for modern text. As many elements <p> as needed can be encoded inside a <div>. A <p> can contain other elements, but it cannot contain other <p>: nesting is prohibited in this case. The element <p> will be provided with an XSLT-generated @xml:id; see §7.2.1.1. If you want to have full control of the way numbering appears in display (e.g., to circumvent numbering of paragraphs resuming at 1 at every new <div>) then manually encode the value to be displayed using the attribute @n on <p> (and preferably use full-stop as separator between counters, no need to use leading zeros); see §3.8.

<caption>Example 3.3.1.A</caption>

```html
<div type="dyad" n="11" xml:id="svayambhu_02.11">
    <quote xml:id="svayambhu_02.11.01" type="base-text" xml:lang="san-Latn"><supplied reason="implied">
        <lg xml:id="svayambhu_02.11.01.01" met="anuṣṭubh">
            <l n="a">yasmin deśe niṣṭīdanti</l>
            <l n="b">viprā vedavidas trayah |</l>
            <l n="c">rājñāś ca prakṛto vidvān</l>
            <l n="d">brāhmaṇas tāṁ sabhāṁ viduḥ ||</l>
        </lg>
    </quote>
    <p xml:id="svayambhu_02.11.02" n="11.1">saṅ brāhmaṇa tigaṅ siki, paḍa vruh mañaji, hana brāhmaṇa sasiki prajñān vidagdha, vinidhi muṅgva riṅ deśa saṅ prabhu, ikaṅ deśa papupulanira, yeka deśa sabhā ṭaranya de saṅ paṇḍita.</p>
</div>
```
### 3.3.2 `<ab>` – Anonymous blocks

As per TEI guidelines, the element `<ab>` (anonymous block) can be used to contain arbitrary component-level units of a text, acting as an anonymous container for phrase or inter-level elements analogous to a paragraph, but without the semantic baggage of labeling a unit as `<p>`. As with `<p>`, so too each `<ab>` will be furnished with an XSLT-generated `@xml:id`; see §7.3.1. If you want to have full control of the way numbering appears in display, then manually encode the value to be displayed using the attribute `@n` on `<ab>` (and preferably use full-stop as separator between counters, no need to use leading zeros); see §3.8.

In the DHARMA project's critical editions, we foresee the use of the `<ab>` element to encode invocations and colophons, and also for encoding speaker indications in texts cast as a dialogue (§3.5.3), as shown in the next two subsections. Finally, we foresee its use in the probably rare instances of text following a connective particle or phrase (e.g. *iti*, *api ca*) used to introduce or end stanzas and not functioning as an integral part of the unit adjacent to the stanza.<fnref n="36" />

#### 3.3.2.1 Invocations and colophons

To represent an auspicious word, such as siddham, or an auspicious phrase, such as namo gaṇeśāya, if such a textual element is weakly connected to the adjacent text, we recommend that you use an appropriate prose container `<ab>` inside a `<div>` without any `@type` while assigning `@type="invocation"`. In this case, assign no number to the `<div>`.

<caption>Example 3.3.2.1.A</caption>

```html
<div>
  <ab type="invocation" xml:lang="san-Latn">namo gaṇeśāya</ab>
</div>
```

However, in the case of invocations to specific divisions of the text, the invocation must be included at the top of the relevant `<div>` but after any furnished `<head>`. Depending on the structure of your text edition — namely whether the highest-level `<div>s` (e.g. `<div type="chapter">` themselves also contains child `<div>s` (e.g. `<div type="dyad">`)— it may then be necessary to wrap the `<ab>` in its own `<div>` in order for the invocation to be brought into structural parallelism with the other child `<div>s` of the parent `<div>`.

Another type of text segment that is extraneous to the overall textual structure, but not classifiable as `<head>`, is the colophon, a term by which we mean here a short statement declaring the end of a text or of a text component. In these cases too, you have to use `<ab>`, and include these as final child within the `<div>` to which they belong, or within a separate `<div>` without `@type` or `@n` just before the end of the `<body>` if they pertain to the text as a whole. You must mark the `<ab>` element with `@type="colophon"`. In this case too the need may arise to wrap the `<ab>` in a `<div>`. See example 3.3.2.1.C.

<footnote n="36">³⁶ See EGD §2.2.2 for how to encode this last scenario.</footnote>
Example 3.3.2.1.B

<div>
  <ab type="colophon" xml:lang="san-Latn">iti strīsatyarakṣaṇa</ab>
</div>

Example 3.3.2.1.C

<div type="chapter" n="2" xml:id="svayambhu_03">
  <head type="editorial">Protection of Faithful Women</head>
  <div type="dyad" n="32" xml:id="svayambhu_04.01">
    [...]
  </div>
  [...]
  <div xml:id="svayambhu_03.04">
    <ab xml:id="svayambhu_03.04.01" type="colophon" xml:lang="san-Latn">iti strīsatyasaṅrakṣaṇa.</ab>
  </div>
</div>
</div>
 <!-- end of chapter 2 -->

Note that the declaration of @xml:lang is not necessary if the language of the invocation and
that of the text proper are identical.

3.3.2.2 Speaker indications

When dealing with a text that is not dramatic in nature (see §3.5.1) but is nevertheless
structured in the form of a dialogue and the transmission itself dedicates structural elements to
indicating the change of speaker, such elements — whether they can be analyzed as a full
sentence or not — are to be wrapped in <ab> with @type="speaker".

Example 3.3.2.2.A

<ab type="speaker">devy uvāca</ab>

It is possible to mark-up the speaker's name with <persName> and @key as per §8.6.2.1.

3.4 Verse Containers

Just as the main components of any prose in your edition need to be encoded, so do any verse
components. The following example shows full encoding of a single Sanskrit stanza.

Example 3.4.A
```xml
<lg met="anuṣṭubh" n="8.123">
  <l n="a">vyavahārān didṛkṣus tu</l>
  <l n="b">brāhmaṇaiḥ saha pārthivaḥ</l>
  <l n="c">mantrajñair mantribhiṣ caiva</l>
  <l n="d">vinītaḥ praviśet sabhām ||</l>
</lg>
```

In the following sections, you will find brief explanations on how to deal with different scenarios involving the encoding of text composed in verse form.<fnref n="37" />

### 3.4.1 <lg> — stanzas

One <lg>, or line group, corresponds to a single stanza as a whole. It can be nested either within a <div> or within a <p>. The <lg> can contain one or more <l> elements and must have the attribute @met to identify the meter of the stanza by its conventional name, if @met has not been declared on the parent <div>. Unlike what is prescribed for epigraphic editions in the EGD, in critical editions the numbering of the <lg> with the attribute @n is allowed but not mandatory. Notably, you should not apply @n to any stanzas that are only implied in the text you are editing but that are supplied in your edition. Another case where you will probably want to omit @n is when a whole text or a whole <div> consists in a single <lg>, which is the case for metrical composition structured essentially in lines and not in stanzas (e.g, when @met="free"), for in such cases arabic line numbering will appear in display. If you encode @n on any <lg> that are part of your text, then you must do so following a consistent pattern, the value of @n on <lg> always being displayed as such (see §3.8). An XSLT-generated attribute @xml:id will be provided also for <lg> (see §7.2.1.1).

The structural framework of a stanza must always be encoded, even when it is damaged or lost. Do not omit missing lines but identify them as lacunae.<fnref n="38" />

#### Example 3.4.1.A

```xml
<lg xml:id="candrakirana_14.01.03" n="3">
  <l n="a">kita makarūpa chanda,</l>
  <l n="b">agave titi mvaṅ śloka,</l>
  <l n="c">ya ta varṇanen kavātun,</l>
  <l n="d">ya pinakasuluhiṅ rāt.</l></lg>

<lg xml:id="candrakirana_14.01.04" n="4">
  <l n="1">Ivriṇiṇ chanda ta ṇaranya,</l>
  <l n="2">kvehiṇ vilaṅniṇ akṣara,</l>
  <l n="3">rikanaṇ pāda sayati,</l>
  <l n="4">pāda ṇaranya sakaṇḍa,</l>
  <l n="5">pa<pb n="13v" edRef="#msba"/>taṇ pāda ya saśloka.</l></lg>
```

<footnote n="37">³⁷ Please note that the present guide follows the vocabulary established in EGD §2.3.1. All the elements discussed here have been introduced in greater detail in the EGD.</footnote>

<footnote n="38">³⁸ As per the guidance in EGD §2.3.8.</footnote>
Display –

kita makarūpa chanda,
agave titi mvaṅ śloka,
ya ta varṇanen kavetun,
ya pinakasuluhiṅ rāt. 3

[line 1] Iviriṅ chanda ta ṇaranya,

[line 2] kvehiṅ vilaṅniṅ akṣara,

[line 3] rikanaṅ pāda sayati,

[line 4] pāda ṇaranya sakaṇḍa,

[line 5] pa[B1:13v]taṅ pāda ya saśloka. 4

### 3.4.2 @met — metrical patterns

The metrical pattern, or “template”, of a stanza will be encoded using the conventional name of the meter as values of the attribute @met in the element <lg>. The list of names allowed is given in the prosodic patterns authority file (see PVG). If a given <div> is entirely (or almost entirely) composed of stanzas of a given type, you may state the @met (or the dominant @met) on the <div>. The metrical pattern for each child <lg> is then inherited from the parent <div>, and doesn't need to be repeated — while any <lg> that has a divergent meter should receive its specific @met, and the divergent value can be displayed. However, as in the case of @met encoded on <div> (§3.2.2), so too the value of @met recorded in an <lg> element will only be displayed if you add a @rend="met".<fnref n="39" />

If you cannot assign a name to the meter in question, you can still use @met to record the prosodic pattern using XML notation. Follow the conventions presented in the prosodic patterns authority file (see PVG). Prosodic XML notation is also used for the attribute @real on the <l> element, to which we now turn.

### 3.4.3 <l> — metrical lines

The line element <l> contains an individual metrical line (pāda). The attribute @n must be used to number the lines. For the numbering of Sanskrit, Prakrit or Old Javanese quantitative verse, you should use lower case Roman letters (a, b, c, d). In syllabo-quantitative verse, assign a letter to each <line>, but in quantitative verse, treat the hemistich as equivalent to a line, i.e. stanzas of the āryā family shall be marked up as consisting of two lines (ab, cd). In other traditions of versification (e.g. Old Sundanese or Tamil), especially when verse lines cannot meaningfully be grouped into stanzas, use a single Arabic number per line and wrap all lines in the relevant given text division together into a single <lg>. Metrically irregular lines are to receive the attribute @real.<fnref n="40" />

<footnote n="39">³⁹ This approach was chosen to be able to deal with texts mixing prose and verse where there is a strong preponderance of *anuṣṭubh* stanzas, for which the metrical pattern does not need to be displayed, besides a smaller number of stanzas using other patterns that do need to be displayed.</footnote>

<footnote n="40">⁴⁰ EGD §2.3.5.</footnote>
### 3.4.4 @real – deviant metrical patterns

The meter of a stanza or of an individual verse line shall not be encoded so long as it conforms to the pattern encoded for the group of stanzas or for the single stanza to which they belong. But when a line, or a group of lines, deviates from the expected pattern, and you believe the metrical irregularity was intended by the author(s) of the work you are editing, it is possible to record the phenomenon using the attribute @real on the stanza or the verse line concerned. The value of the attribute should be the actually observed prosodic pattern following the notation provided in the prosodic patterns authority file (see PVG).

**Example 3.4.4.A**

```xml
<lg met="pādānuṣṭubh">
  <l n="a">...</l>
  <l n="b">...</l>
  <l real="===========" n="c">liṅ saṅ paṇḍita vruheṅ mārga</l>
</lg>
```

**Display –**

^273. liṅ [...] marga:] Unmetrical line. The observed pattern is not *pādānuṣṭubh* but ✜[...][.]

If the above auto-generated observation, based on the values of @met and @real, does not yield an adequate result in the situation you are dealing with, you can formulate a tailor-made observation on the metrical situation by encoding a `<note>` at the end of the `<l>`, which will annul the auto-generated observation.

**Example 3.4.4.B**

```xml
<lg met="pādānuṣṭubh">
  <l n="a">...</l>
  <l n="b">...</l>
  <l real="++++-++-" n="c">liṅ saṅ paṇḍita vruheṅ mārga<note>The line has nine syllables and is hence not compliant with the <foreign>pādānuṣṭubh</foreign> pattern.</note> </l>
</lg>
```

**Display –**

^273. liṅ [...] marga:] The line has nine syllables and is hence not compliant with the *pādānuṣṭubh* pattern.

### 3.4.5 @enjamb – enjambment

In the context of the DHARMA project, enjambment is defined as the occurrence of a metrical line break within a word (usually between members of a compound; rarely within a morpheme). To mark it up, use the attribute @enjamb with the value "yes" when a break occurs at the end of
the line that does not coincide with the end of the word. This attribute should be added on the `<lg>` element containing the initial part of the broken word, not to the one containing the final part like you would do with the attribute `@break`.

When the break falls between words that are members of a compound and without vowel fusion *sandhi*, put any editorial hyphens you might be using for compound analysis at the beginning of the second `<lg>` involved. When a vowel fusion *sandhi* occurs at the transition from one `<lg>` to the next, put the break after the fused vowel without adding a hyphen.

However, when a vowel fusion sandhi happens at the end of a stanza with text outside of it (typically the quotative *iti*), do not use `@enjamb`. Let us take as example the last quarter of a common stanza, which might appear as ... *pitṛbhiḥ saha majjatīti||* in your witnesses, the *iti* being extraneous to the stanza yet written before the punctuation sign. In order to facilitate verse-indexation, the sandhi should be resolved and the metrically extraneous kept outside the stanza — meaning that it needs to be edited in an immediately following container.

Example 3.4.5.A

```xml
<lg>
    [...]
    <l n="d">pitṛbhiḥ saha majjati||</l>
</lg>
<ab>iti</ab>
```

```xml
<lg>
    [...]
    <l n="d">pitṛbhiḥ saha majjati</l>
</lg>
<ab>iti ||</ab>
```

This must be done irrespective of whether any punctuation sign is included in your edition at the end of the stanza, and as shown in the two variants of the above example, the placement of the punctuation inside `<lg>` or inside `<ab>` depends on your preference. If such phenomena are frequent in your text, we recommend that you state the fact that you are intervening as editor in the `<teiHeader>`, and apply one of the encoding solutions shown above without further comment, see §2.2.1.1. If such phenomena are exceptional, and if it is deemed necessary, you can provide a `<note>` element to explain any individual editorial intervention in human-readable terms:

Example 3.4.4.B

```xml
<lg>
    [...]
    <l n="d">pitṛbhiḥ saha majjati||</l>
</lg>
<ab>iti<note>All witnesses read <foreign>majjatīti ||</foreign>.</note></ab>
```
## 3.5 Spoken Text

### 3.5.1 Dramatic elements

Plays are usually organized in structural and formal divisions in which various characters speak, taking turns. Their structure may be analyzed as hierarchic in more than one way: a scene may be divided into speeches and, at the same time, into verse lines. When you wish to emphasize the speech-based performance, you shall use the dramatic elements. However, if your text can't be qualified as dramatic, use the sections §3.5.2 and §3.5.3 to encode direct speech and dialogues.

Each individual speech of a play should be encoded with the element `<sp>`. It requires the element `<speaker>` as first child, which furnishes a label introducing the name of the speaker, while the spoken text itself should be tagged with the elements `<p>`, `<ab>` or `<lg>` and `</l>`, depending on whether it is in prose or in verse.

Any content that can be classified as stage direction should be encoded within the element `<stage>`. When the stage direction is related to a specific speech, `<stage>` should be contained in the element `<sp>` as a child or a descendent depending on the context.

If you ever need to encode drama, follow the few main principles formulated in this section and contact the project's XML-TEI Data Manager.

<caption>Example 3.5.1.A</caption>

```xml
<sp>
  <speaker>rāmaḥ</speaker>
  <stage>tataḥ praviṣaty upaviṣṭo rāma sītā ca</stage>
  <p>devi vaidehi samāśvasihi samāśvasihi te hi guravo na śaknuvanty asmān vimoktum</p>
  <lg met="anuṣṭubh">
    <l>kin tv anuṣṭhāna | nityatvam</l>
    <l>svātantryam apakarṣati</l>
    <l>saṅkaṭā hy āhitāgnīnāṃ</l>
    <l>pratyavāyair gṛhasthatā</l>
  </lg>
</sp>
```

### 3.5.2 Direct speech

The above elements are specific to drama. If you are not sure your text could, or should, be classified as dramatic, you can use more neutral elements. Quotations of direct speech can be encoded with the element `<said>` which can be used for real people as well as fictional ones. The speaker can then be identified with the attribute `@who` if you find her/his identification ambiguous. Just write the name as you expect it to be displayed in the attribute `@who`.
### 3.5.3 Dialogue

If you are encoding a dialogue, which isn't part of a dramatic text, you might want to identify the changes of one interlocutor to another. We foresee two situations, one where the text itself dedicates a structural element to indicating the change of speaker, and another where the text does not but you wish to aid the reader by marking changes of speaker.

For the first scenario, see §3.3.2.2. In the second scenario, mark the place where an interlocutor begins to speak by inserting a `<label>` wrapped around the name of the interlocutor in normalized form. It will be treated as an editorial element and not as an actual part of the text.

**Example 3.5.3.A**

```p><label type="speaker">Rāma</label>devi vaidehi samāśvasihi samāśvasihi te hi guravo na śaknuvanty asmān vimoktum</p>
```

Note that the element `<label>` should always be a child of `<div>`, `<ab>`, `<p>` or `<lg>`. As in §3.3.2.2, it is possible to mark-up the speaker's name with `<persName>` and `@key` as per §8.6.2.1.

## 3.6 Mixed prose and verse

As we have just shown from a dramatic context in example §3.5.1.A, if your text mixes prose and verse, but you are not dealing with any scenario of the type discussed in §4, then every block of prose will be encoded in a `<p>` while every stanza will be encoded in `<lg>`.

**Example 3.6.A**

```p><g met="anuṣṭubh" xml:lang="san-Latn">
  <l n="a">vyavahārān didṛkṣus tu</l>
  <l n="b">brāhmaṇaiḥ saha pārthivaḥ</l>
  <l n="c">mantrajñair mantribhiś caiva</l>
  <l n="d">vinītaḥ praviśet sabhām ||</l>
</g>
<p met="puṣpitāgrā" xml:lang="san-Latn">
  <l n="a">daramukulitanetrapāli nīvī</l>
  <l n="b">nityamitabāhu kṛtoruyugmabandham</l>
  <l n="c">karakalitakucasthalaṃ navoḍhā</l>
  <l n="d">svapiti samīpam upetya kasya yūnaḥ ||</l>
</p>
```

```p><p>samānalajjāmadanā madhyā | eṣāivātipraśrayād ativiśrabdhanavoḍha | asyāś ceṣṭā sāgasi preyasi dhairye vakr' oktir adhairya paruṣavāk | yathā</p>
```
## 3.7 Quotation made by author of the text being edited

If any of the stanzas is quoted from an external source, then wrap the stanza or group of stanzas in a `<quote>` element.

<caption>Example 3.7.A</caption>

```xml
<quote xml:lang="san-Latn">
  <lg met="anuṣṭubh">
    <l n="a">vyavahārān didṛkṣus tu</l>
    <l n="b">brāhmaṇaiḥ saha pārthivaḥ</l>
    <l n="c">mantrajñair mantribhiś caiva</l>
    <l n="d">vinītaḥ praviśet sabhām ||</l>
  </lg>
</quote>
```

Note that this use of `<quote>` is not limited to whole stanzas; in fact, it is not limited to verse-context at all. Any word, string of words or block of words (`<p>`, `<l>`, `<lg>`) can be wrapped in `<quote>` to render a quotation from another work made by the author of your text. See §6.2 on how to encode any known source or parallels.

If you need the quoted segment to be displayed as an indented block quote, then apply the attribute `@rend` with the value `"block"` to the `<quote>` element. This will in principle only be necessary for long quotations of prose text within a prose `<p>`; in any scenario that involves quotations of stanzas or verse lines, the presence of `<lg>` will lead to verse-formatting in display. Quotations of shorter strings of prose without `@rend="block"` will be displayed within quotation marks.

## 3.8 Numbering the text units of the edition

The numbering of each block-level container must be handled by the encoder. It means that the `@n` attribute isn't mandatory in any element `<div>`, `<p>`, `<ab>` nor `<lg>`, but that if you want a specific value to appear in display, you can bring this about in complete freedom. That being said, we recommend that you number the relevant structural elements of your edition and if you do that you try to follow the following recommendations as consistently as possible.

Do not number any invocations or colophons.

If you want to fill in the numbering pattern as counters, then limit yourself to chains consisting of Arabic numbers for each counter, and with full-stop as separator in case more than one counter is relevant, e.g. `@n="1.8.12"`. If you want to number only the current level without including counters for the other levels, then use plain Arabic numbers, e.g. `@n="1"`.

Whatever system you choose to implement, we advise you to always check with the XML-TEI Manager of the project to get it approved. Bear in mind that the greater the diversity of
systems found in the files, the more it may become difficult to obtain a satisfactory display in all editions. Among the major downsides of giving the editor this liberty is not only the difference that will inevitably arise between various editions, but also the risk of your own unintentional inconsistency in using of @n.

For file-internal reference, an automated @xml:id will be provided to identify each level of the edition in order to overcome any problems of inconsistency or evolution of the encoding of @n. See §7.2.1.1.

# 4. Base text and dependent text

It may happen that a single text consists, in whole or in part, of a base text and a dependent text (commentary, gloss, etc.). You might want to encode only one of the two but, if you expect to encode both, you will need to make the relationship between the constituent texts explicit. Two solutions can be envisaged for doing so:

1. Encoding the texts together, as a single whole

2. Encoding the texts in separate files, and linking them to each other

How to choose which option is the most suitable? When base and dependent texts are at the same hierarchical level, or embedded into each other, it makes sense to encode them together. But when the dependent text is given in another hierarchical level, it would be easier to encode them separately. Choosing one solution does not, a priori, exclude the other: solution 2 could, for instance, implement solution 1. Let us say that you have already encoded the base text of your witness, embedded within its dependent text (solution 1), and you want to add a new layer of dependent text: encoding it in the same <div> might be rather complicated, but you could opt for encoding the additional dependent text in a separate file that refers back to the first one (solution 2). For the time being, this guide mostly provides details on solution 1.

## 4.1 Base text embedded in dependent text

When the base text is embedded in the dependent text, everything in your markup is assumed to form part of the latter, unless otherwise specified. Therefore, in order to mark a segment of text as part of the base text, you must use the element <quote> together with the attribute @type="base-text". You must also add an @xml:lang attribute when the base text and the commentary are not written in the same language (see §Appendix B for the relevant ISO codes).

<caption>Example 4.1.A</caption>

```html
<div>
  <quote type="base-text" xml:lang="san-Latn">
    <lg met="anuştub">
```
```html
<| n="a">vyavahārān didṛkṣus tu</>|>
<| n="b">brāhmaṇaiḥ saha pārthivaḥ</>|>
<| n="c">mantrajñair mantribhiś caiva</>|>
<| n="d">vinītaḥ praviśet sabhām ||</>|>
</lg>
</quote>
<p>dependent text</p>
</div>
```

In many cases, the structure of the dependent text will map precisely onto that of the base text; this means that a chunk of base text can be encoded with the corresponding section of dependent text within a single structural container, namely a `<div>`.

Higher level divisions of text wrapped in `<div>` have been discussed in §3.2 with the appropriate `@type` attribute to be used for such sections. The same element `<div>` is to be used, but with different `@type` attributes, for pairing corresponding blocks of base text and dependent text. Although other values can be proposed if necessary, at this stage the only `@type` of `<div>` for such a lower hierarchical level occurring among the DHARMA project's digitally edited texts is that with the value "dyad". A dyad refers to a textual unit presenting a stanza together with dependent prose, the pair of which is itself part of a higher-level `<div>`. When necessary, you can number your lower-level `<div>` with the attribute `@n`. Note that both attributes `@type` and `@n` are optional at this level of XML structure.

The content of the `<div>`, in its substructure, should include one or more block-level containers; on the other hand, no text is allowed to stand outside of such containers within a `<div>`.

<caption>Example 4.1.B</caption>

```html
<div>
  <div type="dyad" n="1">
    <quote type="base-text" xml:lang="san-Latn">
      <lg met="anuṣṭubh">
        <| n="a">vyavahārān didṛkṣus tu</>|>
        <| n="b">brāhmaṇaiḥ saha pārthivaḥ</>|>
        <| n="c">mantrajñair mantribhiś caiva</>|>
        <| n="d">vinītaḥ praviśet sabhām ||</>|>
      </lg>
    </quote>
    <p>kunaṅ hulaha saṅ prabhu, uniṅnānira taṅ vyavahāranikaṅ rāt, arovaña ta sira brāhmaṇa vihikan maṇaji, lavan mantri riṅ vruh mavivekā, sulakṣaṇaa ta sira tumamaa riṅ sabhā.</p>
  </div>
</div>
```
## 4.2 Several sections of base text for one section of dependent text

When dependent text is related to several sections of the base text at once, an enclosing division is required to wrap them together. This means that the element `<quote type="base-text">` will contain all of the base text sections that are comprised in the division. Each should be encoded as an independent block according to its nature, by using an element `<p>` if it is a paragraph, an `<lg>` and `<l>` elements if it is a stanza, and so forth. All the chunks of base text, once encoded, will be siblings in terms of XML-TEI hierarchy.

Remember that any segment(s) of base text that your dependent text contains are considered, from the point of view of your edition, to be quoted from the former in the latter. Numbering furnished in any edition of the base text can be recorded in `<listApp type="parallels"`, see §6.2.

<caption>Example 4.2.A</caption>

```html
<div type="dyad" n="5">
  <quote type="base-text" xml:lang="san-Latn">
    <lg>
      <l n="a">teşām ādyam ṛṇādānaṁ nikşepo 'svāmivikrayaḥ |</l>
      <l n="b">saṁbhūya ca samutthānaṁ dattasyānapakarma ca ||</l>
    </lg>
    <lg>
      <l n="a">vetanasyaiva cādānaṁ saṁvidaś ca vyatikramaḥ |</l>
      <l n="b">krayavikrayānuśayo vivādaḥ svāmipālayoḥ ||</l>
    </lg>
    <lg>
      <l n="a">sīmāvivādadharmas ca pāruṣye daṇḍavācike |</l>
      <l n="b">steyaṁ ca sāhasaṁ caiva strīsaṁgrahaṇam eva ca ||</l>
    </lg>
  </quote>
  <p>dependent text that has reference to all three above stanzas at once</p>
</div>
```

## 4.3 Base text absent in dependent text

You may confront in your digital edition the scenario that the base text is not transmitted as such in the manuscripts of the dependent text, and was presumably never included at any stage of the dependent text's development. There are basic subtypes of this scenario, namely (1) that where a base text is absent as such but nevertheless clearly implied by the dependent text, and (2) that where the author of the dependent text shows no awareness of a block of base text that is present in one or more editions of the latter.
In the first subtype, should you feel that making the implicit text explicitly visible is useful for the readers' appreciation of the text that you are editing, then you should wrap the content of `<quote>` in a `<supplied>` tag, applying to the latter the attribute `@reason` with the value `"implied"`.

<figure><img src="image_8.png" /><figcaption>Example 4.3.A</figcaption></figure>

In the second subtype, when the dependent text lacks any trace of its author's awareness of a segment of base text, but you still wish to include this segment of base text in your digital edition, you must wrap the content of `<quote>` in a `<supplied>` tag, applying `@reason` with the value `"omitted"`.

<figure><img src="image_9.png" /><figcaption>Example 4.3.B</figcaption></figure>

We will now show how the coupling of `<quote>` with `<supplied>` is to be encoded in relationship to the dependent text, while also introducing how to encode a textual reference to the base text (a topic introduced more fully in §6.2).

## 4.4 Encoding base text ignored in the dependent text

If any base text is ignored in the dependent text yet you wish to include it in your edition, you face the problem that there is no natural block of dependent text to match it with inside a `<div>`. The inclusion of a `<quote>` containing `<supplied reason="omitted">` into the edition can be
handled in two different ways. The first is to include more than one segment of base text in a
single <div>. This is illustrated in the next example, which also introduces the use of <listApp
type="parallels">.

Example 4.4.A

<div type="dyad" n="199" xml:id="svayambhu_09.15">
<quote xml:id="svayambhu_09.15.01" type="base-text" xml:lang="san-Latn">
<supplied reason="omitted">
<lg xml:id="svayambhu_09.15.01.01" met="anuṣṭubh">
< | n="a">nānyad anyena saṃṣṛṣṭaṁ</I> < | n="b">rūpaṁ vikrayam arhati |</I>
< | n="c">na sāvadyaṁ na ca nyūnaṁ</I> < | n="d">na dūre na tirohitam ||</I>
</lg>
<listApp type="parallels">
<app>
<note sameAs="txt:MDhŚ08.203">Our text gives no paraphrase for the first stanza grouped in this
section.</note>
</app>
</listApp>
</supplied>
</quote>
<quote xml:id="svayambhu_09.15.02" type="base-text" xml:lang="san-Latn">
<supplied reason="implied">
<lg xml:id="svayambhu_09.15.02.01" met="anuṣṭubh">
< | n="a">anyaṁ ced darśayitvānyā</I> < | n="b">voḍhuḥ kanyā pradīyate |</I>
< | n="c">ubhe ta ekaśulkena</I> < | n="d">vahed ity abravīn manuḥ ||</I>
</lg>
<listApp type="parallels">
<app>
<note sameAs="txt:MDhŚ08.204"/>
</app>
</listApp>
</supplied>
</quote>
<p xml:id="svayambhu_09.15.03">ikaṁ vvaṁ amintonakən kanyā, donyan səḍaṁ tinonton, ..., maṅkana liṅ
bhaṭāra manu nūnin pavarah i bhagavān bhṛgu.</p>
<quote xml:id="svayambhu_09.15.04" type="base-text" xml:lang="san-Latn">
<supplied reason="implied">
<lg xml:id="svayambhu_09.15.04.01" met="anuṣṭubh">
< | n="a">nonmattāyā na kuṣṭhinyā</I> < | n="b">na ca yā spṛṣṭamaithunā |</I>
< | n="c">pūrvaṁ doṣān abhikhyāpya</I> < | n="d">pradātā daṇḍam arhati ||</I>
</lg>
<listApp type="parallels">
<app>
<note sameAs="txt:MDhŚ08.205">Our text gives no paraphrase for the third stanza grouped in this
section.</note>
</app>
</listApp>
</supplied>
```xml
</quote>
</div>
```

In the scenario encoded here, a single `<p>` of dependent text is grouped together in a `<div>` with two stanzas known from other transmissions of the base-text. The main purpose of the editor here is simply to include the vulgate base text integrally, despite the fact that the author of the dependent text ignores certain stanzas.

The second approach is to reserve a separate `<div>` for every segment of base text, regardless of whether any corresponding segment is found in the base text that is being edited. This scenario might be adopted if the editor believes that the dependent text intentionally does not comment on a stanza.

### Example 4.4.B

```xml
<div type="dyad" n="199" xml:id="svayambhu_09.15">
  <quote xml:id="svayambhu_09.15.01" type="base-text" xml:lang="san-Latn">
    <supplied reason="omitted">
      <lg xml:id="svayambhu_09.15.01.01" met="anuṣṭubh">
        <l n="a">nānyad anyena saṃṛṣṭaṁ</l> <l n="b">rūpaṁ vikrayam arhati |</l>
        <l n="c">na sāvadyaṁ na ca nyūnaṁ</l> <l n="d">na dūre na tirohitam ||</l>
      </lg>
      <listApp type="parallels">
        <app>
          <note sameAs="txt:MDhŚ08.203">Our text gives no paraphrase for the first stanza grouped in this section.</note>
        </app>
        <listApp>
          <supplied>
            <note>
              <supplied reason="implied">
                <div type="dyad" n="200" xml:id="svayambhu_09.16">
                  <quote xml:id="svayambhu_09.16.01" type="base-text" xml:lang="san-Latn">
                    <supplied reason="implied">
                      <lg xml:id="svayambhu_09.16.01.01" met="anuṣṭubh">
                        <l n="a">anyāṁ ced darśayitvānyā</l> <l n="b">voḍhuḥ kanyā pradīyate |</l>
                        <l n="c">ubhe ta ekaśulkena</l> <l n="d">vahed ity abravīn manuḥ ||</l>
                      </lg>
                    </supplied>
                    <listApp type="parallels">
                      <app>
                        <note sameAs="txt:MDhŚ08.204"/>
                      </app>
                    </listApp>
                    <supplied>
                      <note>
                        <p xml:id="svayambhu_09.16.02">ikaṁ vvaṁ amintonakən kanyā, donyan səḍaṁ tinonton, ..., maṅkana liṅ
                          bhaṭāra manu nūnin pavarah i bhagavān bhṛgu.</p>
                      </note>
                    </supplied>
                  </quote>
                </div>
              </supplied>
            </note>
          </supplied>
        </listApp>
      </supplied>
    </quote>
  </supplied>
</quote>
</div>
<div type="dyad" n="201" xml:id="svayambhu_09.17">
```
<quote xml:id="svayambhu_09.17.01" type="base-text" xml:lang="san-Latn">
  <supplied reason="implied">
</supplied>

<lg xml:id="svayambhu_09.17.01.01" met="anușțubh">
  <l n="a">nonmattāyā na kuṣṭhinyā</l> <l n="b">na ca yā sprṣṭamaithunā |</l>
  <l n="c">pūrvaṁ doṣān abhikhyāpya</l><l n="d">pradātā daṇḍam arhati ||</l>
</lg>

<listApp type="parallels">
  <app>
    <note sameAs="txt:MDhŠ08.205">Our text gives no paraphrase for the third stanza grouped in this section.</note>
  </app>
</listApp>

Solution (2) tends to emphasize the structure of the vulgate of the base text and regards the fact that some of its elements are ignored in a dependent text as an accessory phenomenon, while solution (1) is more pertinent when a given base text is the focus of an edition.

## 4.5 Dependent text without base text

Some parts of the dependent text may not correspond to any particular section of the base text, as happens with introductory material or commentarial digressions. The same solutions that we have presented in the previous paragraph (§4.4) can be used to encode such scenarios.

If you decide that the subject is connected in some way to the preceding enclosing <div>, as in the case of digressions, then you can include the dependent text within that <div>, after the base text and the corresponding commentary with its own structural tags.

<caption>Example 4.5.A</caption>

<div type="dyad" n="31">
  <quote type="base-text" xml:lang="san-Latn">
    <lg n="31">
      <l n="a">verse line</l>
      <l n="b">verse line</l>
    </lg>
    <listApp type="parallels">
      <app/>
    </listApp>
  </quote>
  <p>dependent text related to the preceding <lg> of base text.</p>
  <p>further dependent text that doesn't correspond to the preceding <lg> of base text.</p>
</div>
If, by contrast, you reckon that the text is too unconnected from the previous enclosing
<div>, you can open a separate <div> to enclose this segment of dependent text on its own.

<figure><img src="image_10.png" /><figcaption>Example 4.5.B</figcaption></figure>

Note that introductory materials are always expected to form their own <div>. The best encoding
solution is left to you and depends on your text's intrinsic structure. In case of doubt, we
recommend the second solution, as it is less ambiguous.

4.6 Dependent text implies base text that is unknown

We distinguish from the scenario intended in the previous paragraph (§4.5) the case of implied
but unknown base text. We mean a scenario where it is clear that your dependent text reflects a
segment of another text but at least the precise wording of the segment of base text is unknown
to you, in the current state of research — or perhaps it is even unknown in which work the
reflected segment was contained. In this case, use an element <ab> for the unknown segment
base text right before the relevant block of dependent text. By the nature of the case, the <ab>
will contain no text as such, but an element <gap/> to represent it. This <gap/> will be wrapped
in <supplied reason="implied"> and can be accompanied by the element <listApp> for which
you must follow the rules given in §6.2.5 for unknown parallels. The <note> element will contain
only textual content, but bear no attributes, as shown in the example.

<figure><img src="image_11.png" /><figcaption>Example 4.6.A</figcaption></figure>
```xml
<listApp type="parallels">
    <app>
        <note>No Sanskrit stanza has been identified as corresponding to the following prose.</note>
    </app>
</listApp>
</supplied>
</ab>
<p xml:id="svayambhu_02.16.03">apan tan hana lēviha sakeń dharma, sira pinakapramāṇaniń loka, sira ta pinakasvarga sań magave hayu, sira pinakakalēpasan sań paṇḍita, tan mańkana ikań vvań adharma, tan hana gamāntyanya mańkanāta sańka pisana tuvi.</p>
</div>
```

## 4.7 Base text reconstructible from dependent text

It might happen that the text you are editing does not transmit a base text as such, but rather contains parts of it embedded within the dependent text. In this case, there might be enough constituent elements of the base text within the dependent text to allow a reconstruction of the base text itself. If such a reconstruction is among your research goals, your encoding should follow the model introduced here.

<caption>Example 4.7.A</caption>

```xml
<div>
    <div type="section">
        <quote type="base-text">
            <p xml:id="ID_02.27c" prev="#ID_02.27b" next="#ID_02.27d">some base text in prose.</p>
        </quote>
        <p>Some dependent text.</p>
    </div>
    <div type="section">
        <quote type="base-text">
            <p xml:id="ID_02.27d" prev="#ID_02.27c">some base text in prose</p>
        </quote>
        <p>Some dependent text.</p>
    </div>
</div>
```

The above scenario presents a main <div> (to which the attributes @type and @n can be added as needed), then divided into subsections, with a <div type="section"> for each pair consisting of base text and commentary. The internal organization of the <div type="section"> follows the model established in §4.1. The value "section" is just a proposition; in the scenario presented in the next section, we imagine that using "group" will make more sense for the encoder. Anyhow, feel free to contact the XML-TEI Data Manager to suggest new values.

If you opt for this encoding strategy in order to reconstruct a base text that is fragmented between sections, it must be rebuilt by linking each part together. Specific models depending on whether you are dealing with dependent prose or dependent stanza are introduced below.
4.7.1 Prose interrupted by dependent prose

In case a block of text in prose is transmitted intertwined with (and interrupted by) the prose of a dependent text, it may be desirable to implement a system that will allow for this text to be reconstituted separately.

Even a fragmented paragraph should be encoded as such, with the element <p>, rather than using the element <ab>, as long as the reconstructed version can be assimilated at least to one complete sentence. Once each segment has received its XSLT-generated @xml:id, as explained in §7.3.1, you can interlink the segments with the attributes @prev and @next, which clarify the textual segments that precede and follow. Their value should always start with "#" followed by the @xml:id of the segment of prose they point to. This system allows all the parts to be chained together and can, if necessary, be used to reconstitute the base text without interspersal of dependent text.

<caption>Example 4.7.1.A</caption>

```html
<div type="group" xml:id="ID_01.01">
  <p xml:id="ID_01.01.01" next="#ID_01.02.01" part="I">some text in prose</p>
  <p xml:id="ID_01.01.02">some dependent text here</p>
</div>
<div type="group" xml:id="ID_01.02">
  <p xml:id="ID_01.02.01" prev="#ID_01.01.01" next="#ID_01.03.01" part="M">some text in prose</p>
  <p xml:id="ID_01.02.02">some dependent text here</p>
</div>
<div type="group" xml:id="ID_01.03">
  <p xml:id="ID_01.03.01" prev="#ID_01.02.01" part="F">some text in prose</p>
  <p xml:id="ID_01.03.02">some dependent text here</p>
</div>
<div xml:id="ID_01.04">
  <p xml:id="ID_01.04.01">another paragraph in prose</p>
</div>
```

The example shows how three <p> elements corresponding to segments of the base text are connected to each other through their @prev and @next attributes; the first segment, with @xml:id="ID_01.01.01", is linked to the second, with @xml:id="ID_01.02.01", through @next; the second, with @xml:id="ID_01.02", is linked to the previous and the following bits with @prev and @next.

We do not foresee the order of segments of the base prose text being shuffled, as might happen if the base text is in verse form. This means that the fragmentation pattern should not be ambiguous — the order of the segments as preserved in the dependent text will match the content order of the base text as intended by the author of the latter — and so they can be marked up with the attribute @part, that renders explicit how all the parts interact. The permitted values for this attribute are "I", "M" and "F" in uppercase letter (for initial, medial and final), an
unlimited number of @part="M" being permitted but only one case each of @part="I" and @part="F" for one <p>.

In case you are dealing with segments of a base text in prose that are presented in the dependent text in an order which is not that of the base text as it was intended, then follow the encoding strategy with <join/> explained in §4.7.2 and contact the XML-TEI Data Manager.

## 4.7.2 Stanzas interrupted by dependent prose

In case a stanza of a base text is transmitted intertwined with (and interrupted by) the prose of a dependent text you should encode its constituent parts each with the element <lg>, and use the attributes @next and @prev as well as @part to chain them together as explained in §4.7.1. The usage of @prev, @next and @part is exactly as explained above, with the sole complication that an <lg> also has constituent verse lines that will interact in a more or less intricate fashion with the segmentation brought about by the dependent text.

Let us take as example a stanza with @n="3" contained in a <div n="33"> that is segmented into four parts by the dependent text requiring four subsections <div type="section">:

<caption>Example 4.7.2.A</caption>

```html
<div type="section">
  <lg n="3" xml:id="ID_33.07" next="#ID_33.09" part="I">
    <I n="a">...</I>
  </lg><!-- end of the 1st part of the lg in question: an entire verse line-->
  <p xml:id="ID_33.08">some dependent text here</p>
</div>
<div type="section">
  <lg xml:id="ID_33.09" prev="#ID_33.07" next="#ID_33.11" part="M">
    <I n="b">...</I>
    <I n="c">...</I>
  </lg><!-- end of the 2nd part of the lg in question: two entire verse lines-->
  <p xml:id="ID_33.10">some dependent text here</p>
</div>
<div type="section">
  <lg xml:id="ID_33.11" prev="#ID_33.09" next="#ID_33.13" part="M">
    <I n="d" part="I">...</I>
  </lg><!-- end of the 3rd part of the lg in question: the first part of a verse line-->
  <p xml:id="ID_33.12">some dependent text here</p>
</div>
<div type="section">
  <lg xml:id="ID_33.13" prev="#ID_33.11" part="F">
    <I n="d" part="F">...</I>
  </lg><!-- end of the 4th part of the lg in question: the last part of a verse line-->
  <p xml:id="ID_33.14">some dependent text here</p>
</div>
```
Note that @part is also used in the example for the `<|>` that is interrupted by dependent prose. This encoding allows us to reconstitute stanza number 3 during processing.

However, reconstituting the stanza directly in your file is possible by making use of the aggregating element `<join/>`. For instance, if you need to recreate the stanza because you want to cite it integrally in a comment or a note, you could either copy-paste its parts, or — more sophisticatedly — use `<join/>` to gather all or some of the parts of the `<lg>` element.

### Example 4.7.2.B

```xml
<note>This is also seen in stanza 3: <join result="lg" scope="root" target="#ID_33.07 #ID_33.09 #ID_33.11 #ID_33.13"/></note>
```

The above will generate the equivalent of the following code:

### Example 4.7.2.C

```xml
<note>This is also seen in stanza 3: <lg n="3"><n="a">...</lg><n="b">...</lg><n="c">...</lg><n="d">...</lg></note>
```

Another scenario in which `<join/>` may be needed is if the order in which the dependent text presents the segments is not the one intended by the author of the stanza:

### Example 4.7.2.D

```html
<div type="chapter" n="33">
  <div type="dyad" n="15">
    <div type="section">
      <lg n="3" xml:id="ID_33.15.07" next="#ID_33.15.09" part="I">
        <l n="a">..</l>
        <l n="b">..</l>
        <l n="c">..</l>
      </lg><!-- end of the 1st part of the lg in question: three entire verse line-->
      <p xml:id="ID_33.15.08">some dependent text here</p>
    </div>
    <div type="section">
      <lg xml:id="ID_33.15.09" prev="#ID_23.15.07" next="#ID_33.15.11" part="M">
        <l n="d" part="M">...</l>
      </lg><!-- end of the 2nd part of the lg in question: an M part of verse d -->
      <p xml:id="ID_33.15.10">some dependent text here</p>
    </div>
    <div type="section">
      <lg xml:id="ID_33.15.11" prev="#ID_33.15.09" next="#ID_33.15.13" part="M">
        <l n="d" part="M">...</l>
      </lg><!-- end of the 3rd part of the lg in question: an M part of verse d -->
      <p xml:id="ID_33.15.12">some dependent text here</p>
    </div>
  </div>
</div>
```
```html
<div type="section">
  <lg xml:id="ID_33.15.13" prev="#ID_33.15.11" next="#ID_33.15.15" part="M">
    <l n="d" part="l">...</l>
  </lg><!-- end of the 4th part of the lg in question: the I part of verse d -->
  <p xml:id="ID_33.15.14">some dependent text here</p>
</div>
<div type="section">
  <lg xml:id="ID_33.15.15" prev="#ID_33.15.13" part="F">
    <l n="d" part="F">...</l>
  </lg><!-- end of the 5th part of the lg in question: the F part of verse d -->
  <p xml:id="ID_33.15.16">some dependent text here</p>
</div>
<join result="lg" scope="root" target="#ID_33.15.07 #ID_33.15.13 #ID_33.15.09 #ID_33.15.11
#ID_33.15.15"/>
</div>
</div>
```

We don't actually foresee this element being used much, and we include it here mainly to let you know it exists. If you do need to use it, contact the project's XML-TEI Data Manager.

## 4.8 Lemmas of base text in dependent text

When the dependent text refers to individual terms or snippets from the base text, called lemma in the classical philological tradition,<fnref n="41" /> resulting in an alternation of base and dependent text, without the whole base text being reconstructible on the basis of the latter, these lemmas shall be wrapped in the element <term>. It is possible to add an attribute @xml:lang to the tag, and we recommend doing so.

<caption>Example 4.8.A</caption>

```xml
<term xml:lang="san-Latn">nikşepa</term>
```

It is possible, but not mandatory, to wrap the corresponding paraphrase or gloss in <gloss>. The attributes @xml:id and @target must be used to match a <gloss> with its <term>. The attribution of identifiers to terms will be handled by an XSLT process, as with other numbering (see §7.2.1.2), although for <term> the numbering pattern will be simple incremental numbering from the beginning of the file to its end. Once the @xml:id have been assigned, you can encode the values of @target, mandatorily with prefix “#”.

<caption>Example 4.8.B</caption>

```xml
<term xml:id="term004" xml:lang="san-Latn">nikşepa</term> some text
```

<footnote n="41">⁴¹ Note that this is not exactly the same as a dictionary lemma, nor is it the same as the lemma of a critical apparatus, on which see §5.</footnote>
<gloss target="#term004">gloss</gloss>

## 5. Critical apparatus

Many experienced editors of South and Southeast Asian texts are used to seeing printed editions with multiple “layers of apparatus”, one or more of which are used to represent parallel passages.<fnref n="42" /> It is important at this juncture to understand that such “layers of apparatus” are a convention of display. Digital editions, unlike printed ones, are not limited by the spatial features of a page-based layout and do not need to use anything like “layers of apparatus” to represent the relationship between the text as constituted by the editor and his observations on particular segments of that text. What is important, is for the types of information to be conveyed to be clearly defined and for the encoding to follow the respective categories of information. Anyhow, in the TEI context, the term *apparatus* has a more limited scope than you may be familiar with, as it concerns only the encoding of variant readings or notes on readings — to the exclusion of parallels, etc. It is to the apparatus in this narrow sense that we turn now.

Printed critical editions generally present the critical apparatus at the bottom of the page or in an appendix, using reference by page/line number or by elements of intrinsic structure of the text to make clear to which segment of text any variant readings (or comments) are to be matched. The TEI offers three main methods for encoding apparatus:

1. The **location-referenced method** assembles all contents of the apparatus separately from the edition (in a different part of the same file or even in a different file), and if the correspondence of any apparatus entry to a segment of text is to be made machine actionable, this must be achieved with reference to elements of intrinsic or extrinsic structure of the edition.<fnref n="43" />

2. The **double-end-point-attached method**<fnref n="44" /> likewise assembles all contents of the apparatus separately from the edition (in a different part of the same file or even in a different file), but embeds anchors within the edition itself, to which the apparatus entries are linked.

3. The **parallel-segmentation method**,<fnref n="45" /> by contrast, embeds the contents of each entry within the edition itself, thereby avoiding the need of any linking system.

In the framework of the DHARMA project, you might use either the first method (meaning that the entries are linked to a block of text without being embedded inside it) or the third method

<footnote n="42">⁴² You will have noticed that the previous chapter has shown some of the relevant encoding strategies concerning parallel texts, and this subject will be dealt with more fully in §6.2.</footnote>

<footnote n="43">⁴³ This method is explained in EGD §9.1.2 and §9.1.3.</footnote>

<footnote n="44">⁴⁴ See TEI Guidelines, §12.2.2.</footnote>

<footnote n="45">⁴⁵ See TEI Guidelines, §12.2.3. This method is the most advantageous from the computational perspective and seems to be favored in the TEI world for multi-witness editions in terms both of the number of specific tools that presuppose it and of the projects that have been applying it.</footnote>
(meaning that the entries are embedded directly into the encoded text itself)<fnref n="46" /> as well as a combination of the two. In what follows, we cover only method 3; however, in §6.3, we introduce method 1, which is easier to encode but only useful if you are editing a verse text.

## 5.1 Structural overview

Let us imagine a text edition based on three witnesses. Below, we illustrate the different ways in which an apparatus entry might be recorded, according to the different readings of the witnesses.

### 1. Two witnesses support the adopted reading, the third witness has a different reading

Example 5.1.A

preceding text

<app>

<lem>wit="#K #L">lemma</lem>

<rdg>wit="#M">variant reading</rdg>

<note>optional observation</note>

</app>

following text

Display -

lemma] K L, variant reading M • optional observation

### 2. None of the witnesses supports the adopted reading

Example 5.1.B

preceding text

<app>

<lem>type="emn">lemma</lem>

<rdg>wit="#K">variant reading 1</rdg>

<rdg>wit="#L #M">variant reading 2</rdg>

<note>optional observation</note>

</app>

following text

Display -

lemma] em., variant reading 1 K, variant reading 2 L M • optional observation

### 3. One witness supports the adopted lemma, one reads it differently, one omits it

<footnote n="46">⁴⁶ Creating a digital edition from a printed one implies the conversion of its external apparatus to an internal one. Some exceptions may be necessary, as in the case of a printed edition with several layers of apparatus. If you find yourself in this situation, please consult the project's XML-TEI Data Manager before proceeding.</footnote>
Example 5.1.C

preceding text

<app>

<lem>wit="#K">lemma</lem>

<rdg>wit="#L">variant reading 1</rdg>

<rdg>wit="#M"><gap reason="omitted"/></rdg>

<note>optional observation</note>

</app>

following text

Display -

lemma] K, variant reading 1 L, om. M • optional observation

4. All witnesses support the adopted reading, on which an observation is made

Example 5.1.D

preceding text

<app>

<lem>wit="#K #L #M">lemma</lem>

<note>optional observation</note>

</app>

following text

Display -

lemma] K L M • optional observation

If for some reason you do not wish the witnesses to be displayed in the apparatus, you can leave them unmentioned in the <lem> but in that case you need to use the attribute @type="note" (see §5.3.2):

Example 5.1.E

preceding text

<app>

<lem type="note">lemma</lem>

<note>optional observation</note>

</app>

following text

Display -

Lemma] • optional observation
## 5. Two witnesses support the adopted reading, but one of them has a partial variant reading, while the third omits the whole segment

<table><caption>Example 5.1.F</caption><thead><tr><th>preceding text</th></tr></thead><tbody><tr><td>&lt;app&gt;<br/>&lt;lem wit="#K #L">padāny<br/>&lt;app&gt;<br/>&lt;lem wit="#K">aṣṭādaśaitāni&lt;/lem&gt;<br/>&lt;rdg wit="#L">aṣṭadaśetani&lt;/rdg&gt;<br/>&lt;/app&gt;<br/>&lt;/lem&gt;<br/>&lt;rdg wit="#M">&lt;gap reason="omitted"/&gt;&lt;/rdg&gt;</td></tr><tr><td>&lt;/app&gt;<br/>following text</td></tr><tr><td>Display —<br/><sup>1.</sup> padāny aṣṭādaśaitāni] K L, om. M.<br/><sup>2.</sup> aṣṭādaśaitāni] K, aṣṭadaśetani L, om. M (larger gap).</td></tr></tbody></table>

These five examples have introduced the elements `<app>`, `<lem>`, `<rdg>`, `<gap>` and `<note>` as well as the attributes `@reason`, `@type`, `@wit` — together, these are the most common building blocks you will use to create your apparatus entries. Some specific features require other building blocks that will be introduced below.

The element `<app>` will contain the whole apparatus entry, the first and mandatory child being `<lem>`, which is used to encode the reading of your choice, i.e., the lemma in philological terminology.<fnref n="47" /> Generally, one or more variant readings will follow and be encoded inside an element `<rdg>` although, as shown in examples 5.1.D and 5.1.E, it is possible to create `<app>` entries consisting only of `<lem>` and `<note>` without any `<rdg>`. The lemma and any corresponding variant readings or observations are to be explicitly encoded together, i.e. wrapped within `<app>`, so that their interconnectedness is computationally explicit.

As shown in the example 5.1.F, apparatus entries may be nested, to record different phenomena applying to different parts of the same larger lemma.

None of your `<app>` elements will be numbered in the XML code: depending on what kind of display is chosen, and whether there is any need, this can be done automatically once the encoding of the file is finalized. On cross-referencing to a specific `<app>`, see §5.2.4 for its usage and §7.3.1 for its explanation.

<footnote n="47">⁴⁷ Note that the term 'lemma' in this context has a different meaning from the one intended in §4.8.</footnote>
## 5.2 Which variant readings to record and which to ignore

### 5.2.1 Recording variant readings positively

In the DHARMA project, we opt for the use of a **positive apparatus**. This choice, reflected in the examples above, implies that, in any apparatus entry, all the witnesses should explicitly be listed and clearly identified, allowing the reader to be sure in every instance which witness reads what. Even though the process of encoding a positive apparatus can be more time consuming than encoding negatively, it has some advantages, among which the fact that it will enable implementing computer-aided verification of the consistency of your encoding.

This methodological requirement implies that each `<app>` should contain at least one, and normally (i.e. except in the case of scribal correction — see §5.5.13) only one instance, to be recorded with `@wit`, whether in `<lem>` (§5.3), in `<rdg>` (§5.5) or in `<witDetail>` (§5.10.2), of each witness listed in your `<listWit>` (§2.1.3). Be aware that any embedded `<app>` (see ex. 5.1F) will only inherit the witnesses declared on the embedding `<app>`.

### 5.2.2 Ignoring insignificant variant readings

An important aspect of your work as critical editor is deciding, case-by-case, whether a given variant reading for a given string of characters requires the creation of an `<app>` entry in your edition, or can simply be ignored. For instance, when all of your witnesses unanimously spell a word in a way that you wish to replace by a spelling that you consider “standard”, or when you have a variety of substandard spellings none of which is exactly the same as the one you wish to adopt as “standard”, you may deem none of the actual readings to merit being recorded as variants. In *Appendix A*, we furnish an overview of types of variants that we recommend ignoring if your are editing a Sanskrit and/or vernacular text from Java or Bali. The lists we furnish could be reused as the basis for your own further customized lists to be included in the `<editorialDecl>` of your edition (§2.2.1.1). However, bear in mind that if any variant reading needs to be recorded, then the principle of a positive apparatus requires that you represent all witnesses in your apparatus. This rule may lead you to explicitly record variant readings that you would have considered insignificant under other circumstances. However, it is also possible to abide in such a situation by the normalization rules declared in your `<editorialDecl>`: some readings can be considered to support the `<lem>` even if they are not strictly identical to it; consequently, the given witness would be encoded in `<lem>` and not in `<rdg>`. It is up to your discretion how you proceed in such situations. Perhaps the choice can be made on a case-by-case basis.

### 5.2.3 Hiding insignificant variants readings without deleting them

We offer you a way to experiment with the granularity of your editorial policy by applying the attribute `@rend="hide"` that may be used on any element `<app>`. Its effect is to only display the content of the `<lem>` without generating an apparatus entry. We foresee that this may be useful
if you initially create `<app>` entries to represent types of variant readings that you subsequently deem not to pass the threshold of significance for being included in your edition's apparatus. In this way, you will be able to reduce the number of apparatus entries so that only the more significant appear in the display, without needing to remove from the file itself the collation of the various witnesses once it has been made.

<table><caption>Example 5.2.3.A</caption><tr><td>sira dumadyakən vṛddhiniṁ janma kabeh,<br/><code>&lt;app rend="hide"&gt;</code><br/><code>&lt;lem type="norm"&gt;prāṇaprāṇī&lt;/lem&gt;</code><br/><code>&lt;rdg wit="#msjb"&gt;praṇapraṇī&lt;/rdg&gt;</code><br/><code>&lt;rdg wit="#msba"&gt;praṇapraṇi&lt;/rdg&gt;</code><br/><code>&lt;rdg wit="#msbb"&gt;pranaprani&lt;/rdg&gt;</code><br/><code>&lt;/app&gt;</code></td></tr><tr><td>sarva hurip,<br/><br/><code>Display —</code><br/><code>text</code><br/><code>sira dumadyakən vṛddhiniṁ janma kabeh, prāṇaprāṇī sarva hurip,</code><br/><code>apparatus</code><br/>Not shown</td></tr></table>

## 5.2.4 Strategies to encode apparatus entries across block boundaries

Textual variants can occur at different levels of the text: although you will most frequently be encoding variants at the phrase level, they may just as well occur at a higher structural level, pertaining to verse lines or even whole stanzas, paragraphs or sections (`<div>`). If such a phenomenon occurs within your text, you need to exercise extra care while encoding the relevant apparatus entries, especially in case of a nested entry.

When your apparatus entry straddles a block-level container, such as `<div>`, `<p>`, `<ab>`, `<lg>` or even `<l>`, you might need to break it into two or more segments depending on its length. When this happens, you will have to provide an `@xml:id` consisting of the letters "app" followed by an incremental number formatted as a 5-digit number and add after an underscore a lower-case letter to identify the subparts. Once each part is clearly identified, you can link all the subparts together with the attribute `@prev` and `@next`, following the same mechanism that is used when a block level container is broken down to fit the base-text. See §7.2.1.2.

<table><caption>Example 5.2.4.A</caption><tr><td>&lt;div&gt;</td></tr><tr><td>&lt;p&gt;[...]</td></tr></table>
<app xml:id="app00001_a" next="#app00001_b">...</app>
</p>
</div>
<div>
<p>
<app xml:id="app00001_b" prev="#app00001_a">...</app>
[...]</p>
</div>

## 5.3 The lemma

Within the element <app>, the adopted reading (or emendation/conjecture) with regard to which you are going to record one or more variant reading(s) and/or formulate a note is to be wrapped in the element <lem>.<fnref n="48" />

### 5.3.1 Extent of the lemma

There are no strict rules for the extent of your lemmas. Lemmas should remain sufficiently concise for the difference(s) between them and variant readings to stand out in your apparatus. There is no upper limit on the extent of a lemma. Indeed it may well occur that your lemma must extend over two or more adjoining words. Regarding the lower limit, your lemma should preferably consist of minimally a single whole word, but truncation of words is also admissible (§5.3.1.2), should the need arise.

In case of variation that involves multiple words, it is recommended to delimit your lemma in such a way as to include the first and last elements (normally, words) that are common to the lemma and all variant readings. See ex. 5.3.1.1.C and ex. 5.5.5.3.A for instance.

Metrical considerations will sometimes come into play: in a Sanskrit work in *anuṣṭubh* for which there are a large number of witnesses and lots of variants, it can make sense to take by default as the lemma the text of a complete eight-syllable quarter-verse (*pāda*), rather than producing five or six little *lemmata* for each half-line.

#### 5.3.1.1 Ellipsis in the lemma's display

If you prefer any long lemmas to be shortened when displayed in the critical apparatus, you will not be able to indicate the shortened form inside <lem> itself, since we need a record of it in its full length to be displayed in the text edition. Instead, after recording the lemma in full with the element <lem>, insert an element <note> with a specific attribute @type="altLem" to express the truncated form of the lemma.<fnref n="49" /> Let's imagine this lemma:

<footnote n="48">⁴⁸ Note that DHARMA has chosen not to allow declaring the empty element <lem/> in its encoding model for omissions and interpolation. See *TEI Encoding Guidelines*, §12.4.</footnote>

<footnote n="49">⁴⁹ We present here the solution offered by Marjorie Burghart in her contribution “Textual Variants” to *Digital Editing of Medieval Manuscripts: A Textbook*, edited by Marjorie Burghart, Elena Pierazzo and James Cummings (2014–2017), p. 20.</footnote>
Example 5.3.1.1.A

<app><lem>saṅ brāhmaṇa saṅ vruh riṇ aṣṭādaśavyavahāra,</lem></app>

If you desire in the apparatus the specific display saṅ brāhmaṇa ... -vyavahāra, then you must encode as follows.

Example 5.3.1.1.B

<app>
  <lem>saṅ brāhmaṇa saṅ vruh riṇ aṣṭādaśavyavahāra,</lem>
  <note type="altLem">saṅ brāhmaṇa ... -vyavahāra</note>
  <rdg>wit="#A">...</rdg>
  <rdg>wit="#B">...</rdg>
</app>

Note that you may simply type three full stops (...): the XSLT transformation will replace them by the proper ellipsis symbol (... U+2026).

As shown in the following, much more complex example, any <note type="altLem">
should be placed immediately after the <lem> to which it applies. By contrast, any "normal"
<note> should be the last child of <app> (see §8.2.1).

Example 5.3.1.1.C

... śūdra,
<app>
  <lem>wit="#A #C">macaṅkramāta riṇ patapan, amava sabhūṣaṇanya,
    sakavava ri patapan atah, pramāṇa sabhūṣaṇanya, kavāva riṇ patapan,
    tan kilalanən de saṅ ratu, tan kavāva riṇ rāma, tan ucapən deniṅ śūdra,
    ṅuniveḥ
  </lem>
  <app>
    <lem type="emn">sabanva</lem>
    <rdg>wit="#A #C">saṁ banva</rdg>
  </app>
  uṅgvānira,
  <app>
    <lem type="conj">salinaraṇan</lem>
    <rdg>wit="#A #C">valilaraṇan</rdg>
  </app>
  salinaraṇan
</app>
<app> saṅ prabhu</lem>
<note type="altLem">macaṅkramāta ... saṅ prabhu</note>
<rdg>wit="#B"><gap reason="omitted"/></rdg>
<note>The reading of <ptr target="#B">, jumping directly from <foreign>śūdra</foreign> to
<foreign>salviranya</foreign>, seems equally satisfactory.</note>
</app>
salviranya ...

Display —

text

... śūdra, macaṅkramāta riṅ patapan, amava sabhūṣaṇanya, sakavava ri patapan atah, pramāṇa sabhūṣaṇanya, kavāva riṅ patapan, tan kilalanən de saṅ ratu, tan kavāva riṅ rāma, tan ucapən deniṅ śūdra, ṅuniveh sabanva uṅgvānira, salinaraṇan saṅ prabhu, salviranya, ...

apparatus

^287. macaṅkramāta ... saṅ prabhu] **A C**, om. **B** • The reading of **B**, jumping directly from śūdra to salviranya, seems equally satisfactory.

^288. sabanva] em., saṁ banva **A C**, om. **B** (larger gap).

^289. salinaraṇan] conj., valilaraṇan· **A C**, om. **B** (larger gap).

### 5.3.1.2 Truncation

It may be impossible or undesirable for the lemma boundary to be made to match with the most proximate word boundaries. In such cases, we offer the following ways to bring about display of a hyphen or of a raised circle to mark the point(s) of truncation, whereby hyphen shall mark natural truncation points (i.e. points where you would use hyphen if you would hyphenate your text) while raised circle shall mark any points that are not natural points for hyphenation. You must then use `@rend` inside `<lem>`, with one of the following six values:

* hyphenleft, hyphenright, hyphenaround

* circleleft, circleright, circlearound

**Example 5.3.1.2.A**

```
anya<app><lem type="emn" rend="hyphenleft" wit="#M">tobhāve</lem><rdg wit="#K #L">-tobhuve</rdg></app>
```

Display —

^1. -tobhāve] **M**, -tobhuve **K L**.

The needed hyphen before lemma *tobhāve* will be inserted by the transformation script, but in order to keep full control over display of `<rdg>`, no automatic insertion of any kind will apply to its contents. This is why you need to type the hyphen in `<rdg>`, as in `-tobhuve` in the example.

If your text edition systematically hyphenates compounds, and you wish to truncate at a break in a compound, then you have at your disposal the following two equivalent ways of bringing about proper display of the required hyphen in edition and apparatus:

**Example 5.3.1.2.B**
```
asvāmi <app> <lem type="emn" rend="hyphenleft">vikraya</lem> <rdg wit="#L #K">vikriya</rdg></app>
 <!-- if using @rend="hyphenleft", you need to type a hyphen outside of <lem> while typing one inside of <rdg> -->
```

```
asvāmi <app> <lem type="emn">vikraya</lem> <rdg wit="#L #K">vikriya</rdg></app>
 <!-- if not using @rend="hyphenleft", you simply type the hyphens at the start of both <lem> and <rdg> -->
```

Comparison of the two suggests that recourse to `@rend="hyphenleft"` will be less useful in the case of a fully hyphenated text edition.

The encoding of truncation at unnatural points is strictly analogous, except that here the issue of interaction with editorial hyphenation will never arise.

### Example 5.3.1.2.C

```
any <app> <lem rend="circlearound" wit="#M">atobh</lem> <rdg wit="#K #L">°atheb°</rdg></app>āve
```

Display —

1. °atobh°] M, °atheb° K L.

Note that none of the uses of `@rend` in the preceding examples can be applied to a `<note>` with `@type="altLem"`. Should you require hyphens or raised circles in the display of the alternative lemma, you should explicitly type them in the contents of the `<note>`, as you need to do in `<rdg>`.

It may not, finally, be superfluous to point out explicitly that the extent of a variant reading should always correspond exactly to the extent of the lemma. In other words, you should never truncate an `<rdg>` if you do not truncate the corresponding `<lem>`, or truncate the `<rdg>` otherwise than you truncate the `<lem>`.

## 5.3.2 @type values usable with <lem>

If the adopted reading is not directly supported by any of the witnesses, then you must apply to the `<lem>` an attribute `@type`. The labels to express basic philological statements as to the status of the lemma are "norm", "emn" and "conj".

* "norm" — **Normalization** means any alteration to the text as transmitted in the witnesses in order to make it compliant with what is perceived as standard, without any of the actual readings being deemed to constitute a significant variant. Note that this `@type` will only be needed if for some reason you deem it useful to report any readings that do not constitute significant variants, because otherwise you would not be creating any `<app>` for the given segment of text at all (§5.2.2).

* "emn" — **Emendation** refers to a reading that is proposed by the editor to stand instead of the transmitted readings if these are deemed unacceptable, based on evidence that is deemed to point quite certainly to this specific choice of reading.
* "conj" — **Conjecture** means a reading that is proposed by the editor to stand instead of the transmitted readings if these are deemed unacceptable, or to fill in transmissional lacunae, without the editor disposing of strong supporting evidence for the specific alteration as opposed to other imaginable choices of reading.

Admittedly, the distinction between conjecture and emendation is not always sharp and can be
rather subjective. Some editors indeed do not make the same three-way distinction, but we
recommend it for critical editions produced by the DHARMA project. Here are some examples of
how the @types can be used:

Example 5.3.2.A

<app>
  <lem type="emn">pariśrānto 'pi</lem>
  <rdg wit="#B #C">pariśrānte 'pi</rdg>
  <rdg wit="#D"><gap reason="omitted"/></rdg>
</app>

Example 5.3.2.B

<app>
  <lem type="conj">pariśrānto 'pi</lem>
  <rdg wit="#B #C">pariśkṛto 'pi</rdg>
  <rdg wit="#D"><gap reason="lost"/></rdg>
</app>

We provide three further @type values, whose *raison d'être* is not only connected with
philological appreciation of the status of the lemma but also with logical requirements of the TEI
encoding model. These values are:

* "reformulated_elsewhere" — described in §5.5.6, this @type implies that you are adopting a lemma that is not attested as such in any witness but that is not deemed an emendation either, for instance a lemma that mixes the word order from one witness with the specific reading of one or more words from another witness.

* "omitted_elsewhere" — described in §5.5.9, this @type makes it possible on the one hand to oppose those witnesses which omit the whole segment to those which transmit it in some form while on the other hand allowing you to avoid giving the impression that there is no variation of reading for the lemma among the latter.

* "lost_elsewhere" — described in §5.5.11, this @type is intended to represent that one witness is affected by a larger lacuna, while the other witnesses keep transmitting variants.

* "note" — illustrated in §5.1, no 4 and §5.10.1, this type serves to indicate that the `<app>` entry in question contains only a `<note>` besides the `<lem>`, especially that it does not
contain any <rdg>. Use of this @type may or may not be accompanied by use of @wit
on the <lem>.

From the point of view of the model, these values of @type allow you not to declare any @wit
on <lem> and so to circumvent the problem of inheritance of values of @wit.<fnref n="50" />

## 5.4 Recording witnesses

If the adopted reading is supported by a witness (whether because the adopted reading is found
as such in one or more of the witnesses or can be obtained by applying your normalization
rules), then apply the attribute @wit inside <lem> using as its value the identifier of the relevant
witness or witnesses as declared in the <sourceDesc> (see §2.1.3), preceded by the "#" that is
needed to make the link to the list of sigla defined in your <listWit>. However, be careful not to
refer to a family of witnesses and one of its members in the same attribute @wit. Any alternative
readings corresponding to the adopted <lem> are to be reported by wrapping each one in its
own element <rdg> and recording the relevant witness or witnesses in the same way as is done
in <lem>.

<caption>Example 5.4.A</caption>

```xml
<app>
  <lem wit="#A #C">aṣṭādaśaitāni</lem>
  <rdg wit="#B">aṣṭadaśetani</rdg>
</app>
```

In the next section, we will discuss in detail how to record variant readings.

## 5.5 Variant readings

In this section, you will find discussion of various specific features of our use of the element <rdg> in such cases as unclear or illegible readings, scribal additions and deletions, omissions due to scribal intervention or error, and lacunae due to physical deficiency of a witness.<fnref n="51" /> Other phenomena such as interpolations or transpositions will be found in other sections of this guide, §5.6, and §5.8, as will instruction on how to supply untransmitted text segments, §5.7.

### 5.5.1 Quote witnesses as diplomatically as possible

When quoting a reading from a witness for which you have a TEI-encoded diplomatic edition, using what is called “strict transliteration” in the project’s Transliteration Guide, you should copy verbatim from that diplomatic edition, paying attention to the following issues:

<footnote n="50">⁵⁰ https://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCAPSU</footnote>

<footnote n="51">⁵¹ Note that DHARMA has chosen not to allow declaring the empty element <rdg/> in its encoding model for omissions and interpolation. See TEI Encoding Guidelines, §12.4.</footnote>
* you may remove any milestone elements (`<lb/>` and `<pb/>`)<fnref n="52" /> if their presence has no incidence on the nature of the variant reading, but keep them if their presence seems relevant; you may copy them as they are in the file for your diplomatic edition along with any attributes (`@n` and `@break`) they bear.

* be aware of start-tags and end-tags:

* add the start-tag for retained markup commencing before and ending inside your lemma;

* add the end-tag for retained markup commencing inside your lemma and ending after it;

* add start and end-tags for a lemma snipped from within a longer stretch of phrase-level markup.

If you do not have a separate TEI-encoded diplomatic edition, then represent the reading of the witness in question in strict transliteration, adapting the transliteration scheme of any published edition to DHARMA norms and citing any manuscript readings reported in a published edition as diplomatically as you can or with as much normalization as you deem necessary/useful, depending on the case.

### 5.5.2 Highlighting segments affected by variation

If more than one variant affects a lemma, it is possible to wrap the affected segments in the element `<seg>` to enable rapid identification of the segments of the `<lem>` affected by variation of reading encoded in the corresponding elements `<rdg>`. Apply the attribute `@type` with value `"highlight"` to such elements `<seg>`.

<caption>Example 5.5.2.A</caption>

```xml
<app>
  <lem>wit="#A #C">aṣṭādaś<seg type="highlight">ai</seg>tāni</lem>
  <rdg>wit="#B">aṣṭādaś<seg type="highlight">e</seg>tāni</rdg>
</app>
```

Display —

1. aṣṭādaśaitāni A C, aṣṭādaśetāni B

### 5.5.3 Encoding causes of variance of reading

It is possible to implement a classification of the conscious interventions as well as the unconscious errors of scribes through the use of the attribute `@cause` on a rejected `<rdg>`. It may, for instance, be useful to mark readings which are identical in meaning to the adopted

<footnote n="52">⁵² For more about milestone elements, we refer to §8.1 in this Guide.</footnote>
lemma but express it through a different lexeme or with different (yet equivalent) morphological
means. The values we propose for @cause are the following:<fnref n="53" />

* eye-skip (see §5.5.9)

* line_omission (see §5.5.9)

* haplography

* dittography

* lexical: the reading differs from the lemma by offering an entirely different lexeme

* orthographical: the reading differs from the lemma only in spelling (i.e., not in any grammatically significant way)

* morphological: the reading differs from the lemma in its grammatical form

* transposition: the reading changes the order in which text segments (letters/syllables, words, forms, phrases, sentences, lines) occur in the lemma

* syntactic: the reading differs from the lemma in its grammatical construction or arrangement

* subtractive: omission of some unit of text through oversight, erasure, or some other cause — use eye-skip or haplography if one of those two seems to be the specific cause

* additive: an interpolation, i.e., some text judged by the editor to have entered the tradition through the mistaken or deliberate copying of auxiliary material (e.g., glosses, marginalia, etc.) — use dittography if that seems to be the specific cause

Here is an example of a lexical variant, where the *prabu* in two witnesses is a synonym of *ratu* in the witness that supports the lemma. The grammatical constructions are also slightly different (with suffix *-niš* before *ratu* in the lemma against free-standing morpheme *saṁ* before *prabu* in the rejected reading), but the editor has here chosen not to encode that type of variation nor even to remark upon it in a `<note>`, though that would have been possible.

<caption>Example 5.5.3.A</caption>

dravya<app>
<lem rend="hyphenleft" wit="#L">niš ratu</lem>
<rdg>wit="#K #M" cause="lexical">saṁ prabu</rdg>
</app>
tinuvavakən,

In the following example, the only significant difference between the rejected reading and the lemma is that the same words are arranged differently, which the editor has decided to underline with the attribute @cause="transposition".

<footnote n="53">⁵³ We adopt most of the values and definitions from the Digital Latin Library Guidelines, §12.15 Tagging Readings for Analysis. Note, however, that the Digital Latin Library offers these values to be used with the attribute @ana, while we have favored @cause. On this point, we follow the TEI Guidelines, where the following values are proposed: homeoteleuton, homeoarchy, paleographicConfusion, haplography, dittography, falseEmendation. See §att.textCritical.</footnote>
<caption>Example 5.5.3.B</caption>

<app>
  <lem>wit="#K #M">likhita, sākşi, bhukti</lem>
  <rdg>wit="#L" cause="transposition">sakşi, likittha, bhūkti</rdg>
</app>

See also §5.8 for this and other scenarios of transposition of text segments. Contact the project's XML-TEI Data Manager if the proposed values of @cause do not meet your requirements.

5.5.4. Grouping variant readings

The TEI model offers the possibility of grouping variant readings based on their classification
with the element <rdgGrp>. We have not made any concrete recommendations for its use in this
guide. Nonetheless, encoding groups of variant readings with <rdgGrp> may be useful in
analyzing the proximity or divergence between the respective witnesses. If you see any use for
it in your edition, please contact the XML-TEI Data Manager. Note that it is possible to use it
only on a few apparatus entries deemed particularly revealing.

The <rdgGrp> element should always be used inside an <app> entry after the <lem>. All variant readings need to enter one of the groups thus established (no <rdg> element can be declared as a sibling of <lem>, all must be descendants of an <rdgGrp>). Add an attribute @cause to the <rdgGrp> to make explicit that a given group of variants belong to the same class of variants (see §5.5.3).

<caption>Example 5.5.3.A</caption>

<app>
  <lem>wit="#EI #Ra2">though</lem>
  <rdgGrp cause="orthographic">
    <rdg>wit="#La">thogh</rdg>
    <rdg>wit="#Hg">thouh</rdg>
  </rdgGrp>
  <rdgGrp cause="lexical">
    <rdg>wit="#Lb">although</rdg>
    <rdg>wit="#Hh">whereas</rdg>
  </rdgGrp>
</app>

5.5.5 Encoding readings *ante* and *post correctionem*

Even after a scribal intervention, it is often possible to determine how a witness read before a
scribe intervened to correct it. This is conventionally called the *ante correctionem (ac)* reading,
while the result of correction is conventionally labeled *post correctionem (pc)*. There are major
advantages to encoding the before/after reading each in its own <rdg>, namely:

* that either one may also be attested in another witness and that it will be consistent with our general approach in recording variant readings to mark agreement between two or more witnesses on a single reading by associating all those witnesses to a single <rdg> through @wit.

* that the *scribal correction* may be the result of the intervention of a hand distinct from the hand that was responsible for the initial reading, a fact that could not be represented if you made use of `<choice><sic>...</sic><corr>...</corr></choice>` as is done for *editorial interventions* in the project's epigraphic editions.

Before we move on to showing how you can apply the labels *ac* and *pc* to the before and after readings, we must emphasize that we do not see any objection to ignoring *ac* readings if they are not found as such in any other witness and if you encode the *pc* reading in `<lem>` — in other words, if you believe the scribe did not see the *ac* reading in any manuscript from which he was copying and agree with the correction that he made. Another situation in which you may feel free to ignore the *ac* reading (or leave unmarked that a given `<rdg>` is *pc*) is when it has become irrecoverable in the course of the scribal process of correction.

However, there will often be situations where you wish to encode both *ac* and *pc* readings, most especially if it is the former that supports the text you accept in `<lem>`. Let's say you are aiming at a result that, in print, would resemble the following:

vijayaḥ P<sub>pc</sub> Q] vajayaḥ P<sub>ac</sub> vajayo R

You should then make use of the element `<witDetail>` (see §5.10.2) which can be linked to a reading as well as to one or more witnesses for that reading, or even to a specific hand responsible for a given reading. The link is inferred from the element's position, immediately after the element `<lem>` or `<rdg>` bearing the attribute @wit for the witness in which a correction has occurred.<fnref n="54" />

<table><caption>Example 5.5.5.A</caption><tr><td>&lt;app&gt;</td></tr><tr><td>&lt;lem wit="#P #Q">vijayaḥ&lt;/lem&gt;</td></tr><tr><td>&lt;witDetail wit="#P" type="pc"/&gt;</td></tr><tr><td>&lt;rdg wit="#P">vijayaḥ&lt;/rdg&gt;</td></tr><tr><td>&lt;witDetail wit="#P" type="ac"/&gt;</td></tr></table>

<footnote n="54">⁵⁴ A draft version of this guide also allowed the use of @varSeq, i.e. varSeq="1" for ante correctionem and varSeq="2" for post correctionem readings. We have removed this possibility since it didn't seem to bring any versatility to the encoding that is not also furnished by use of <witDetail/>. If you need its reintroduction for a case you can't fully express with <witDetail/>, contact the project's XML-TEI Data manager.</footnote>
<rdg wit="#R">vajayo</rdg>
</app>

Display -

^1. vijayaḥ] P<sub>pc</sub> Q, vajayaḥ P<sub>ac</sub>, vajayo R

Example 5.5.5.B

<app>
  <lem>wit="#P #Q">vijayaḥ</lem>
  <witDetail>wit="#P" type="pc"/>
  <rdg>wit="#P">v<subst><del>a</del><add>place="above">i</add></subst>jayaḥ</rdg>
  <witDetail>wit="#P" type="ac"/>
  <rdg>wit="#R">vajayo</rdg>
</app>

Display -

^1. vijayaḥ] P<sub>pc</sub> Q, v([a]i)jayaḥ P<sub>ac</sub>, vajayo R

The following examples concern a scenario where the correction was applied by a second hand, and in the last example this fact is the object of an editorial comment:

Example 5.5.5.C

<app>
  <lem>wit="#P #Q" hand="#P_H2">vijayaḥ</lem>
  <witDetail>wit="#P" type="pc"/>
  <rdg>wit="#P" hand="#P_H1">vajayaḥ</rdg>
  <witDetail>wit="#P" type="ac"/>
  <rdg>wit="#R">vajayo</rdg>
</app>

Display -

^1. vijayaḥ] P<sub>pc-sm</sub> Q, vijayaḥ P<sub>ac-pm</sub>, vajayo R

Example 5.5.5.D

<app>
  <lem>wit="#P #Q" hand="#P_H2">vijayaḥ</lem>
  <rdg>wit="#P" hand="#P_H1">vajayaḥ</rdg>
  <witDetail>wit="#P" type="ac"/>
  <rdg>wit="#R">vajayo</rdg>
  <note>In <ptr target="#P"/>, the second hand has added the i-vowel marker.</note>
</app>
</app>

Display -

^1. vijayaḥ] P<sub>pc-sm</sub> Q, vajayaḥ P<sub>ac-pm</sub>, vajayo R • In P, the second hand has added the i-vowel marker.

As you can see in the examples, it is possible, within the `<rdg>` elements, to make use of the full gamut of elements described in the chapter on the "Representation of primary sources" of the TEI Guidelines. In the examples above, we have used `<gap>`, `<del>` and `<add>`. For more on these elements, see §5.5.7 through §5.5.13.

### 5.5.6 Encoding a rejected branch of transmission

Should you face a scenario where different (groups of) witnesses offer different formulations (e.g., ordering of words) for a given segment, you will be forced to accept one and reject one or more other formulations, or propose a reading that is not attested as such in any of the witnesses. In the latter case, you may be forced to emend in a manner not supported by any witness, but the reading of the segment retained in your edition may also be a compromise between varying branches of transmission. If your reading is indeed based to a significant extent on one branch of transmission, while another branch shows a reformulation stretching over multiple words, you can indicate this by assigning the attribute `@type="reformulated_elsewhere"` to the `<lem>` in your edition. At the moment, we foresee two specific scenarios in which this attribute must be used.

#### 5.5.6.1 Adopting the formulation from one branch but a reading from another

Should you wish to adopt the overall formulation of one branch of transmission while still needing a reading from a rejected branch for a specific word that is part of the segment reformulated in that branch, then you may encode the situation along the lines of the following example:

<caption>Example 5.5.6.1.A</caption>

```xml
<app>
  <lem type="reformulated_elsewhere">ḍaṇḍa saṅ prabhu,
    amaṅgih <app><lem>wit="#L">duryaśa</lem><rdg>wit="#K #M">ḍūryyaşan</rdg></app> sira,
  <app><lem>wit="#K">amaṅgih</lem><rdg>wit="#L">hamaṅguḥ</rdg><rdg>wit="#M">amaṅguḥ</rdg></app>
  pāpa</lem>
  <witDetail>wit="#K #M" type="retained"/>
  <note type="altLem" rend="hyphenright">ḍaṇḍa saṅ prabhu ... amaṅgih pāpa</note>
  <rdg>wit="#L">ḍeṇḍa, hamaṅguḥ dūryyaşa: saṁ prabhū, makadḍi hamaṅguḥ papa:-</rdg>
  <note>The <ptr target="#L"/> reading is smoother with regard to the placement of <foreign>saṅ prabhu</foreign>; we have nevertheless decided to adopt the word order and punctuation of <ptr target="#K #M"/>. The somewhat awkward placement of <foreign>saṅ prabhu</foreign> could be smoothened by moving the punctuation mark to stand before instead of after <foreign>saṅ prabhu</foreign>.</note>
</app>
```
Display —

text

łaŋda saŋ prabhu, amaŋgih duryaśa sira, amaŋgih pāpa

apparatus

^785.łaŋda saṇ prabhu ... amaṅgih pāpa] Thus formulated in K M, dēṇḍa, hamaṅguḥ dūryyaṣa: saṁ prabhū, makadḍi hamaṅguḥ papa: L • The L reading is smoother with regard to the placement of saṇ prabhu; we have nevertheless decided to adopt the word order and punctuation of K M. The somewhat awkward placement of saṇ prabhu could be smoothened by moving the punctuation mark to stand before instead of after saṇ prabhu.

^786. duryaśa] L, dūryyaṣan K M

^787. amaṅgih] K, hamaṅguḥ L, amaṅguḥ M

In the <app> for the passage which is reformulated in some witness(es), the element <lem> that
bears the attribute @type="reformulated_elsewhere" doesn't take any attribute @wit. Rather,
the witness(es) which furnish(es) the basic structure of your lemma should be declared in a
<witDetail type="retained"/> following the main <lem> and before any <note type="altLem">,
should you need one (see §5.3.1.1). The integral reading(s) of the witness(es) showing
reformulation are represented in <rdg>. You can then cite all witnesses in any <app> that needs
to be included within the <lem> marked with @type="reformulated_elsewhere". The reason for
declaring the witness(es) whose formulation is retained in <witDetail/> rather than in <lem> is
connected with the logic regarding inheritance of the attributes: to allow embedding an <app> in
a <lem> all the witnesses must have been indicated in the parent <app>, which isn't the case
here. That's why we need to declare the witnesses in a different manner than usual.

5.5.6.2 Adopting the formulation from one branch but a reading from another across boundaries

Should you need to declare a reformulation on a larger segment of text crossing block-level
containers, use the element <span type="reformulationStart"/> and <span
type="reformulationEnd"/>. Unlike the twin elements <span type="omissionStart"/> and <span
type="omissionEnd"/>, we don't expect them inside an <app> entry. The <span/> should be
used as an anchor to declare the beginning and the end of the reformulation. In order to match
the start element with the end element corresponding to it, any <span
type="reformulationStart"/> should be given an @xml:id formed on the abbreviated term
"reform" followed by a three-digit incremental number. The <span type="reformulationEnd"/>
should be linked to it with the attribute @corresp with the value of the @xml:id preceded by "#".
These attributes are mandatory in order to match the reformulation's boundaries correctly,
because it may happen that two or more start/end pairs come to overlap. An <app> entry should
be opened right after the <span type="reformulationEnd"/>. It should contain an element <lem>
associated with the witness whose reformalation has been kept in an attribute @wit and
identified clearly with the attribute @type="retained". The rejected variants can be encoded as
usual with the element <rdg> (see §5.5) and the <app> may also contain any necessary <note>
(see §5.10.1).
adopted. In such a scenario, you may record the underlying reading that you have observed but decided not to adopt in your edited text, as a <rdg> with @type="paradosis" and @wit for all the witnesses that reflect this reading.<fnref n="55" />

### Example 5.5.6.3.A

```html
<app>
```

```html
<lem>wit="#L">śeṣaniṁ daṇḍa, śeṣaniṁ *tukon, ika tan tumusa riṅ anak putuniṅ ahutaṅ</lem>
```

```html
<note type="altLem">śeṣaniṁ tukon ... anak putuniṅ ahutaṅ</note>
```

```html
<rdg>wit="#K">śeṣaniṁ daṇḍa, śeṣa vlan, Ika ta kabeḥ, yan matikaṁ mahutaṁ, tan yogya tagihen hanaknya</rdg>
```

```html
<rdg>wit="#M">sesaniṁ, sesa velyan, ika ta kabeḥ yan mati kaṁ mahutaṁ, tan yogya tagihen anaknya</rdg>
```

```html
<rdg type="paradosis" wit="#K #M">śeṣaniṁ daṇḍa, śeṣa vlyan, ika ta kabeḥ, yan matīkaṇ mahutaṇ, tan
yogya tagihen hanaknya</rdg>
```

```html
<note>The two alternative ways of reading the last sentence, represented respectively by <ptr target="#L"/>
and <ptr target="#K #M">, seem equally acceptable. It is remarkable that where <ptr target="#L"/> reads
<foreign>śeṣaniṁ tukon</foreign>, <ptr target="#K #M"/> seem to reflect <foreign>śeṣa vlyan</foreign> in their
hyparchetype, while they agree with <ptr target="#L"/> on reading <foreign>śeṣaniṁ daṇḍa</foreign>. There is
external textual evidence in Perpusnas L882 (<foreign>mvah hutaṅ tan kaliliranā deniṅ putra, hutaṅ tan paputra,
hutaṅ totohan, śeṣadaṇḍa, hutaṅ tukon, hutaṅ sajāṅ</foreign>) that might support conjecturing <foreign>śeṣa
daṇḍa</foreign> in our text. There is also evidence that <foreign>tukon</foreign> and <foreign>velyan</foreign>
were felt to be equivalent in this genre of literature (UBL Or 5037 <foreign>ana vvaṅ istrī linamar saptapayu
sinrahan ikaṅ tukon mati taṅ istrīkaṇ sinrahan tukon velyan ika si bañavan ika tan vañsulakna ikaṅ
tukon</foreign>).</note>
```

```html
</app>
```

### Display -

¹1040. Śeṣaniṁ tukon ... anak putuniṅ ahutaṅ] Thus formulated in L, śeṣaniṁ daṇḍa, śeṣa vlan, Ika ta kabeḥ, yan matikaṁ mahutaṁ, tan yogya tagihen hanaknya K, sesaniṁ, sesa velyan, ika ta kabeḥ yan mati kaṁ mahutaṁ, tan yogya tagihen anaknya M, śeṣaniṁ daṇḍa, śeṣa vlyan, ika ta kabeḥ, yan matīkaṇ mahutaṇ, tan yogya tagihen hanaknya K M • *Paradosis* of K M: śeṣaniṁ daṇḍa, śeṣa vlyan, ika ta kabeḥ, yan matīkaṇ mahutaṇ, tan yogya tagihen hanaknya • The two alternative ways of reading the last sentence, represented respectively by L and K M, seem equally acceptable. It is remarkable that where L reads śeṣaniṁ tukon, K M seem to reflect śeṣa vlyan in their hyparchetype, while they agree with L on reading śeṣaniṁ daṇḍa. There is external textual evidence in Perpusnas L882 (mvah hutaṅ tan kaliliranā deniṅ putra, hutaṅ tan paputra, hutaṅ totohan, śeṣadaṇḍa, hutaṅ tukon, hutaṅ sajāṅ) that might support conjecturing śeṣa daṇḍa in our text. There is also evidence that tukon and velyan were felt to be equivalent in this genre of literature (UBL Or 5037 ana vvaṅ istrī linamar saptapayu sinrahan ikaṅ tukon mati taṅ istrīkaṇ sinrahan tukon velyan ika si bañavan ika tan vañsulakna ikaṅ tukon).

## 5.5.7 Encoding (segments of) a reading as unclear

Many manuscripts contain text that is difficult to read. It might be a single grapheme, a word, a sentence or even longer passages. You may use the element <unclear> to represent unclearness (and degrees of unclearness) of reading.<fnref n="56" /> Note that the only child allowed within

<footnote n="55">⁵⁵ We are slightly adapting the term “paradosis” here from the way it is used in M. L. West, *Textual Criticism and Editorial Technique* (1973), pp. 53–59.</footnote>

<footnote n="56">⁵⁶ EGD §5.3.1.</footnote>
`<unclear>` is `<g/>`; in case the unclear segment straddles some other TEI element, the unclear text around it must be wrapped separately in `<unclear>`.

To encode a segment that would be illegible out of context (e.g. because of physical damage or sloppiness of the scribe), but as to whose reading you are quite confident in the context, use the element `<unclear>` without any attributes.

Example 5.5.7.A

```xml
<rdg wit="#L642">ya ta mas <unclear>ı̈kṛt</unclear> masəkar vañva</rdg>
```

You can use the attribute `@reason` with the value `"eccentric_ductus"` if your confidence regarding the reading is affected by any unusual or incomplete aspect of a glyph.

Example 5.5.7.B

```xml
<app>
  <lem wit="#L642">ceva masva ceva mibuḥ</lem>
  <rdg wit="#L633">cava<unclear reason="eccentric_ductus">ma</unclear>so sevavibu</rdg>
</app>
```

Any tentative reading can be indicated using the attribute `@cert`, the only admitted value for which is "low".<fnref n="57" /> You can encode segments whose reading is ambiguous with `<choice>` and `<unclear>`.<fnref n="58" /> If the given portion is really impossible to read, you can use the element `<gap/>` element with `@reason="illegible"` as described in the following section.

### 5.5.8 Encoding (segments of) a reading as illegible

When the reading corresponding to a given lemma in a witness is wholly or partially illegible (e.g. because of physical damage or extreme sloppiness of the scribe), then encode the illegible segment in `<gap>` with the value `"illegible"` for `@reason` inside the `rdg` for the relevant witness. In this case, you will typically be able to know or estimate the number of illegible characters, and need to specify `@quantity` and `@unit` within `<gap reason="illegible"/>`. Here, `@quantity` must express the number of lost characters in numerical form. The default value for the attribute `@unit` is set on `"character"` (which must be understood to mean a whole *akṣara in our context*), but it can also be used with the value `"component"` depending on the case.<fnref n="59" /> If you estimate the number of illegible characters, add an attribute `@precision` with the value `"low"` to underline the uncertainty. It is also possible to use `@extent="unknown"` with the attribute `@unit="character"`.

<footnote n="57">⁵⁷ In other words, we exclude the values `"medium"` and `"high"` foreseen by the TEI, especially because a hypothetical `@cert="high"` would mean that you do not need to encode `<unclear>` at all. See EGD §5.3.2.</footnote>

<footnote n="58">⁵⁸ See EGD §5.3.3.</footnote>

<footnote n="59">⁵⁹ See EGD §5.4.5.</footnote>
### Example 5.5.8.A

```html
<app>
  <lem>wit="#K">tinurunakən sakeň svarganya</lem>
  <rdg>wit="#L">tinurunakən <gap reason="illegible" quantity="4" unit="character"/>nya</rdg>
</app>
```

Display —

1. tinurunakən sakeň svarganya] K, tinurunakən [4x]nya L.

### Example 5.5.8.B

```html
<app>
  <lem>wit="#K">tinurunakən sakeň svarganya</lem>
  <rdg>wit="#L">tinurunakən <gap reason="illegible" extent="unknown" unit="character"/>nya</rdg>
</app>
```

Display —

1. tinurunakən sakeň svarganya] K, tinurunakən [...]nya L.

## 5.5.9 Text of lemma absent from a witness due to scribal omission

When you wish to indicate that a given lemma has no corresponding reading in a given witness, because the scribe has omitted the string of characters in question, then you can use `<gap>` with the value `omitted` on @reason inside the `<rdg>` for the relevant witness. Let us discuss the following provisional example:

### Example 5.5.9.A

```html
<app>
  <lem>wit="#K">tinurunakən sakeň svarganya deniň devata kabeh</lem>
  <note type="altLem">tinurunakən ... kabeh</note>
  <rdg>wit="#L" cause="eye-skip"><gap reason="omitted"/></rdg>
  <note>This sentence seems to have been omitted in <ptr target="#L"/> due to eye-skip from
  <foreign>kavaḥ</foreign> to <foreign>kabeḥ</foreign>.</note>
</app>
```

Display —

1. tinurunakən ... kabeh] K, om. L (eye-skip). This sentence seems to have been omitted in L due to eye-skip from kavaḥ to kabeḥ.

In the case of text omitted due to eye-skip, as in this example, the mandatory elements are `<app>`, `<lem>`, `<rdg>` and `<gap>` with @cause="eye-skip", while the two elements `<note>` are optional. As you see, there is a redundancy in the example between the use of
@cause="eye-skip" (cf. §5.5.3) and the contents of the final <note>, which you may want to avoid by avoiding the explicit term "eye-skip" in the way you formulate the note that explains for human readers what process of eye-skip you imagine. So let us propose the following slight modification:

Example 5.5.9.B

<app>
  <lem>wit="#K">tinurunakən sakeň svarganya deniň devata kabeh</lem>
  <note type="altLem">tinurunakən ... kabeh</note>
  <rdg>wit=#L" cause="eye-skip"><gap reason="omitted"/></rdg>
  <note>The scribe of <ptr target=#L"/> seems to have skipped from <foreign>kavah</foreign> to <foreign>kabeh</foreign>.</note>
</app>

Display —

^1. tinurunakən ... kabeh] K, om. L (eye-skip). The scribe of L seems to have skipped from kavah to kabeh.

In case the process of eye-skip seems self-evident, there will of course be no need to use any
explanatory <note>.

On the other hand, you may wish to make the process even more transparent by
including in the lemma both segments which have triggered the *saut du même au même*, in
which case, however, you may not use <gap> in your <rdg>.

Example 5.5.9.C

ikaň avyavahāra kalih, tan ana kumavruhi

<app>
  <lem>wit=#K">vicāranya, tātan vruh saň prāgvivāka ri hutaňnya, konən</lem>
  <note type="altLem">vicāranya, tātan ... hutaňnya, konən</note>
  <rdg>wit=#L" cause="eye-skip">vicāranya konən</rdg>
  <note>asatyaha</note>
</app>

Display —

^1. vicāranya, tātan ... hutaṅnya, konən] K, vicāranya konən L (eye-skip).

A model similar to <rdg>wit=#L" cause="eye-skip"><gap reason="omitted"/></rdg> in
ex. 5.5.8. A applies to the omission of an entire line of verse by one or more witnesses. In this
case it is possible to add the attribute @cause="line_omission" to the <rdg> element in order to
display such a reading with an indication like "(line omission)" instead of "(eye-skip)".

Example 5.5.9.D

<lg n="23">