```html
<| n="a">nāsti satyāt paro dharmo</|>
<app>
  <lem>wit="#A">| n="b">nānṛtāt pātakaṁ param |</|></lem>
  <rdg>wit="#B" cause="line_omission"><gap reason="omitted"/></rdg>
</app>
<| n="c">sthitiś ca loke dharmaś ca</|>
<| n="d">tasmāt satyaṁ viśiṣyate ||</|>
</lg>
```

### Display —

In case any variant reading occurs among the witnesses that do transmit the segment affected by a line omission in another witness, you will need to make use of the @type with value "omitted_elsewhere" on <lem> (see §5.3.2), as in the next example:

### Example 5.5.9.E

```html
<| n="c">
<app>
  <lem type="omitted_elsewhere">kvehnya savarga</lem>
  <app>
    <lem>wit="#msjb">muṅguh ikanaṅ</lem>
    <rdg>wit="#msbb">muṅgu rikanaṅ</rdg>
  </app>
  <app>
    <lem>wit="#msjb">vacan aniga-</lem>
    <rdg>wit="#msbb">jati maniga-</rdg>
  </app>niga</lem>
  <witDetail type="retained" wit="#msjb #msbb"/>
  <note type="altLem">kvehnya ... aniga-niga</note>
  <rdg>wit="#msba" cause="line_omission"><gap reason="omitted"/></rdg></app>
</|>
```

### Display —

Note that this last encoding strategy is a customization for the case of a line omission but otherwise exactly analogous to ex. 5.5.11.1.B. Remember also that the list of permitted values of @cause is limited. See §5.5.3.

<footnote n="1">1. nānṛtāt pātakaṁ param [] A, om. B (line omission).</footnote>

<footnote n="1">1. kvehnya ... aniga-niga] transmitted in J₂ B₂, om. B₁ (line omission).</footnote>

<footnote n="2">2. muṅguh ikanaṅ] J₂, muṅgu rikanaṅ B₂, om. B₁ (larger gap)</footnote>

<footnote n="3">3. vacan aniga-] J₂, jati maniga- B₂, om. B₁ (larger gap)</footnote>
### 5.5.10 Text of lemma absent from a witness due to physical deficiency

When you wish to indicate that a given lemma has no corresponding reading in a given witness, because the manuscript has physically lost the string of characters in question, then use `<gap>` with the value `"lost"` on `@reason` inside the `<rdg>` for the relevant witness. Example:

<figure><img src="image_12.png" /><figcaption>Example 5.5.10.A</figcaption></figure>

If necessary, you can also use the element `<gap/>` to express the partial loss of the lemma in a given witness. In this case, you will typically be able to know or estimate the number of lost characters, and need to specify `@quantity` and `@unit` within `<gap reason="lost"/>`. Here, `@quantity` must express the number of lost characters in numerical form. You can also add the attribute `@precision="low"`, if you need to underline the fact that the quantity of lost characters can only be estimated. For details, see §5.5.8.

<figure><img src="image_13.png" /><figcaption>Example 5.5.10.C</figcaption></figure>

<figure><img src="image_14.png" /></figure>
Note that we distinguish this kind of case where the physical deficiency corresponds to a part of the lemma from the scenario of larger physical deficiency within which an expected text segment falls. This second case is explained in §5.5.10.

### 5.5.10.1 Text absent from a witness due to physical deficiency but with known meter

If the number of syllables is known thanks to its prosodic pattern for any text segment that is irretrievably lost or illegible because of a physical deficiency, the following encoding must be used: wrap the element `<gap/>` within a `<seg>` with the attribute `@met`. The value of the attribute should match the prosodic conventions in the external authority file (see PVG). For the case of a segment of text of known metrical structure not in the reported reading of a witness but in the text edition itself (for instance if the text is being edited on the basis of a single witness that is lacunose), see §5.7.2.

## 5.5.11 Absence of a witness for a lemma due to larger physical lacuna

### 5.5.11.1 Textual loss within a block-level container

It may also happen that a lemma finds no corresponding reading in a given witness for the reason that the segment in question falls within a larger physical lacuna in that witness. If the entire lemma falls within a single textual block, you may nest the relevant `<app>` in a larger `<app>`, as follows:

#### Example 5.5.11.1.A

```
<app>
  <lem>
    <app>
      <lem type="norm" wit="#EdASD">məŋpəŋ</lem>
      <rdg wit="#A">məpəm</rdg>
    </app>, məlah,
    <app>
      <lem type="norm" wit="#EdASD">mañcir</lem>
    </app>, midvakən,
    <rdg wit="#B"><gap reason="lost"/></rdg>
  </app>
</app>
```

Display —

text

məŋpəŋ, məlah, mañcir, midvakən,

apparatus

<footnote>^938. məŋpəŋ, məlah, mañcir, midvakən,] lac. B</footnote>

<footnote>^939. məŋpəŋ] norm. EdASD, məpəm A, lac. B (larger gap)</footnote>

<footnote>^940. mañcir] norm. EdASD, lac. B (larger gap)</footnote>
You should not encode in the embedded `<app>` an `<rdg>` for the witness affected by the larger lacuna. The indication “/ac. L (larger gap)” in the example is generated by the fact that `<lem>` falls within the `<app>` to which `<rdg> wit="#L"><gap reason="lost"/></rdg>` applies. In other words, this scenario is an exception to the general rule that all witnesses should explicitly be listed and clearly identified in a given `<app>` (see §5.2.1). A slightly more complicated but also more rigorous manner of encoding this scenario is as follows:

### Example 5.5.11.1.B

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

Display —

text

məŋpəŋ, məlah, mañcir, midvakən,

apparatus

^938. məŋpəŋ, məlah, mañcir, midvakən,] preserved in A Ed<sup>ASD</sup>, lac. B

^939. məŋpəŋ] Ed<sup>ASD</sup>, məpəm A, lac. B (larger gap)

^940. mañcir] Ed<sup>ASD</sup>, lac. B (larger gap)

This second solution makes it possible to generate “preserved in A Ed<sup>ASD</sup>” in the display. For `@type="lost_elsewhere"`, see §5.3.2.

## 5.5.11.2 Textual loss across boundaries between block-level containers

When a lacuna straddles boundaries between block-level containers, you will need to use an alternative approach, namely to mark the beginning and end of the physical lacuna with `<lacunaStart/>` and `<lacunaEnd/>` inside `<rdg>` elements corresponding to `<lem>` elements for the words affected by the beginning and end of the gap in the witness:

### Example 5.5.11.2.A

<figure><img src="image_16.png" /></figure>
<app><lem wit="#A">di</lem><rdg wit="#EdASD"><gap reason="omitted"/></rdg></app> bumi lamba, di bumi

<app><lem type="emn">parək</lem><rdg wit="#A">paR<unclear>ka</unclear></rdg><rdg wit="#EdASD">tan parək</rdg></app>.</p>

<p n="4">
<app><lem wit="#A #EdASD">ini pakən</lem><rdg wit="#B"><lacunaEnd/> pak·kən</rdg></app> uraň...
</p>

Display —

text

1.3 i...kalaňkaň saň hyaň dasa-sila, maya-maya saň hyaň dasa-marga, kaprətyaksaan na dasa-indriya, pakən ňrətakən di bumi lamba, di bumi parək.

1.4 ini pakən uraň...

apparatus

^24. dasa-sila] A Ed<sup>ASD</sup>, dasa[... B

^25. dasa-sila ... (§1.4) ini pakən] A gap due to loss intervenes in B

^26. di] A, om. Ed<sup>ASD</sup>, lac. B (larger gap)

^27. parək] em., paRka A, tan parək Ed<sup>ASD</sup>, lac. B (larger gap)

^28. ini pakən] A Ed<sup>ASD</sup>, ...] pak·kən B

Note that the <rdg> containing <lacunaStart/> should always include at least the last preserved word or compound member before <lacunaStart/>; inversely, the <rdg> containing <lacunaEnd> should always include at least the first preserved word or compound member after <lacunaEnd/>. In this approach, too, you may not encode any <rdg> for the given witness in loci falling between <lacunaStart/> and <lacunaEnd/>. The two indications "lac. B (larger gap)" in the example are generated by the fact that the two <lem>s fall between the two elements and no <rdg> for #B has been explicitly encoded.

Note also that any <lacunaStart/> must be closed at some point, before the end of your edition, with a <lacunaEnd/>. When a witness breaks off a few paragraphs before the end of the text, the <lacunaEnd/> must be added in an <app> entry at the last word. If an apparatus entry is required at that point for other reasons, then proceed as usual. Otherwise add an attribute @rend="hide" to this <app>. This is the only scenario in which the <lacunaEnd/> does not need to be encoded with a word or compound member.

Example 5.5.11.2.B

<app rend="hide"><lem>wit="#EdASD #B">palipurna.</lem><rdg>wit="#A"><lacunaEnd/></rdg></app>

5.5.12 Absence of a witness for a lemma due to larger scribal omission

The following scenarios are strictly analogous to those treated in the previous section, and differ from them only in that the reason for textual loss in the given witness is not physical damage but
scribal omission, meaning that the `<gap>` is in this case to be encoded with `@reason="omitted"`
instead of `@reason="lost"`.

### 5.5.12.1 Textual loss within a block-level container

As above, we offer two encoding strategies, again with a slight preference for the second:

<caption>Example 5.5.12.1.A</caption>

```html
<app><lem>saṅ vṛddhah yan tan vruh
<app>
  <lem>wit="#L">iṅ</lem>
  <rdg>wit="#K">riṅ</rdg>
</app> dharma, tan vṛddhaḥ ṇaranira,</lem>
<note type="altLem">saṅ vṛddhah ... tan vṛddhaḥ ṇaranira,</note>
<rdg>wit="#M" cause="eye-skip"><gap reason="omitted"/></rdg>
</app>
```

Display -

Text

saṅ vṛddhah yan tan vruh iṇ dharma, tan vṛddhaḥ ṇaranira,

Apparatus

<caption>Example 5.5.12.1.B</caption>

```html
<app><lem type="omitted_elsewhere">saṅ vṛddhah yan tan vruh
<app>
  <lem>wit="#L">iṅ</lem>
  <rdg>wit="#K">riṅ</rdg>
</app> dharma, tan vṛddhaḥ ṇaranira,</lem>
<witDetail type="retained" wit="#L #K"/>
<note type="altLem">saṅ vṛddhah ... tan vṛddhaḥ ṇaranira,</note>
<rdg>wit="#M" cause="eye-skip"><gap reason="omitted"/></rdg>
</app>
```

Display -

Text

saṅ vṛddhah yan tan vruh iṇ dharma, tan vṛddhaḥ ṇaranira,

Apparatus

<footnote>^1. saṅ vṛddhah ... tan vṛddhaḥ ṇaranira,] *om. M* (eye-skip).</footnote>

<footnote>^2. iṅ] *L*, riṇ *K*, *om. M* (larger gap).</footnote>

<footnote>^1. saṅ vṛddhah ... tan vṛddhaḥ ṇaranira,] transmitted in *L K*, *om. M* (eye-skip).</footnote>

<footnote>^2. iṅ] *L*, riṇ *K*, *om. M* (larger gap).</footnote>
### 5.5.12.2 Textual loss across boundaries between block-level containers

Since the TEI clearly assumes that `<lacunaStart/>` and `<lacunaEnd/>` shall be used only in cases where physical damage is the reason for textual loss, but does not provide any strictly analogous pair of elements for the situation where scribal omission is the reason, we have decided to introduce the tailor-made element-attribute combinations `<span type="omissionStart" />` and `<span type="omissionEnd" />`.<fnref n="60" />

<figure><img src="image_17.png" /><figcaption>Example 5.5.12.2.A</figcaption></figure>

Display —

text

1.1 ... kalaṅkaṅ saṅ hyaṅ dasaśila, maya-maya saṅ hyaṅ dasa-marga, kaprятиaksaan na dasa-indriya, pakən ṅrətakən di bumi lamba, di bumi parək.

1.2 ini pakən uraṅ...

apparatus

<footnote n="1">¹. dasaśila] A Ed<sup>ASD</sup>, dasa[... B</footnote>

<footnote n="2">². dasaśila ... (§1.2) ini pakən] A gap due to omission intervenes in B</footnote>

<footnote n="3">³. di] A, om. Ed<sup>ASD</sup>, om. B (larger gap)</footnote>

<footnote n="4">⁴. parək] em., paRka A, tan parək Ed<sup>ASD</sup>, om. B (larger gap)</footnote>

<footnote n="5">⁵. ini pakən] A Ed<sup>ASD</sup>, ...] pak·kən B</footnote>

<footnote n="60">⁶⁰See TEI §12.1.5 and the comment on the potential for confusion inherent in the term "lacuna" made in Library of Digital Latin Texts §12.9 (Gaps in Witnesses). We have favored an approach with `<span>` rather than `<milestone/>` to avoid the need of adding the mandatory attribute `@unit` with the value "absent" as suggested by the TEI Guidelines §att.milestone for cases which mark the beginning of a piece of text not present in the edition.</footnote>
Again (see §5.5.11), there will be no need to encode any <rdg> for the given witness in loci falling between the two elements <span>. The two indications “om. B” in the example are generated by the fact that the apparatus entries fall between the opening and closing <span/>, and no <rdg> for #B has been explicitly encoded.

It is possible to combine the tailor-made element-attribute `<span type="omissionStart"/>` for a larger textual omission with the values available for the attribute `@cause` (see §5.5.3). You must then add the attribute `@cause` with the chosen value on the parent element `<rdg>` in which you declare the starting point of the omission, as you would do for a smaller omission. You don't need to add the `@cause` on the `<rdg>` containing its end. The value of `@cause` will be reflected in the apparatus entry that makes the connection between beginning and end of the omission.

### Example 5.5.12.2.B

```html
class="svayambhu_07.10">
[...]
<app><lem>wit="#L #M">ńaranya, limań</lem><rdg>wit="#K" cause="eye-skip">ńaranya, <span type="omissionStart"/></rdg></app>
    kṛṣṇalam, <app><lem type="emn">samāṣa</lem><rdg>wit="#L #M">sama:s·</rdg></app>ńaranya,
[...]
</div>
class="svayambhu_07.11">
[...]
pirak <app><lem>wit="#L #M">ńaranya, ikań</lem><rdg>wit="#K"><span type="omissionEnd"/></rdg></app>
sapuluh tahil
[...]
</div>
```

### Display —

* ^808. ĩaranya, limań] L M, ĩaranya, [... K (eye-skip)

* ^809. ĩaranya, limań ... (119.1) ĩaranya, ikań] A gap due to omission intervenes in K caused by eye-skip

* ^810. samāṣa] em., sama:s·L M, om. K (larger gap).

[...}

* ^815. ĩaranya, ikań] L M, ...] ikań K

For the time being, we only allow the use of `@cause="eye-skip"` for interaction with `<span type="omissionStart"/>` and `<span type="omissionEnd"/>`. Contact the XML-TEI Data Manager should you require another value of `@cause`.

## 5.5.13 Reporting scribal additions and deletions

### 5.5.13.1 <add> – Additions

Several possibilities are offered to indicate that text has been added to a witness. It can be done of course with a simple prose description, even though we rather recommend using semantic markup, namely the element `<add>`. Do not encode with `<add>` any segments supplied by a previous editor or to supply any elements yourself. This element should be used only for additions made in the text by the scribe or someone else who handled the manuscript prior to
an edition. Such additions are often easily identified by their placement above or below the line, or in the margin. Making use of the attribute @place is mandatory, and the following values are available:<fnref n="61" />

* "inline": addition made within the original text (in *textu*)

* "below": addition below the line (*subscr.*)

* "above": addition above the line (*suprscr.*)

* "top": addition in the top margin (*in mg. sup.* = *in margine superiore*)

* "bottom": addition in the bottom margin (*in mg. inf.* = *in margine inferiore*)

* "left": addition in the left margin (*in mg.* = *in margine*)

* "right": addition in the right margin (*in mg.* = *in margine*)

* "overstrike": addition made in the space where a previous string of text has been erased (*in ras.* = *in rasura*). This value can only be used with the element `<add>` when it goes hand in hand with the element `<del>` (see §5.5.13.2)

* "unspecified": no information on the place is currently available

If you want to specify the scribal hand making the addition, it is possible to do so using the attribute @hand. You need to have declared this hand in the `<handDesc>` part of the `<teiHeader>`, see §2.1.3.1. Then, provide its @xml:id as value for @hand. Here are two examples:

### Example 5.5.12.1.A

```xml
<app>
  <lem>wit="#K">deśa</lem>
  <rdg>wit="#L">deśa</add>place="below">ńaranya</add>,</rdg>
</app>
```

Display —

¹. deśa] K, deśa «(subscr. ṇaranya)», L.

### Example 5.5.13.1.B

```xml
<app>
  <lem>wit="#K">deśa</lem>
  <rdg>wit="#L">deśa</add>place="below" hand="#L_H2">ńaranya</add>,</rdg>
</app>
```

Display —

¹. deśa] K, deśa «(H₂ subscr. ṇaranya)», L.

<footnote n="61">⁶¹ Some values are the same as in EGD §4.4.2. Note that all values will be displayed except if the element `<add>` is used within `<subst>`.</footnote>
When the addition is marked in the witness with any non-alphanumeric mark (such as the cross-shaped called kākapada in Sanskrit), you may use @rend with the value "mark" to encode this. This encoding method shall apply regardless of where such a scribal mark appears (at the locus of insertion, next to the inserted text, or at both places) and of what shape the mark takes.<fnref n="62" /> The particular shape or shapes used by a given hand in a given witness can be described in <handDesc> as well.

### 5.5.13.2 <del> – Deletions

Scribal deletions are to be wrapped in <del> analogously to the use of <add> for additions. In this section, deletions are taken into account only by themselves but, as the section below explains, you can also encode <del> together with <add>, when deletions and additions co-occur. To qualify how deletions have been carried out, you can use the attribute @rend with one of the following values:<fnref n="63" />

* "strikeout": text struck through, erased or scraped off, without it having become impossible to detect what was deleted (*ante ras*.)

* "dots": dots added next to the characters to be deleted (*exp. = expunction*)

* "ui": for the combined application (typical in Javanese and Balinese manuscripts) of vowel markers *u* and *i* under and above characters to be deleted (*ui*)

The use of the attribute @rend is optional. For the time being, no differentiation is foreseen in the display.

#### Example 5.5.13.2.A

```html
<app>
  <lem>wit="#L">maṇaku dṛvya, juga ya,</lem>
  <rdg>wit="#K">maṇaku dṛvya, <del>rend="ui">Ikamaṅkana;</del>juga: ya;</rdg>
  <note>The canceled string was initially written due to eye-skip from the preceding paragraph.</note>
</app>
```

#### Display —

¹⁵⁹. maṇaku dṛvya, juga ya, ] L, maṇaku dṛvya, [[ui Ikamaṅkana;, ]] juga: ya, K • The canceled string was initially written due to eye-skip from the preceding paragraph.

Note that any text marked as deleted must be legible. If the passage is in fact illegible, it should be encoded with the empty element <gap/> as per §5.5.9. However, if you want to cite a reading that presents a deleted *akṣara* which has become illegible in the deletion process, you can follow the following encoding model:

#### Example 5.5.13.2.B

<footnote n="62">⁶² See EGD §4.4.2.</footnote>

<footnote n="63">⁶³ See EGD §4.4.1.</footnote>
<app>
  <lem type="emn">añalāntaranana</lem>
  <rdg>wit="#L">hañala<del><gap reason="illegible" unit="character" quantity="1"/></del>ntarana:</rdg>
  <rdg>wit="#K">añalantarana:</rdg>
  <rdg>wit="#M">añalantara</rdg>
</app>

Display —

^23. añalāntaranana] em., hañala[[1x]]ntarana: L, añalantarana: K, añalantara M.

5.5.13.3 Combining additions and deletions

A deletion occurring in combination with an addition may be understood as a corrective
substitution process. You may deem it preferable to encode *ante* and *post correctionem*
readings as per §5.5.5 in order to bring out the correspondence of the uncorrected or corrected
state of the text with the readings of other witnesses in <lem> or <rdg>. However, you may also
choose to encode such cases using <add> in combination with <del> and the wrapper <subst>.
Here are two examples, the first involving deletion of a vowel marker yielding inherent vowel a
as substitution:

Example 5.5.13.3.A

<app>
  <lem type="emn">samagrig asambevara</lem>
  <rdg>wit="#A">samagrig<subst><del>ə</del><add place="below">a</add></subst>sambehara</rdg>
  <rdg>wit="#B #C">samagrigə sambehara</rdg>
</app>

Display —

^78. samagrig asambevara] em., samagrig(<<[[:a]]>>sambehara A, samagrigə sambehara BC

Example 5.5.13.3.B

<app>
  <lem>wit="#A #B">parasparopasarpaṇa</lem>
  <rdg>wit="#C">parasparopasa<subst><del>na</del><add place="inline">pa:</add></subst>na</rdg>
</app>

Display —

^270. parasparopasarpaṇa] AB, parasparopasa([[:na|pa::]]na C

However, not all cases of co-occurrence of addition and deletion are interpretable in a
straightforward manner. When you are not sure how a deletion interacts with an addition, it is
recommended to use the elements <del> and <add> without nesting them in <subst>. When
you do use `<subst>`, the values of `@place` on `<add>` and of `@rend` on `<del>` will not be displayed but must still be encoded.

## 5.6 Reporting extraneous text segments (interpolations)

When a (group of) witness(es) has a segment of text that is absent in one or more other (groups of) witnesses and you consider the state of the text in the latter to be original, then the more expansive (group or groups of) manuscript(s) bear testimony to a process often called interpolation. This is different, in theory, from an addition for which a single scribe in a manuscript is responsible. But when you are editing a text on the basis of a small number of witnesses, it may not be possible to discern groups of manuscripts and it may hence not be possible to distinguish interpolations from scribal additions. We offer the following ways of encoding such extraneous text segments.

### 5.6.1 Extraneous text block with `@type="interpolation"`

Any text block (`div`, `p`, `ab`, `lg`) that is transmitted in all your witnesses or in a whole group of witnesses, or even only in a single witness, but which you consider to have been interpolated during a stage of the text's transmission posterior to the one you are trying to reconstruct, may be included in your edition in the suitable block-level container to which you will apply `@type="interpolation"`. Do not furnish any `@n` for such interpolated elements. The display will assign to such elements the number of the previous element of the same level, followed by an asterisk.

<caption>Example 5.6.1.A</caption>

```html
<div type="dyad" n="54">[...]</div>
<div type="interpolation">
  <app><lem>wit="#L"><p>ya tapva ahutaṅ, pinet kinuṅkuṅ ta ya de pradhana, ...</p>
    <p>kuneṅ pvekaṅ tan tinuron, daṇḍa kaṅ sinambat vrat iṅ apadu.</p></lem>
  <note type="altLem">ya tapva ahutaṅ, ..., daṇḍa kaṅ sinambat vrat iṅ apadu.</note>
  <note>These paragraphs are absent in <ptr target="#K"/> and seem extraneous to our text.</note>
</app>
</div>
```

### 5.6.2 Extraneous text in `<rdg>` (optionally with `<seg type="interpolation">`)

A segment, that may or may not correspond to a whole semantic block, found in one or more of your witnesses, which you do not wish to display in your edited text,<fnref n="64" /> can be recorded in the apparatus with reference to a word or words common to the accepted and to the rejected

<footnote n="64">⁶⁴ Note that this is different from the case of a scribal edition taking place “before our eyes” in a witness, and which would be encoded using the `<add>` element (§5.5.13.1). In the situation we are dealing with here, the segment is present in one or more witnesses, but you as editor decide that it was absent in the stage of the text’s history that you are trying to reconstruct.</footnote>
readings that serve to anchor the extraneous segment in question.<fnref n="65" /> Such segments may be as short as a single word or stretch over multiple phrases. It is possible, but not mandatory, to flag the extraneous segment with `<seg @type="interpolation">`, which may be useful for querying your XML data on interpolations, though we do not foresee any special display of such segments.

<caption>Example 5.6.2.A</caption>

```xml
<app>
  <lem>wit="#L">tan</lem>
  <rdg>wit="#K">riṁ tan</rdg>
</app>
```

```xml
<app>
  <lem>wit="#L">tan</lem>
  <rdg>wit="#K"><seg type="interpolation">riṁ</seg>
  <tan></rdg>
</app>
```

<caption>Example 5.6.2.B</caption>

```xml
<app><lem>wit="#K #M">kunaṅ ikaṅ
<app><lem>wit="#L #K">pirak paṇa sapuluh</lem><rdg>wit="#M">sapuluh pana pirak</rdg></app>
<abbr>ma</abbr>,</lem>
<note type="altLem">kunaṅ ikaṅ ... sapuluh <abbr>ma</abbr></note>
<rdg>wit="#L"><seg type="interpolation">kunaṁ Ikaṁ pirak ṣapuluḥ pana:, ma:, || o || <lg
xml:lang="san-Latn" met="anuṣṭubh"><l>Rṇadeve vratijñante,</l> <l>pañcama siṁtam ahartti,</l>
</l>hapanave dadviguṇiṁ,</l> <l>tan manom anuṣasaniṁ,</l></lg> ka, riṅ mavutaṁ yan masaṅketa:, yapva
ta mityeṁ vuhus riṁ purvvaka:, daṇḍanika: de bhūpatya, pañca satapa<del><gap reason="illegible"
unit="character" quantity="1"/></del>ṇa, kunaṁn apuvara haṇasi<unclear>h</unclear> dvigunotama daṇḍa
|| o || <lg xml:lang="san-Latn" met="anuṣṭubh"><l>nipṭiṁ vak nityaṁ* krodaṣṭaṁ*,</l> <l>valat ṣobṛṁ*
namasṭḍdi,</l> <l>niṣṭe maḍyamaṁ* hutamaṁ*,</l> <l>purvvakaṁ* mituva daṇḍaṁ*,</l></lg> ka, hana ta
ya: vaṁn apihutaṁ, tinagih pihutaṁnya, tan paveh vetan drāvenya, haṣṛṁ saṁn apihutaṁ, maṇalap
saḍrvenya, maṇalap histri, sunu, bhūmi, nūn pasu sakalvirim patik venaṁ yata hinalap, vetniṁ kaṁniṣṭa
vinañūn mityeṁn ūjar,, maka:don hinira:-hira:, haṇiṇindeti, haṇlindihi, tan druḥ kaṁn adṛve vaṁn apihutaṁ,
lumka:s kaṇśa:seṁ tan hambava cihna Utər· daLm, hikya ōaran valat sahaṣa havalat ṣobra, hiṇar:vakən
vinalik rantas vitya:, mvaṁ tinibakna daṇḍa mahira<del>ntaṁ</del>n kaṁ sa:hasobradḍi, kunəm
pinaraṅgvakna vutaṁ, lavan daṇḍanekaṁ sahaṣa, vnaṇ pasaṇana vrat niṣṭa maḍyotama, ye niṣṭa vit hutaṁ
mvah paṇamet· sinahaṣa:, niṣṭa: daṇḍa,, 5000, yen madya paṇamete, daṇḍa, 10000, hutama paṇamete,
daṇḍa, 20000, sapaṇamete haṇsula:kna riṁ kaṁn avutaṅ, vaṣana, daṇḍa riṁ saṁ bhūpatya || 0 || kunaṁ
Ikaṁ pratekaniṁ harta:, sapaṇna:, 20, limaṁ paṇa:, 2, ku, tkeṁ hartha,</seg> kunaṁ ikaṁ pirak pana
sapuluḥ, ma:,</rdg>
<note>Manuscript <ptr target="#L"/> inserts a substantial interpolation between two iterations of the lemma.
The interpolation notably contains the full text of MDhŚ 8.139 and an unidentified Sanskrit stanza. Although
having stanza 8.139, with paraphrase, in this general part of the text is potentially attractive, the fact that the
stanza is quoted in full is suspect, and the precise locus where it is inserted interrupts the paraphrase of
```

<footnote n="65">⁶⁵ The usual method to encode such a phenomenon is to provide an empty `<lem>` element for this additional text. Nonetheless, since no empty element has been used in the DHARMA encoding model, we have decided in favor of keeping the usual printed strategy. Anway, the missing anchoring lemma would have raised a particular display issue, if members of the project expect to display the main edition with notes in a way that reproduces the printed apparatus.</footnote>
8.137. On these grounds, we favor the hypothesis that the segment of text found only in this witness is extraneous to our text.</note>
</app>

### 5.6.3 <surplus> – identifying small segments of extraneous text

Any smaller segment that you consider, as editor, to be inauthentic or superfluous but nevertheless need to retain in the edition, for some reason (for instance if all your witnesses have it), should be encoded as <surplus>.

**Example 5.6.3.A**

*lələbakna<surplus>,</surplus> mvaň

Display –

*lələbakna{,} mvaň

**Example 5.6.3.B**

maňkana, <surplus><term xml:lang="san-Latn"><app><lem type="norm">dānapratibhūḥ</lem><rdg>wit="#L">da:napratibhuḥ</rdg><rdg>wit="#K #M">dana:pratibuḥ</rdg></app></term> ņaranya, <surplus> yan mati ikaň maňaku,

Display –

maňkana, {dānapratibhūḥ ņaranya,} yan mati ikaň maňaku,

### 5.6.4 <secl> – misplaced text segments

The TEI Guidelines offer a further element <secl> (meaning “secluded”) for “the case of an interpolation which the editor regards as genuine (i.e. written by the author in question), but out of its original place”<fnref n="66" /> which you can’t determine. In such a case, <secl> allows taking its contents out of the text flow and marking it as not belonging where it is found in the witnesses. Should this element seem convenient for transmissional phenomena that you need to encode, then please contact the XML-TEI Data Manager.

<footnote n="66">⁶⁶ See TEI Guidelines, §11.3.1.7.</footnote>
## 5.7 Supplying untransmitted text or indicating your inability to supply lost text

The `<supplied>` element can be used to mark any segment that you wish to include in your edited text but that is not found in any of the manuscripts. Besides the specific scenario of a dependent text (like a commentary) that implies but does not cite its base text fully or at all (see §4.3), we envisage the use of `<supplied>` when:

1. a segment is supposed to have been present at the stage of the text's development that your edition is trying to reconstruct but assumed to have been lost or expunged in the subsequent course of transmission

2. you wish to indicate the purely editorial nature of untransmitted punctuation that you may wish to insert to help the reader, without implying that it was ever present in the transmission

It is possible to use `<supplied>` directly in your edition in cases where the editorial intervention does not require the creation of an apparatus entry; `<supplied>` can also be used inside a `<lem>` (and even inside an `<rdg>`, if a printed edition indicates it has supplied a given segment), which, in turn, is to be wrapped in `<app>`. In any scenario, the element must be used with the attribute `@reason` having one of the following values:

* "lost": to be used when text is conjecturally restored to fill a physical lacuna which affects the given locus in all witnesses

* "omitted": to be used when it is assumed that a given string as been voluntarily expunged or involuntarily omitted in the course of transmission

* "implied": to be used when a given string of text or punctuation sign, not found in any of your witnesses, is not assumed ever to have been present in the transmission of your text but somehow implied and needs to be displayed in your publication

* "undefined": to be used for instance when a printed edition indicates that the editor has supplied a segment without indicating the reason

* "unknown": to be used when you cannot determine the reason behind loss or omission

Furthermore, it is possible to indicate on which evidential basis you supply the segment by adding the attribute `@evidence`, with one of the following three values:

1. "internal"

2. "external"

3. "conjecture"

The first value means that there is an analogous passage elsewhere in your text that supports the hypothesis that a segment needs to be supplied in the current context; the second means
that there is such evidence but that it is external to your text. If you use @evidence="external",
then you are expected to encode the parallel passage(s) in question as per §6.2.

Example 5.7.A

... sadaņayan<supplied reason="implied"/></supplied> sajamus ...

Example 5.7.B

... vvaņ atuha

<app>

<lem><supplied reason="omitted" evidence="internal">dahat, rare</supplied></lem>

<rdg>wit=#A #B #C</rdg><gap reason="omitted"/></rdg>

<note>The two words supplied here are assumed to have been omitted in transmission due to eye-skip. Their restoration is supported by two other occurrences of the pair <foreign>atuha/rare</foreign> in our text, in §12 and §91.</note>

</app> dahat, ...

Example 5.7.C

... yan pahutaṅ,

<app>

<lem><supplied reason="omitted" evidence="external">mvaṅ managih riṅ tan pahutaṅ</supplied></lem>

<rdg>wit=#A #B #C</rdg><gap reason="omitted"/></rdg>

</app> adharma ṇaranya, ...

5.7.1 Reporting a locus of suspected textual loss

A particular scenario arises when you have reason to believe, against unanimous evidence of
the manuscripts, that a certain amount of text has been omitted or lost in transmission at a given
locus, but are unable to determine what precise segment of text is to be supplied to fill the gap.
This is basically the opposite of an interpolation. Such a situation may be encoded as follows:

Example 5.7.1.A

salvirniṅ <supplied reason="omitted" evidence="conjecture"/></supplied> hyaṅ ṛśiśāsana

Or, if you need to render the reasons behind your assumption of textual loss explicit in a note:

Example 5.7.1.B

tan paṇilaṇakən sira iri ya,

maṅkana liṅ <app><lem><supplied reason="omitted" evidence="conjecture"/><gap/></supplied></lem><note>All</note>
mss. have <foreign>atəhər</foreign> (spelled <foreign>at:hər</foreign>) directly following <foreign>liṅ</foreign>.
This seems grammatically impossible, as <foreign>maṅkana liṅ</foreign> is always used in a possessive
construction immediately followed by a designation of the speaker. We can only guess that words like
<foreign>bhaṭāra manu</foreign> have been omitted.</note></app>
</p>
</div><div type="dyad" n="16">
<p xml:id="svayambhu_02.16.01">atəhər ...</p>
</div>

You may use "lost" or "unknown" as values of @reason (in many cases, it will be impossible to
know the reason for a segment's absence). Use of @evidence is not mandatory and if you do
find it useful, other values may be relevant than "conjecture". See the list of suggested values
above.

5.7.2 Marking up lacunae with known meter

If you are editing a text on the basis of a *codex unicus* which is incompletely preserved, some
(parts of) verse may be lost. You might wish to mark this lost text that can't be restored, but for
which the prosodic pattern is known. To do so, wrap a <gap/> element with <seg>. Add the
attribute @met to it and record the prosodic pattern of the lacuna (see PVG for the conventions
to be used in @met). In syllabic verse, the number of lost characters can be calculated
accurately. In other cases, such as moraic verse, you might need to use the attribute
@precision="low".<fnref n="67" />

<caption>Example 5.7.2.A</caption>

<seg met="+++---+--"><gap reason="lost" quantity="7" unit="character"/></seg>

Display -

[- - - - - - -]

5.8 Encoding transposition of text

The term transposition is used here to designate phenomena of inversion of the order of words,
sentences or paragraphs vis-à-vis the order of your edited text. It may be possible to distinguish
purely physical processes of displacement of folios, leading to a witness no longer presenting
the text in the proper order, from cases where witnesses show varying sequences because
some person involved in transmitting the text made a change in the text's sequence,
intentionally or not. (Our encoding model does not take into account the issue of intentionality.)
Complex transpositions are difficult to encode with the parallel segmentation method, if they
involve variants occurring in different locations. For simpler cases, such as inversion between

<footnote n="67">⁶⁷ EGD §5.4.4.</footnote>
two segments of text following each other in close succession (§5.8.1), physical displacement of
folios in an antegraph (§5.8.2) or changes in the order of lines within a stanza (§5.8.3), you can
make use of the methods for encoding apparatus described so far, with the specifications we
offer below. We address a slightly more complicated scenario in §5.8.4. But for cases that are
even more intricate, it may be most pragmatic to decide in favor of a prose description in a
<note> rather than an apparatus entry with complex TEI encoding.<fnref n="68" />

5.8.1 Transposition of text segments within a single block

In simple cases, i.e., as long as the transposed segments all fall within a single block of text, the
usual pattern for creating an apparatus entry should be followed. The reading accepted by the
editor as the lemma goes into the element <lem>, while any variant reading is recorded in <rdg>
with @cause="transposition" as per §5.5.3 (example 5.5.3.B). It is possible to highlight
transposed segments with <seg type="highlight"> as per §5.5.2.

<caption>Example 5.8.1.A</caption>

<app>
  <lem>wit="#K">ika ta saṅ prabhu, tinut <seg type="highlight">sira</seg> deniṅ rat kabeh</lem>
  <rdg>wit="#L" cause="transposition">Ika: ta <seg type="highlight">sira</seg> saṁ prabhū tinut deniṁ rat kabeh</rdg>
  <rdg>wit="#M">ika ta saṁ prabu <seg type="highlight">maṅkana</seg>, tinut <seg type="highlight">sira</seg> de<seg type="highlight">nikaṁ</seg> rat kabeh</rdg>
</app>

Display —

933. ika ta saṅ prabhu, tinut sīra deniṅ rat kabeh] K, Ika: ta sīra saṁ prabhū tinut deniṁ rat kabeh L
(transposition), ika ta saṁ prabu maṅkana, tinut sīra denikaṁ rat kabeh M

5.8.2 Transposition through physical displacement

If you have determined that one or more folios must have been displaced in an antegraph of a
given witness, so that the text jumps in the middle of one folio to the middle of another in a
prima facie random manner, then you can record such textual displacement with the element
<locus> using the attribute @type with the value "displacement". To document the place in the
text where the reader has to flip from one folio and line to another, you must create an <app> to
accommodate an <rdg> for the witness in question, and should use the attributes @from and
@to for filling in the page/folio and line references. You are likely to come up with corresponding
<app> entries, for where the text jumps and then jumps back, and small errors are liable to
occur around the loci of displacement, as in the following example:

<footnote n="68">⁶⁸ We have taken inspiration from https://digitallatin.github.io/guidelines/LDLT-Guidelines.html (§12.12.4) on certain points in determining our encoding model.</footnote>
<table><caption>Example 5.8.2.A</caption><tr><td><pre><app><lem>wit=#L #K&gt;piraknya&lt;/lem&gt;<br/>&lt;rdg>wit=#M&gt;si&lt;locus type="displacement" from="21r12" to="12r2"/&gt;raknya&lt;/rdg&gt;</pre></td><td><pre><app><lem>wit=#K&gt;alapənira&lt;/lem&gt;<br/>&lt;rdg>wit=#L&gt;&lt;gap reason="omitted"/&gt;&lt;/rdg&gt;<br/>&lt;rdg>wit=#M&gt;a&lt;locus type="displacement" from="12r2" to="21r2"/&gt;pənira&lt;/rdg&gt;</pre></td></tr><tr><td>Display –<br/><br/>^850. piraknya] L K, si[displacement from 21r12 to 12r2]raknya M</td><td>Display –<br/><br/>^911. alapənira] K, om. L, a[displacement from 12r12 to 21r2]pənira M</td></tr></table>

### 5.8.3 Transposition of the lines of a stanza

Let us now consider a case where two hemistichs appear in reverse order. In the following example, witness A shows the accepted order of the four verse lines, while witness B puts the second hemistich before the first. Except for this change in order, the text of all verse lines is strictly identical in both witnesses. For this reason, you do not need to reproduce the same text and can use the attribute @corresp on the `<I>` elements in `<rdg>`. Note that, in this case, the `<lem>` element must bear the attribute `@type="transposed_elsewhere"` and shall always contain the text in full.

It is only possible to use @corresp inside the `<rdg>`, not vice versa. The value of the attribute @corresp should refer to the `@xml:id` of the element to which it corresponds, prefixed by `#`. An XSLT transformation process that can be launched and relaunched by the project's XML-TEI Data Manager will generate `@xml:ids` for all `<lg>` and `<I>` elements in our XML files.<fnref n="69" /> Note that in the following example, the `<lg>` element must be added inside the `<app>` rather than outside, since the TEI model requires that an `<lg>` element must at least contain one direct child `<I>`, `<lg>` or `<gap>`.<fnref n="70" />

<table><caption>Example 5.8.3.A</caption><tr><td><pre><app><lem>wit=#A" type="transposed_elsewhere">&lt;lg met="anuşţubh">&lt;l n="a" xml:id="siksaguru_33a">dharmakşetre kurukşetre&lt;/l&gt;<br/>&lt;l n="b" xml:id="siksaguru_33b">dharmajñair bahubhir vṛte|&lt;/l&gt;<br/>&lt;l n="c" xml:id="siksaguru_33c">uñchavṛttir dvijah kaś cit&lt;/l&gt;<br/>&lt;l n="d" xml:id="siksaguru_33d">kāpotir abhavat purā||&lt;/l&gt;</pre></td><td><pre></pre></td></tr></table>

<footnote n="69">⁶⁹ This process can be launched or relaunched upon request.</footnote>

<footnote n="70">⁷⁰ See TEI Guidelines, https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-lg.html.</footnote>
Display —

Apparatus

^1. B presents the lines in order cdab.

If the variation between the witnesses does not only concern the order of the verse lines but also the text of one or more lines, then encode the transposition as above, using the attribute @corresp, while encoding any variant readings of specific text segments in the usual manner, meaning that you will embed one or more <app> elements in the <app> representing the transposition. In view of this embedding, it is necessary to encode the witness(es) supporting the order of text as retained in your edition following the pattern presented in §5.5.6.1 (on <witDetail type="retained"/>).

Example 5.8.3.B
Display —

Apparatus

^1. B presents the lines in order cdab.

^2. kuru-] B, giri- A.

### 5.8.4 Discontinuous transposition

Now we will consider discontinuous transposition, that is a given witness placing a text segment in a different location of the text that does not overlap with the lemma, and may even be situated in a different text block. It is possible to limit yourself to explaining the differences of position solely in a `<note>` (see §6.1) at the end of the `<p>` or `<l>` at which point one or more witnesses start to diverge from the accepted text. However, it is also possible to encode this kind of scenario, but it means that a single `<app>` element will not be sufficient to indicate the various positions in the text where the segment is found in the respective witnesses. If you do decide to encode the scenario rigorously, it means that you will have an apparatus entry that only contains a `<lem>` linked to another `<app>` that only contains an `<rdg>`.

The reading you are adopting as a lemma should, as usual, be encoded in a `<lem>` element. Whether it comes before or after the *locus* at which the transposed `<rdg>` is recorded in your edition, the `<lem>` should bear the attribute `@type` with the value `"transposed_elsewhere"` also in cases of discontinuous transposition. The `<lem>` affected by the transposition should be furnished with an attribute `@xml:id` whose pattern will be `"trsp###"`, with an incremental three-digit number. For now, we expect you to attribute the numbers manually and don't foresee any auto-generation of those identifiers with an XSLT script, but should you think you would benefit from it, please contact the XML-TEI Data Manager of the project. This identifier should be represented with an `@corresp` preceded by a `#` in all the variants readings rejected by the encoder, as in the following example.

#### Example 5.8.4.A

```xml
<app xml:id="app00755">
```

```xml
<lem wit="#A" type="transposed_elsewhere" xml:id="trsp001">
```

```xml
<lg met="anuştubh" n="12">
```

```xml
<| n="a">dharmakşetre kurukşetre</|>
```

```xml
<| n="b">dharmajñair bahubhir vr̥te|</|>
```

```xml
<| n="c">uñchavṛttir dvijaḥ kaś cit</|>
```

```xml
<| n="d">kāpotir abhavat purā ||</|>
```

```xml
</lg>
```

```xml
</lem>
```

```xml
<note type="altLem">dharmakşetre... purā||</note>
```

```xml
<note>The MS A provides the stanza as the 12th, while in the MS B it is the 23rd. We have decided to keep the stanza's position as in A.</note>
```

```xml
</app>
```

```text
[...]
```
<app xml:id="app00856">
  <rdg wit="#B" corresp="#trsp001" cause="transposition"/>
  <note>The stanza is number 12 in our edition.</note>
</app>

Display —

^755. dharmakṣetre... purā||] A (transposition) • The MS A provides the stanza as the 12th, while in the MS B it is the 23rd. We have decided to stanza's position as in A.

^856. dharmakṣetre... purā||] B (transposition, see st. 12) • The stanza is number 12 in our edition.

If you need to encode any variant readings for the segment affected by transposition, then you will face the problem of inheritance of attribute values and need to make use of `<witDetail>` to encode the @wit for the witness whose position you retain (compare the encoding strategy described in §5.5.6.1). In the following example, the editor keeps the position of the stanza following one witness and yet makes use of a variant reading from a witness that places the segment elsewhere.

Example 5.8.4.B

<app xml:id="app00755">
  <lem type="transposed_elsewhere" xml:id="trsp001">
    <lg met="anuṣṭubh" n="12">
      <l n="a">dharmakṣetre <app><lem rend="hyphenright" wit="#B">kuru</lem></app>
      <rdg wit="#A">giri-</rdg></app>kṣetre</l>
      <l n="b">dharmajñair bahubhir vṛte</l>
      <l n="c">uñchavṛttir dvijaḥ kaś cit</l>
      <l n="d">kāpotir abhavat purā||</l>
    </lg>
  </lem>
  <witDetail wit="#A" type="retained"/>
  <note type="altLem">dharmakṣetre... purā||</note>
  <note>The MS A provides the stanza as the 12th, while in the MS B it is the 23rd. We have decided to keep the stanza's position as in A.</note>
</app>
[...]
<app xml:id="app00856">
  <rdg wit="#B" corresp="#trsp001" cause="transposition"/>
  <note>The stanza is number 12 in our edition.</note>
</app>

Display —

^755. dharmakṣetre... purā||] A (transposition) • The MS A provides the stanza as the 12th, while in the MS B it is the 23rd. We have decided to stanza's position as in A.

^756. kuru-] B, giri- A.

^856. dharmakṣetre... purā||] B (transposition, see st. 12) • The stanza is number 12 in our edition.
Now let's imagine the editor wants to retain a transposed segment neither in the position that it has in A nor in the one it has in B.

### Example 5.8.4.C

```xml
<app xml:id="app00755">
    <rdg wit="#A" cause="transposition" corresp="#trsp001"/>
</app>
[...]
<app xml:id="app00856">
    <rdg wit="#B" cause="transposition" corresp="#trsp001"/>
</app>
[...]
<app xml:id="app00955">
    <lem type="emn transposed_elsewhere" xml:id="trsp001">
        <lg met="anușțubh" n="12">
            <l n="a">dharmakșetre kurukșetre</l>
            <l n="b">dharmajñair bahubhir vṛte</l>
            <l n="c">uñchavṛttir dvijaḥ kaś cit</l>
            <l n="d">kāpotir abhavat purā</l>
        </lg>
    </lem>
    <note type="altLem">dharmakṣetre... purā</note>
    <note>We have decided to emend the transposed stanza to avoid the variants proposed by the witnesses A and B because ...</note>
</app>
```

### Display —

* ^755. dharmakṣetre... purā || A (transposition, see st. 12)

* ^856. dharmakṣetre... purā || B (transposition, see st. 1212)

* ^955. dharmakṣetre... purā || em. (transposition) • We have decided to emend the transposed stanza to avoid the variants proposed by witnesses A and B because ...

## 5.9 Marking an irreparably corrupt segment as crux

Any passage that is transmitted in unintelligible or otherwise apparently corrupt form, and which you are not able to repair by conjectural emendation, is to be marked as a so-called "crux" by wrapping it in <sic>. Make sure that readings of all witnesses are recorded in an <app> wrapped around the <sic>, using <lem> and <rdg> in the usual way, unless the crux passage is found as such without variant readings in all your witnesses. Should the witnesses not be in precise agreement, yet none evidently be more acceptable than the rest, try to represent in <sic> what seems to be the corrupt reading from which they all derive (no need for any @type on <lem> in this case), or adopt the reading of one of the witnesses (with or without applying any cosmetic normalization). Any text segment ABC wrapped in <sic> will be displayed in obeli: †ABC†.
### Example 5.9.A

kaṇṭhāravam, tan pañhvab,
<app><lem>wit="#L642"><sic>akadanəm</sic></lem><rdg>wit="#L633">Akadaranəm·</rdg></app>
tan pañulet ri harəpən saṅ guru, <sic>sudəm</sic> phalarahasyam tan

Display —

text:

kaṇṭhāravam, tan pañhvab, ṭakadanəmṭ(234) tan pañulet ri harəpən saṅ guru, ṭsudəmṭ phalarahasyam tan

apparatus:

^234. ṭakadanəmṭ] L642, Akadaranəm· L633

## 5.10 Annotations in apparatus

### 5.10.1 <note> – Apparatus Notes

Using `<note>` to insert free-text observations into your edition requires the element either being enclosed in an `<app>` with variant readings or it being placed as the final child of an encoding block (`<p>`, `<ab>` or `<lg>`). Such a `<note>` will normally comment on some philological problem raised by a lemma, by one or more variant reading(s), or by the block of text as a whole. For more on the use of `<note>`, see §6.1 and §8.2. It is understood that the contents of `<note>` are formulated in English by default, and for this reason there is no need to use `@xml:lang="eng"` (by way of exception to the general principles stated in §8.10.1).

If you want to assign a `<note>` to a sequence of words defined as a `<lem>`, without assigning any `@wit` to the `<lem>`, and without encoding any `<rdg>` (e.g., because the remark applies to a reading shared by all witnesses), you need use the attribute `@type="note"` to be conformant with the encoding model (see §5.3.2 and §5.1, no. 4).

### Example 6.1.C

<app><lem type="note"><app><lem>wit="#L #M">vetanasya</lem><rdg>wit="#K">veka:nasya</rdg></app> na ca
<app><lem>wit="#K #M">dānam</lem><rdg>wit="#L">daniṁ</rdg></app></lem><note>All mss. indicate that this
was the received Sanskrit text, which makes perfect sense, but is nevertheless problematic because it is
unmetrical.</note></app>
### 5.10.2 `<witDetail>` – Witnesses Notes

The `<witDetail>` is defined as a "specialized note" by the TEI Guidelines. Unlike `<note>`, it can provide specific information related to a particular aspect of the witness you would like to evoke for the witness or witnesses supporting a given reading, e.g. a note explaining that the variant readings might involve two hands. It may only be used to comment on the `<lem>` or the `<rdg>` immediately preceding it and must bear the attribute `@wit` identifying the witness or witnesses with which the observation is concerned. The DHARMA schema prohibits use of `<witDetail>` other than as an empty element, though this is not a TEI constraint. We have made this choice because we so far use `<witDetail>` only as a solution to encode *ante* and *post correctionem* readings (see §5.5.5 or `@type "ac"` and `"pc"`), as well as specific information regarding reformulation on a larger segment of text (see §5.5.6.2 for an explanation for `@type "retained"` and `"rejected"`). This being the case, we are not inclined to allow use of this element in other contexts. However, if you feel like you might benefit from using it, contact the XML-TEI Data Manager.

## 6. Editorial material applied to entire blocks of text

### 6.1 Text critical notes

If you need to apply a note to a whole paragraph, an invocation/colophon, a stanza or a verse line of edited text, out of the context of associating parallel passages to the edited text (a topic to which we turn in the immediately following paragraphs), you can use a `<note>` as final child of the respective block-level container (`<p>`, `<ab>`, `<lg>` or `<l>`), to be placed after any final punctuation (and after the final `</l>` in the case of `<lg>`). The note will be displayed as part of the apparatus with a lemma generated automatically on the basis of the first and last words of the block without your needing to apply `<app>` and `<lem>`.

<caption>Example 6.1.A</caption>

```html
<p>kunaṅ ikaṅ strī ... śūdra <app><lem>wit="#L">sākṣinya</lem><rdg>wit="#K">sakṣyanya</rdg></app>,
yan <app><lem>wit="#L">caṇḍāla</lem><witDetail>wit="#L" type="pc"/><rdg>wit="#L">cacaṇḍala</rdg><witDetail>wit="#L" type="ac"/><rdg>wit="#K">caṇḍala mavyavahara</rdg></app>, caṇḍāla <app><lem>wit="#L">sākṣinya</lem><rdg>wit="#K">sakṣyanya</rdg></app>.
```

```
<note>The readings of both witnesses cannot be reconciled with each other without doing violence to one or the other. It is noticeable that the reading of <ptr target="#K"/> is much more coherent than that of <ptr target="#L"/>.
By the principle of <foreign>lectio difficilior potior</foreign>, <ptr target="#L"/>'s readings should probably be preferred: they are less consistent, somewhat elliptical, and compressed, whereas <ptr target="#K"/>'s readings look like an expansion and systematization.</note></p>
```

<caption>Example 6.1.B</caption>
```xml
<lg xml:id="rt_49.02" n="2">
  <l n="a"><lb n="6"/>sampuh rakva ghinositan sahanani'n bala mareka kabeh mana'n kila, </lb>
  <l n="b"><lb n="7"/>mvan ra'n ka'n hana bhakti marpat ahalap rinacana sinugandha lepana, <note>After
  this line, <ptr target="#JK"/> has: <foreign>(malya-ban pinako-pa sobba mideri'n taretepan iva'n)</foreign>, the
  brackets clearly being meant to cancel the words in question, which are identical to 48.3c. The scribe realized he
  had skipped ahead. </note></l>
  <l n="c"><lb n="8"/>śobha listi'n i madhyani'n vata'n an énjah arøja tinulis bhinūṣaṇan, </lb>
  <l n="d"><lb n="9"/>mvan lu'n sir kanaka dravāra'n i hiri'n nya kumulili'n arambatan tøtø. </lb><note>Stanza
  numbered 294 in <ptr target="#JK"/></note></lg>
```

### Display –

^380. mvan [...] lepana,] After this line, JK has: (malya-ban pinako-pa sobba mideri'n taretepan iva'n), the brackets clearly being meant to cancel the words in question, which are identical to 48.3c. The scribe realized he had skipped ahead.

^381. sampuh [...] tøtø.] Stanza numbered 294 in JK.

## 6.2 Parallel passages: quotations, testimonia, etc.

A specific case of the above concerns parallel passages. The term "parallel" designates any text that is not in the direct tradition of the edited text. The term is used here to cover such phenomena as quotations or adaptations from your text in a later one, possible or certified sources of your text figuring in earlier texts, transmission of parts of your text in anthologies, or similar textual material in another text that may point to that text as well as yours having reworked the same pre-existing material.

Testimonia, namely quotations of a text in other ancient sources, can be considered as witnesses. If a quotation of your text attests to variant readings, the relevant information can be provided as an annotation in the critical apparatus (§5), but our discussion here will focus on how to record parallel passages separately from your critical apparatus. In terms of how your edition would be displayed this might mean a separate layer at the bottom of a page of edited text, or an appendix in a book, not to mention the broad range of possibilities that will be at our disposal in the visual presentation of an online edition.

It should be noted that encoding parallel passages is optional: the editor must decide whether listing them is necessary or useful for her/his own edition or not. It is difficult to make general recommendations regarding the choice between reporting parallel passages in the manner described here and citing them in annotation to your critical apparatus, or (in a different file, see §9.1) to your translation. But if you do opt for recording parallel passages separately, we recommend limiting yourself to reporting material that constitutes direct evidence for the transmission/reception history of your text, and/or to textual material that has had direct impact on the way you have chosen to constitute your text (i.e. your rejection, acceptance or emendation of transmitted readings).

The method outlined below enables you to document with some nuance the relationship between the text you are editing (including any base text embedded in or implied by it) and any
parallel texts. We mean hereby that a parallel passage which is similar, but not identical, to the
text of your edition will not be encoded in the same way as a strictly identical one. In this
connection, note that some variants (e.g. ones that merely pertain to spelling, or that involve an
obvious infelicity in the edition of reference that you would weed out if you were re-editing that
text) may be ignored as insignificant for evaluating the question of identity or difference between
mutual parallels.

6.2.1 Associating a known parallel to a whole block of text

Any type of parallel passage can be given within the element <listApp> with a dedicated
attribute @type="parallels".<fnref n="71" /> This element uses the children <app> and <note> already familiar
from the chapter Critical Apparatus, but their use for recording parallels is slightly different,
among other things because it does not involve <lem>. The <listApp type="parallels"> will be
the first following sibling (even in the case of an externally encoded apparatus, see §6.3) of the
block containing the text for which a parallel will be reported, namely <p> or <lg>. With <quote>,
when the passage in question is itself quoted from another text, the <listApp type="parallels">
can follow the <p> or <lg>, rather than the <quote> itself. This last scenario is shown in the
following example:

<caption>Example 6.2.1.A</caption>

<div type="dyad" n="32">
<quote type="base-text" xml:lang="san-Latn">
<lg n="31" met="anuṣṭubh">
< | n="a">arjayej jñānam arthāṁś ca</|
< | n="b">vidvān amaravat sthitaḥ |</|
< | n="c">keśeṣv iva gṛhītaḥ san</|
< | n="d">mṛtyunā dharmam ācaret II31 II</|
</lg>
<listApp type="parallels">
<app>
<note corresp="txt:NarSm_04.12"/>
<note corresp="txt:ViSm_03.11"/>
</app>
</listApp>
</quote>
<p>mataṅnya deyanika saṅ meṇet, apageḥ kadi tan kneṅ pāti, lviraniran paṅarjana jñāna, artha, kunaṅ yan paṅarjana dharma, kadi katona rumaṅgut mastakanira, ta pva ikaṅ mṛtyu denira, ahosanā palayvana juga sira.</p>
</div>

As shown in the example, the element <listApp type="parallels"> shall be structured internally
with at least one <app> element, which will, in turn, contain one or more <note> elements; you
shall use one <note> element per parallel. Note that, while the above example shows

<footnote n="71">⁷¹ Note that we have decided not to follow TEI guidelines §16.1.2, although its model has been applied in the SARIT project.</footnote>
@type="base-text" on <quote>, the same structure can be used — without that attribute — for quotations of preexisting textual material which do not fall in the category of base text interacting with dependent text.

### Example 6.2.1.B

```xml
<quote xml:lang="san-Latn">
  <lg met="anuṣṭubh">
    <l>// 0 // <app><lem>wit="#B">yatīnāṁ</lem><rdg>wit="#A #C">ya tana:ṁ</rdg></app> putra yat dravyaṁ, yat kiñ cit <app><lem type="norm">pustakādikam</lem><rdg>wit="#A #C #B">pustakaḍikaṁ*</rdg></app>,<l>
    [...]
  </lg>
  <listApp type="parallels">
    <app>
      <note corresp="txt:..."/>
      <note corresp="txt:..."/>
    </app>
  </listApp>
</quote>
```

However, outside a quoted passage, the parallels are indeed at the same structural level than the `<p>` or `<lg>` elements.

### Example 6.2.1.C

```xml
<p xml:id="siksaguru_11.01"><term xml:lang="san-Latn">kurvanti
  <app><lem type="emn">kṛtāyām</lem><rdg>wit="#A">kata ya</rdg><rdg>wit="#B">kata yan</rdg></app> dharma</term>, gavayakāna sakagavayan saṅ hyaṅ dharma, Ivirnya ta nihan, <term xml:lang="san-Latn">dāna</term>, <term xml:lang="san-Latn">śīla</term>, <term xml:lang="san-Latn"><app><lem type="emn">kṣānti</lem><rdg>wit="#A">yanti</rdg></app> <rdg>wit="#B #C">kyanti</rdg></app></term>, <term xml:lang="san-Latn">vīrya</term>, <term xml:lang="san-Latn"><app><lem type="emn">dhyāna</lem><rdg>wit="#A #B #C">byana</rdg></app></term>, <term xml:lang="san-Latn">prajñā</term>, <term xml:lang="san-Latn">karuṇā</term>, <term xml:lang="san-Latn">mudita</term>, <app><lem type="norm"><term xml:lang="san-Latn">metrī</term></lem><rdg>wit="#A #C">metri</rdg></app> <mes-tri</rdg></app>, <term xml:lang="san-Latn">upekṣā</term>.
</p>
<listApp type="parallels">
  <app>
    <note corresp="txt:KAS.10§17">KAS 10§17: <foreign>ikaṅ metrī karuṇā muditā upekṣā, ya tikā sinaṅguh caturpāramitā ṅaranya. papupulni caturpāramitā mvaṅ ṣaṭpāramitā, Ivirnya: dāna, śīla, kṣānti, vīrya, dhyāna, prajñā, metrī, karuṇā, muditā, upekṣā. ya tikā sinaṅguh daśapāramitā ṅaranya, ya tikā matattva pañcadevī</foreign>.</note>
  </app>
</listApp>
<p xml:id="siksaguru_11.02">kaliṅanya, [...]</p>
```
It is also possible to apply a typology of parallels, in which case you will differentiate <app> elements by their attributes @type. This will make it possible, for instance, to sort your parallel texts in order to enable multiple display scenarios. However, since we do not foresee this option being used much, the value of @type is left to the encoder's discretion. Please contact the XML-TEI Data Manager if you want to use this option.

<caption>Example 6.2.1.D</caption>

```xml
<listApp type="parallels">
    <app type="imitation">
        <note corresp="txt:NarSm_04.12">
            <lg>properly encode the parallel stanza here</lg>
        </note>
    </app>
    <app type="quotedby">
        <note corresp="txt:KKT_07.111">
            <lg>properly encode the parallel stanza here</lg>
        </note>
    </app>
    <app type="adaptation">
        <note corresp="txt:MaBh_07.59">
            <lg>properly encode the parallel stanza here</lg>
        </note>
        <note corresp="txt:Ram_04.12">
            <lg>properly encode the parallel stanza here</lg>
        </note>
    </app>
</listApp>
```

## 6.2.2 <note> — Empty or with Contents

The content of the element <note> itself varies depending on the encoding context. On the one hand, it can be left empty if you are using one of the attributes to provide a link toward an external resource (§7.2.3) containing the relevant segment of parallel text. Several scenarios should be considered here:

1. you want to quote the parallel text by retrieving it automatically in display from an electronic edition of the text without actually duplicating it in your file — **for the time being, this is only a theoretical option that cannot be implemented yet**;

2. you want to quote the parallel text by duplicating it into your file;

3. you just want to display a textual reference without actually quoting the parallel text.
In the example that follows, there are two identical parallels for the passage in question and you, as editor, think it would be redundant to display their readings as they are identical to the relevant segment of the text you yourself are editing.<fnref n="72" />

### Example 6.2.2.A

```xml
<listApp type="parallels">
```

```xml
<app>
```

```xml
<note copyOf="txt:MDhŠ_08.00"/>
```

```xml
<note copyOf="txt:NarSm_04.12"/>
```

```xml
</app>
```

```xml
</listApp>
```

Even if you do not need to quote the parallel text, you may wish to comment on it and in that case your `<note>` shall no longer be empty by contain your free-text discussion of the parallel:

### Example 6.2.2.B

```html
<div type="dyad" n="4">
```

```html
<quote type="base-text" xml:lang="san-Latn">
```

```html
<supplied reason="implied">
```

```html
<lg met="anuṣṭubh">
```

```html
<| n="ab">hiṁsāṁ yaḥ kurute kaś cid deyaṁ vā na prayacchati |</>|>
```

```html
<| n="cd">sthāne te dve vivādasya bhinne 'ṣṭādaśadhā punaḥ ||</>|>
```

```html
</lg>
```

```html
</supplied>
```

```html
<listApp type="parallels">
```

```html
<app>
```

```html
<note>This stanza is absent from the constituted text of <bibl><ptr target="bib:Olivelle2005_01"/></bibl>, though it is referenced in his app. crit. for one manuscript. The stanza occurs in ed. <bibl><ptr target="bib:Mandlik1886_01"/>Mandlik</bibl> 8.4 with reading <foreign>bhinno</foreign>, where our text implies <foreign>bhinne</foreign>.</note>
```

```html
</app>
```

```html
</listApp>
```

```html
</quote>
```

```html
<p>hiṁsāṁ [...]</p>
```

```html
</div>
```

On the other hand, the `<note>` element can be given contents by providing the parallel text when this cannot be retrieved automatically and/or by giving complementary indications through a further embedded `<note>`. A simple option is to encode the parallel passage as a string of plain text, wrapped only in `<foreign>` (§8.10.2).

<footnote n="72">⁷² For the use made here of @copyOf, see §6.2.3.1.</footnote>
Example 6.2.2.C

<listApp type="parallels">
<app>
<note>Cf. Vṛh 61: <foreign><term xml:lang="san-Latn">akrodha</term> ṇaranya tan bvat sṛeṇen, <term xml:lang="san-Latn">guruśuśrūṣā</term> ṇaranya bhakty aguru, <term xml:lang="san-Latn">śauca</term> ṇaranya nitya majapa maradina śarīra, <term xml:lang="san-Latn">āhāralāghava</term> ṇaranya tan abvat iṇ pinaṇan, <term xml:lang="san-Latn">apramāda</term> ṇaranya tan paləhpaləha, pəṇpəṇen ikaṇ hurip sādhana niṇ magavaya yogasamādhi, hayva hinələmhələm, gavayakəna tekaṇ sādhana, sādhana ṇaranya ikaṇ yogamārga, makalarapan daśaśīla, ikaṇ daśaśīla umaṇunakən ikaṇ yoga</foreign>.</note>
<note>Cf. VS.04: <foreign><term xml:lang="san-Latn">akrodha</term> ṇaraniṇ tan kataman srəṇen. <term xml:lang="san-Latn">guruśuśrūṣā</term> ṇaraniṇ lot umulahakən siddhaniṇ svakāryaniṇ guru, gurubhakti kaliṇanya riṇ maṇkana, makanimitta hyuniran ruməṇvakən sarinahasyaniṇ varahvarah saṇ guru. <term xml:lang="san-Latn">śauca</term> ṇaraniṇ nityaśah mācamana sūryasevana ṇarcana ri bhaṭāra. <term xml:lang="san-Latn">āhāralāghava</term> ṇaraniṇ tan baraṇbaraṇ iṇ pinaṇan, <term xml:lang="san-Latn">apramāda</term> ṇaraniṇ tan paləhpaləh, an aṇabhyāsa ri saṇ hyaṇ kabhujaṅgan. ika ta kalima niyamabrata ṇa, liṇ bhaṭāra śiva</foreign>.</note>
</app>
</listApp>

But if it seems convenient (e.g., because you can copy-paste from a text edition already
available in TEI encoding) or useful for some other purpose, you may encode any parallel verse
text that you wish to include in your <listApp> using <lg> with as many <l> as needed (see
§3.4). If the parallel is in prose, you must use as many elements <p> or <ab> as necessary (see
§3.3). In addition, you can add an embedded <note> to highlight specific features of the quoted
passage. As you see, the embedded <note> element might also contain bibliographic
references, encoded as per §8.4.

Example 6.2.2.D

<listApp type="parallels">
<app>
<note copyOf="txt:MDhŠ_08.004"/>
<note corresp="txt:MDhŠ_08.058">
<lg>properly encode the parallel stanza here, using as many <l> as needed</lg>
<note>The paraphrase suggests that the received reading was <foreign>bandhyo</foreign>. But no such variant is reported in <bibl><ptr target="bib:Olivelle2005_01"/></bibl>.</note><!-- end of the embedded note -->
</note><!-- end of the embedding note -->
</app>
</listApp>

As shown in this example, the scenarios of an empty and a non-empty <note> can be combined
within the same <app>.

References can be provided using several solutions in the context of <note>, especially
considering that our use of the "txt:" prefix is currently theoretical, as explained in §7.1.3. You
can use `<ptr/>` or `<ref>` elements as described in §7.1.3.3 for citing text or in §7.2 for internal links as shown in the following example.

<caption>Example 6.2.2.E</caption>

```xml
<listApp type="parallels">
    <app><note corresp="txt:SMG_09.02">Cf. <ref target="DHARMA_CritEdSasanaMahaguru.xml#smg_09.02">SMG 9.2</ref>.</note></app>
</listApp>
```

## 6.2.3 <note> — Attributes

To qualify the nature of the parallelism, a set of attributes is available for use on the `<note>` for the parallel in question. The values for such attributes should always be built with the prefix `"txt:"` as described in §7.1.3.<fnref n="73" />

1. `@sameAs` or `@copyOf`: both of these attributes are used to identify identical content. See §6.2.3.1 below for further details.

2. `@corresp`: points to elements that correspond to the current element in some way but are not necessarily identical. See §6.2.3.2 below for further details.

The potential uses of such notation include the possibility of making concordances between other texts and yours. In the following paragraphs, we will furnish more detail on when and how to use `@sameAs`, `@copyOf` and `@corresp`.

### 6.2.3.1 @sameAs and @copyOf — Declaring an identical parallel passage

Two attributes can be used to express the identity of content: `@sameAs` and `@copyOf`. The former allows you to represent not only the fact that a segment of another text is identical in reading to the current segment of your text but also to reproduce the identical segment for analytical purposes (e.g. if its reading has been an argument for your choice between or even against transmitted readings of your text), while the latter enables you to represent the simple fact that identical contents is found in a parallel text, without repeating the textual segment in question.

Let us start with an example of `@copyOf`:

<caption>Example 6.2.3.1.A</caption>

```xml
<listApp type="parallels">
```

<footnote n="73">⁷³ Although it is allowed by the TEI, we have decided not to use the attribute `@source` in this context, since it does not allow qualifying the nature of parallels.</footnote>
You should use @sameAs if the parallel passage pointed to with this attribute is repeated in the current <note> (and, if necessary, commented upon in an embedded <note>):

<caption>Example 6.2.3.1.B</caption>

### 6.2.3.2 @corresp — Declaring a non-identical parallel text

Any correspondence other than that of identity between a textual segment of your edition and a segment of another text can be established through the attribute @corresp. This attribute implies nothing about the degree or the nature of the correspondence other than that the two segments match without being strictly identical. If they were, you would use @sameAs or @copyOf, as explained earlier in §6.2.4. As shown in several of the examples above, you can record any observations on the correspondence you have marked up by adding a <note>.

### 6.2.4 Associating a parallel to a segment of a stanza or paragraph

Besides the method of recording parallel passages which matches a parallel to an entire <p> or <lg> of text, discussed so far, it is also possible to match a parallel passage to a smaller segment. Two solutions are offered here, the choice between them depending on how complex it will be to encode the delimitation of the segment in question.

#### 6.2.4.1 Declaring a parallel for a segment within a text block

First, you can identify the segment for which there is a parallel using <lem> in an <app> within <listApp>, still to be declared (cf. §6.2.1) as the first sibling of the containing <p> or <lg>.

<caption>Example 6.2.4.1.A</caption>
<p> xml:id="skk_01.02">ini saṅ hyaṅ dasa-krəta, kundañən uraṅ reya, asiṅ nu dek nañjərkən saṅ hyaṅ sasana krəta, pakənən həbəl hirup(,) həbəl ñovana, jadyan kuras, jadyan tahun, dəgdəg tañjər, jaya praṅ, ñovana na uraṅ reya.</p>
<listApp type="parallels">
<app>
<lem>jadyan kuras, jadyan tahun</lem>
<note corresp="txt:PNJ_129"><foreign>jadyan kuras jadyan tahun</foreign>.</note>
<note corresp="txt:TB_35v"><foreign>pada ñovana, dadian kuras, dadian tahun, dadian kaneneh</foreign>.</note>
<note corresp="txt:MSJ_21"><foreign>maṅka jadiyan kuras jadiyan tahun</foreign>.</note>
<note corresp="txt:LK_137"><foreign>tətəñər jadian tahun, saṅ atuaṅ dina taraṅ, tətəñər jadian kuras, putər kuruṅ dina iruṅ</foreign>.</note>
</app>
</listApp>

The correspondence between the contents of <lem> and a segment of the text is not encoded in
any way and needs to be made by the reader of the edition. For this reason, the <lem> does not
need to be identical to the corresponding string in the body of your <p> or <lg>: you can
truncate it or modify it in any other way that seems useful (in the manner of <note
type="altLem"> in §5.3.1.1). As before, it is possible to assign a category to the parallelism with
an attribute. This method is recommended if the segment falls within a relatively short <lg> or
<p> and the reader will easily be able to match any lemma between the body of the text edition
and the display of parallels for that <lg> or <p>.

6.2.4.2 Declaring a segment of text using <anchor>

If you need to match your parallels with a longer paragraph (or stanza), or even across
structural boundaries, it may become difficult for you to match the contents of <lem> to the
relevant segment of edited text. In this case, we recommend that you use <anchor> elements at
the start and end of the segment and refer to these anchors in the <app> using the attributes
@from and @to, respectively for the beginning and the endpoint of the lemma.

<caption>Example 6.2.4.2.A</caption>

<p>kalaṅkaṅ saṅ hyaṅ dasasila, <anchor xml:id="anchor001"/>maya-maya saṅ hyaṅ dasa-marga, <anchor
xml:id="anchor2"/> kaprətyaksaan na dasa-indriya, pakən ṅrətakən di bumi lamba, di bumi parək.
</p>
<listApp type="parallels">
<app from="#anchor001" to="#anchor002"><note sameAs="txt:AmGu_34"/></app>
</listApp>

As before, it is possible to comment on the parallelism with a further <note>.

<caption>Example 6.2.4.2.B</caption>
<p>kalaṅkaṅ saṅ hyaṅ dasasila, <anchor xml:id="anchor001"/>maya-maya saṅ hyaṅ dasa-marga, <anchor
xml:id="anchor2"/> kaprятиaksaan na dasa-indriya, pakən ṅrətakən di bumi lamba, di bumi parək.</p>
<listApp type="parallels">
<app from="#anchor001" to="#anchor002">
<note>The same words also appear in AmGu.34.</note>
</app>
</listApp>

Please follow the numbering pattern for @xml:id shown above, raising the number of each new
<anchor> by 1 as you advance in your file, formatting it as a 3-digit number. Remember that you
may never declare two identical @xml:id in a single file, and that Oxygen will show your file to
be invalid if you do, mistakenly, reproduce a value that is already taken.

6.2.5 Associating parallel texts that are implied but unknown

As discussed in §4.6, if you expect the existence of a parallel text (for instance because your
author explicitly states that he is quoting another work) but no actual quotation from and/or
reference to a source text can be given, this shall be marked in a plain-text note:

<caption>Example 6.2.5.A</caption>

<div type="dyad" n="...">
<p n="1">ACTUALLY TRANSMITTED TEXT.
<listApp type="parallels">
<app>
<note>your note stating that parallels are expected but unknown</note>
</app>
</listApp>
</p>
</div>

Note that no attributes should be given for the element `<note>` in this case.

6.3 Encoding an external apparatus stanza-by-stanza

If your text is rigorously structured in verse form and you prefer not to adopt the parallel
segmentation method for encoding your critical apparatus, you can follow a structural approach
analogous to the one described in the section §6.2: each block of text will be immediately
accompanied by its associated apparatus, wrapped in <listApp> with @type="apparatus". This
<listApp> element should be the very first following sibling of the element (\<lg\>, \<p\> or \<ab\>) in
which the segment of text is wrapped. Inside <listApp>, each apparatus entry should be
encoded in a <app> element, on which you may provide a specification of the lemma's locus in
the edition using the attribute @loc.<fnref n="74" /> Do so by using the values given in @n attributes for your verse lines as in example 133. Copy the text of each lemma into <lem> and use the attribute @wit in the manner described in §5.4. The lemma declared for the <lem> element should normally be a copy of the relevant string inside the block of text.<fnref n="75" /> Variant readings should be encoded in an <rdg> element, as per §5.5, using the attribute @wit in the same way as in <lem>.

<figure><img src="image_18.png" /><figcaption>Example 6.3.B</figcaption></figure>

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

<footnote n="74">⁷⁴ The attribute @loc isn’t mandatory, but it is recommended for verse lines <l> to earn some processing time.</footnote>

<footnote n="75">⁷⁵ Though the same exceptions can be made here as those outlined in EGD §9.1.3.</footnote>
```xml
<lg>
  <listApp type="apparatus">
    <app loc="a">
      <lem wit="#msCb #msCa #msNb #msNb #msNc">atisaṁśayakaṣṭaṁ te</lem>
      <rdg wit="#msCa">atiśaṁsa</unclear>ya</unclear>kaṣṭan te</rdg>
      <rdg wit="#msCc #Ed">atiśaṁsayakaṣṭaṁ me</rdg>
    </app>
    <app loc="b">
      <lem wit="#msCa #msCb #msNa #msNb #msNc #Ed">dvijasattama</lem>
      <rdg wit="#msCc">ca dvijottamaḥ</rdg>
    </app>
    <app loc="c">
      <lem wit="#msCa #msCb #msNa #msNc">°jñeyaṁ</lem>
      <rdg wit="#msCc #msNb #Ed">°jñeya</rdg>
    </app>
    <app loc="c">
      <lem wit="#msCa #msNa #msNb #msNc #Ed">manuṣyais tu</lem>
      <rdg wit="#msCb">manuṣaiś ca</rdg>
      <rdg wit="#msCc">maṇukṣe</unclear>ptu</unclear></rdg>
    </app>
  </listApp>
</lg>
```

# 7. Referencing and cross-referencing

## 7.1 Links based on prefixes

It will happen often that you need to encode some piece of information that is stored outside of your TEI-XML working file. In order to facilitate project-wide consistency in storing and citing this kind of information, we have decided to create three different reference lists, containing relevant data on:

1. DHARMA project members ("part:");

2. Bibliographic references ("bib:");

3. Text editions, both machine-readable and non machine-readable ("txt:").

The declarations "part:", "bib:" and "txt:" are shortcuts to the files that list information of the these types. In brief, they work as pointers to the relevant external reference lists. In the following paragraphs, we give more detail regarding their respective functions. The correct path to the external files for participants, bibliographic resources, and text editions are provided in our
encoding template, in the `<encodingDesc>` within the element `<listPrefixDef>` as previously explained (§2.2).

### 7.1.1 part: — Referring to other DHARMA team members

The prefix `"part:"` stands for `"participants"` and works as an abbreviated reference to the file that lists the participants of the project, i.e. `"DHARMA_ IdListMembers_ v01"`, which you can find in the project documentation folder in GitHub.<fnref n="76" />

Within this reference file, each participant is encoded through the element `<persName>` bearing a specific `@xml:id`. Each `@xml:id` consists of four letters joined together, all lower-case: in simple scenarios, the two initial letters of a person's first name joined to the two initial letters of her/his surname, will form the identifier, but it is also possible to form identifiers from initials according to another pattern. For instance, `"dogo"` stands for Dominic Goodall and `"zapa"` for Zakariya Pamuji Aminullah, while `"amwb"` stands for Amandine Wattelier-Bricout.

You will need to point to the values of these `@xml:id`'s for instance if your digital edition is the fruit of multiple hands and, within your `<fileDesc>`, you need to declare who the editors are (see §2.1.1.2). Another situation in which these identifiers need to be used is when, in the `<revisionDesc>`, you want to signal who made certain changes to the text (see §2.2.3). Please bear in mind that, in order to correctly point to the relevant information, the value of the attribute you use (e.g. `@ref`, `@who`, etc.) will have to be built with the prefix `"part:"` followed by the identifier of the person.

### 7.1.2 bib: — Referring to items in the DHARMA Zotero Group Library

The prefix `"bib:"` stands for "bibliographic reference" and works as an abbreviated link to an item in the DHARMA project's Zotero group library. These bibliographic data are not encoded in an xml list, by contrast with our use of the prefixes `"part:"` and `"txt:"`. When you want to point to a specific bibliographic item from the common library, you must use its short title as declared in the Zotero item itself.<fnref n="77" />

### 7.1.3 txt: — Referring to editions of other texts

Reference to editions of other texts may need to be made more or less frequently in your own edition, for instance if you want to cite parallels to given segments of your digital edition or simply to justify some philological decision. When such a reference is made, you may be content with a simple abbreviation plus numerical sequence to indicate the text you are referring to, and the passage in it, but it may also be necessary to cite the words of the passage referred to, and in the latter case it might be convenient to be able to retrieve the passage to the cited automatically. In the context of a collective research project, it is desirable for the same text editions to be used whenever the given text needs to be cited, and for the titles of texts to be referred to by a uniform set of abbreviations and with a uniform reference pattern. Such uniform indications of passages in other editions are here called "canonical references" and are built

<footnote n="76">⁷⁶ Available in the [project-documentation repository](https://github.com/dharmaroma/project-documentation).</footnote>

<footnote n="77">⁷⁷ For the project's use of Zotero's Short Title field, see the ZG §4.10.</footnote>
with the prefix "txt:" standing for "text edition". After this prefix shall follow the canonical
reference that itself consists of two parts. The first part (e.g. MaBh for Mahābhārata) is the main
identifier of the record and must match a declared @xml:id in the project's authority file for text
editions (see §7.1.3.1). The second part provides the textual locus or range with reference to
the numerical position of structural elements of the edition.

### 7.1.3.1 Entries in the txt: authority file

In the authority file,<fnref n="78" /> each text is encoded within a <bibl> element, bearing a specific <abbr
type="siglum"> and, built on the siglum defined therein, an @xml:id for the <bibl> entry as a
whole.

<caption>Example 7.1.3.1.A</caption>

```xml
<bibl corresp="bib:Olivelle2005_01" xml:id="EdMaDhaSa2005">
  <abbr type="siglum">MāDhŚā</abbr>
  <title>Mānava-Dharmaśāstra</title>
  <ptr target="https://raw.githubusercontent.com/sarit/SARIT-corpus/master/manusmrti.xml"/>
</bibl>
<bibl corresp="bib:Acri2017_01" xml:id="EdDhPa2017">
  <abbr type="siglum">DhPāt</abbr>
  <title>Dharma Pātañjala</title>
  <ptr
    target="https://raw.githubusercontent.com/erc-dharma/tfd-nusantara-philology/master/editions/DHARMA_CritEdDh
    armaPatanjala.xml"/>
  <msIdentifier>
    <settlement>Berlin</settlement>
    <repository>Staatsbibliothek</repository>
    <idno>MS Schoemann I-21</idno>
  </msIdentifier>
</bibl>
```

As the example shows, within each <bibl>, you can encode the following types of information:

1. the existence of a digital representation of the text edition (although we show only examples of .xml format, digital representations in .txt or .html formats can be referred to in analogous fashion)

2. the relevant Zotero item for the published edition of reference

3. the manuscript on which the edition of reference is based (an option that should be used only if the edition of reference is based on a known codex unicus)

In defining the siglum, you are free to use diacritical marks. Although we recommend
constructing sigla by using the first two letters of each element of the text's title, and a capital
letter on the first letter of each segment, we recognize that it will be very hard across a large

<footnote n="78">78 Available in the [project-documentation repository](https://github.com/Project-Documentation/project-documentation).</footnote>
scholarly community to arrive at a consensus on how to form sigla, and that the choices made in the example will look strange to many team members.<fnref n="79" />

The @xml:id will then be constructed using the same siglum, but stripped of any diacritical marks, with the letters “Ed” as prefix, and with the year in which the edition was published as suffix. If you need to encode more than one edition per text, you will need to create a separate <bibl> for each edition.

A <ptr/> element can be provided for the edition if a digital representation thereof is available, and it will be a requirement to furnish such a <ptr/> element if any automated text retrieval is envisaged (see §7.1.3.3).

### 7.1.3.2 Quoting entries from the txt: authority file

You will need to point to the values of the @xml:id of these bibliographic items when encoding in your xml file the reference to the given text edition, using either the element <note> bearing the attributes @sameAs, @copyOf, @corresp (see §6.2.3) or the element <ptr/> (§7.1.3.3). The values of these attributes should always be prefixed by “txt:”, and end with the textual reference separated from the @xml:id by an underscore, as shown in the following example.

<caption>Example 7.1.3.2.A</caption>

```xml
<listApp type="parallels">
    <app>
        <note sameAs="txt:EdMaDhSa2005_08.069"/>
    </app>
</listApp>

 <!-- this example shows a case where you are content with the structure of the digital representation and don't need to specify anything more -->
<listApp type="parallels">
    <app>
        <note sameAs="txt:EdMaDhSa2005_08.069-08.070"/>
    </app>
</listApp>

 <!-- this example shows a case where you are citing a parallel that is two consecutive stanzas long. Any range is expressed with a hyphen separating the full expression of the starting and ending points -->
<listApp type="parallels">
    <app>
        <note sameAs="txt:EdMaDhSa2005_08.069.cd txt:EdMaDhSa2005_08.080.ab"/>
    </app>
</listApp>

 <!-- this example shows a case where you are citing a parallel that is discontinuous, e.g. the second half of a stanza 8.69 plus the first half of a stanza 8.80 -->
```

<footnote n="79">⁷⁹ For the moment, we offer no solution that would allow team members to display sigla other than those defined in <abbr> according to the pattern recommended here, or various team members each to define their own <abbr> for the same text title. But it can probably be done by removing the @xml:id from the containing <bibl> and defining a separate @xml:id in each respective <abbr>. The pattern for forming xml:id's will then need to be redefined.</footnote>
```xml
<listApp type="parallels">
    <app>
        <note sameAs="txt:EdMaDhSa2005_08.070">
            <bibl><ptr target="bibl:Olivelle2005_01"/></
            <citedRange unit="chapter">8</citedRange><citedRange unit="stanza">69</citedRange>
            <bibl></bibl>
        </note>
    </app>
</listApp>

 <!-- this example shows a case where the stanza numbering of the digital resource diverges from that of the printed edition -->
<listApp type="parallels">
    <app><note sameAs="txt:EdAmGa1981_03">
        <bibl><ptr target="bibl:Atja+SalehDanasasmita1981_01"/></
        <citedRange unit="page">1</citedRange><citedRange unit="line">6</citedRange>
        <bibl></bibl>
    </note>
</app>
</listApp>

 <!-- this example shows a case where the digital resource is structured with xml elements while the corresponding printed edition needs to be cited by page and line numbers -->
```

Any locus or sequence of text should be expressed in two parts separated by an underscore.<fnref n="80" />
The first part consists in the @xml:id of the text edition, while the second part defines a locus or a sequence (expressed as starting point plus ending point separated by a hyphen). This second part needs to represent the structural pattern of the chosen text edition. For instance, if you want to reference stanzas 29 and 30, in chapter 12 of book 1 of the *Mahābhārata*, the reference would be MaBh_01.12.29-01.12.30. The sequence is to be given in its full length and may not be shortened. This is to ensure that ranges across structural boundaries are handled efficiently.

Thus far the theory of our system. In reality, as the previous example with various scenarios suggests, there is probably no limit to the potential complexity of references that you may need to make. For this reason, the system proposed above with location references after an underscore is only an imperfect prototype. While we recommend using the above system as much as possible, your files will also validate if you limit yourself to citing the edition's @xml:id and omit the underscore and numerical specification. However closely or less closely you follow the above encoding model, it will in all cases be necessary to spell out in human-readable manner what you wish to appear in display.

Example 7.1.3.2.B

<footnote n="80">⁸⁰ This separator is chosen in order to comply with some of the recommendations established by Canonical Text Services (CTS). This is a protocol to identify texts or fragments of text following the classical notions of “work” and “citation” used in the humanities with the aim to make them retrievable through a network service. It was built by Christopher Blackwell and Neel Smith as part of their Homer Multitext project.</footnote>
```xml
<listApp type="parallels">
    <app>
        <note sameAs="txt:EdMaDhSa2004_08.069">MāDhŚā 8.69</note>
        <note corresp="txt:EdDhPa2017">DhPāt (p. 124) read the same stanza with variant <foreign>guru</foreign> instead of <foreign>ācārya</foreign> in the last <foreign>pāda</foreign>.</note>
    </app>
    <app>
        <note corresp="txt:SHP_5b">Cf. SHP 5b: <foreign>ika sarva janma, ikaṇ janma tumuvuh, janma triyak, janma mrēga pasu paksi, janma mavoṇ, janma siṅ voṇ, vastuniṅ voṇ, samaṇkana kvehiṇ janma pamētuanikeṇ lanaṇ vadon</foreign>. Possibly <foreign>mavoṇ</foreign> should be emended to <foreign>voṇ</foreign> and vastuniṅ to <foreign>vastu siṅ</foreign>.
        </note>
    </app>
    <app>
        <note corresp="txt:SMG_21.1">
            Cf. <ref target="DHARMA_CritEdSasanaMahaguru.xml#sasanamahaguru_21.01">SMG 21.1</ref>: <foreign>ini catur-rahayu ṇaranya, silokanya nihan, mas pirak komala hintēn, kaliṇanya, mas ta ma ṇaranna, sabda tuhu tēpēt bēnēr, byakta pañcaksara, pirak ta ma ṇaranna, ambēk krēta, yogya rahayu, komala ta ma ṇaranna, gēiṇṇa caaṇ padaṇ, heraṇ lēga loganda aṅn-aṅṇanna, hintēn ma ṇaranna, caṇciṇ sēri, sēmu imut, sēmu guyu, rame ambēk.</foreign>.</note>
        </app>
    </app>
</listApp>
```

On the use of `<ref>` in the last scenario, see §7.2.2.1.

### 7.1.3.3 Shortcuts for citing texts

If you need to cite a text declared in the authority list in any free-text section, such as in a `<p>` or in a `<note>`, you can use an empty tag as a shortcut to mention its title or siglum. The logic is the same as in section §2.1.4. See the following examples:

#### Example 7.1.3.3.A

```
<note>While <ptr rend="title" target="txt:EdAmGa1981"/> appears ...</note>
```

Display —

While Amanat Galuṅguṇ appears ...

#### Example 7.1.3.3.B

```
<note>While <ptr rend="siglum" target="txt:EdAmGa1981"/> appears ...</note>
```

Display —

While AmGa appears ...
The empty element `<ptr target="txt:EdAmGa1981"/>` works as a pointer to the @xml:id of the text defined in the authority list from which we will retrieve the title. You can add an attribute @rend to select a specific rendering, whether only the siglum or the whole title of the work: the latter might be preferable for instance when the siglum is ambiguous or not universally recognized. Choose between the values "title" and "siglum" to fill in the attribute @rend. Note that the `<ptr/>` element calling an item from the txt authority file must have one of these values for @rend, if not nothing will be displayed at all.

#### 7.1.3.4 Automatic retrieval?

Automatic retrieval of the text of another edition — a theoretical desideratum alluded to in the introduction to §7.1.3 — is basically only manageable if the other edition is rigorously structured, and preferably encoded in TEI-XML, a condition which is only rarely fulfilled in our field at this time. The practical consequences are that you will always need to insert passages to be cited into your file and that the encoding of canonical text references as described in the §7.1.3.2 helps to lend more semantic specificity to your TEI file but serves no computational process in our system for the time being.

## 7.2 Other links

Note that in this section, you will only find a solution for ad-hoc linking that should only appear in freeform text elements such `<note>`. Several linking mechanisms are available in the DHARMA encoding model. The main two possibility at your disposal are:

1. `<ptr/>` — an empty element that points to an external resource with the attribute @target

2. `<ref>` — a text-containing element whose contents will be hyperlinked to the resource declared in the attribute @target

When using the first solution, you must always be aware of how textual content will be generated automatically to anchor the link identified in the attribute, while in the second solution, you will be able to decide on your own which text is used as anchor for the hyperlink.

### 7.2.1 Making links inside your edition using identifiers

In various contexts, both a human text editor and a computer will need to be able to establish unambiguous connections between distinct blocks of text. To make this possible, our system requires unique identifiers for block elements (defined through @xml:id attributes). We have opted for a referencing system based on the mark-up of your text edition. The unique reference pattern is autogenerated by stringing together the sequential values corresponding to each level of the document hierarchy, each number being separated from the next by a full-stop.<fnref n="81" /> Each

<footnote n="81">⁸¹ This means that our system uses identifiers in the form of an untyped path. The other solution would have been to use identifiers with typed paths. It would have required the identifier of a block element to be</footnote>
such identifying pattern is anchored by the value of the @xml:id declared on the <TEI> root of
the edition, followed by an underscore.<fnref n="82" />

### 7.2.1.1 Identifying patterns for block-level containers

In order to identify the structural hierarchy of the xml, attributes @xml:id will be inserted into
your code to allow cross-referencing to <div>, <p>, <ab>, <lg> or <quote> segments of your text
edition.<fnref n="83" /> This will be done through an XSLT transformation process that can be launched and
relaunched by the project's XML-TEI Data Manager at the encoder's request.<fnref n="84" /> The values
assigned to the elements will reference the sequential numbers of the parent <div> and of the
elements <ab>, <p>, <lg> and <quote> within that <div>. This means that in some cases, the
<div> identifier can diverge from the editorial numbering pattern reflected in your @n attributes.
It also means that if you are making any changes to the structure, all the identifiers will have to
be updated. Such updating is not without consequences since it will break any link based on the
previous identifiers. So be careful before making structural changes and do not forget that you
will have to update any encoding that references internal identifiers.

In the following example, the first <div> element used to enclose an invocation has
received an @xml:id numbered in relation to its position in the file's internal hierarchy, even
though it is the second <div> that is marked by the attribute @n as the first chapter of the text.

<caption>Example 7.2.1.1.A</caption>

```xml
<div xml:id="rsisasana_01">
    <ab xml:id="rsisasana_01.01" type="invocation" xml:lang="san-Latn">[...]</ab>
</div>
<div n="1" type="chapter" xml:id="rsisasana_02">
    <lg xml:id="rsisasana_02.01" met="upajāti">[...]</lg>
    <p xml:id="rsisasana_02.02">kaliñanya, [...]</p>
</div>
```

The @xml:ids can be used to interlink or reference segments of texts elsewhere in the file (see §7.2.2.3). They will become indispensable if you are dealing with prose or stanzas interrupted by base text, scenarios discussed in §4.7.1 and §4.7.2. Once each segment has its own @xml:id, you can interlink the segments with the attributes @prev and @next, used to identify the previous segment and the next. 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

built with the element name, a hyphen, and a number, for instance p-2, which seemed undesirably
verbose to us. See TEI Guidelines, Chapter 16.1 on links and Chapter 16.2 on pointing mechanisms.

<footnote n="82">⁸² See TEI Guidelines, Chapter 1.3, part 1.1.1 about Element Identifiers and Labels.</footnote>

<footnote n="83">⁸³ Note that the identifiers generated by our system will take the file's element <text> as their hierarchical
starting point. However, the element <text> itself is omitted from the identifying patterns. We have opted
for this starting point rather than the <body> element to prevent identifiers being assigned to components
inside any <front> and <back> elements that are present (see §10.1 and §10.2). If the need to refer to
front/back matter appears at some point in the project, contact the project's XML-TEI Data Manager.</footnote>

<footnote n="84">⁸⁴ The XSLT file to generate the numbering pattern can be found in the project-documentation github
repository.</footnote>
together and can, if necessary, be used to reconstitute the base text without interspersal of
dependent text.

### 7.2.1.2 Identifying patterns for other containing elements

Some other elements can also be given an identifier to handle cross-referencing and linking
elements across block boundaries. Among those elements, we foresee such a pattern could be
useful for `<term>`, `<lem>` and `<app>`.<fnref n="85" /> For those three elements, the identifying pattern should
be the name of the element followed by a 3-digit number for `<term>` and a 5-digit number for
 `<app>` and `<lem>`, i.e. `term001`, `lem00001` and `app00001`. See §5.2.4 and §4.8 for more about
their use.

### 7.2.1.3 File internal links

Once the `@xml:id` attributes have been generated (as per §7.2.1.1) for every structural element of your edition (`<div>`, `<lg>`, `<p>` and `<ab>`), it will be possible to reference any of those elements by their unique identifier. To create a link toward another part of your edition from a free-text part, you can use the element `<ref>` with the attribute `@target` filled with the identifier of the element you want to mention with the hashtag symbol. For instance, if you want to link a note with the chapter 2, you will provide the identifier of this chapter in the `@target` attribute.

#### Example 7.2.1.3.A

```
<ref target="#svayambhu_03">See the same phenomenon in chapter 2</ref>
```

### 7.2.1.4 Shortcuts for citing a part of the edition

If you want to quote a part of your edition, you can use the `<ptr/>` element with the identifier of the said part, preceded by a hashtag, as value for `@target`. The display will then be the name or the attribute `@type` of the element and the `@n` attribute provided with it. For instance, if no attributes have been associated with the element you are referencing, a number based on the occurrence of the element in your edition will be automatically generated. If you require a custom display, we recommend you use the solution with `<ref>` explained just above (§7.2.1.3).

#### Example 7.2.1.4.A

```
<app>
```

```
<lem type="conj"><supplied reason="omitted" evidence="internal">daṇḍa riṇ trivarṇa,</supplied></lem>
```

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

```
<note>Our restitution is based on the parallel in <ptr target="#svayambhu_07.01"/></note>
```

```
</app>
```

Display —

782. (daṇḍa riṇ trivarṇa,) *conj.*, om. L K M • Our restitution is based on the parallel in *dyad 109*.

<footnote n="85">⁸⁵ Feel free to contact the XML-TEI Data Manager if you need another element to be numbered.</footnote>
## 7.2.2 Making links with resources outside the edition

### 7.2.2.1 Create a link between two DHARMA editions

The solution provided above to create a link between two elements in the same file can be used to create a link between two XML files created in the DHARMA framework. You should use the element `<ref>` around a human-readable reference like the title of the text you want to link to. To generate the hyperlink, you must also reference an attribute `@target` in which you should give the full name of the file of the text.

<caption>Example 7.2.2.1.A</caption>

```xml
<ref target="DHARMA_CritEdSvayambhu.xml">Svayambhu</ref>
```

If you want to provide a specific reference to a part of the text encoded in TEI in DHARMA framework, you will use the element `<ref>`. The value of the attribute `@target` shall be built using the filename, followed by a hashtag symbol and then by the `@xml:id` of the part you want to reference. In the following example, a link is made with the *Siksa Guru*, Chapter 7, first paragraph, encoded in XML-TEI by Aditia Gunawan. In the relevant XML file, the *locus* is identified as `@xml:id="siksaguru_07.01"`.

<caption>Example 7.2.2.1.B</caption>

```xml
<note corresp="txt:SiGu_7.1"><ref target="DHARMA_CritEdSiksaGuru.xml#siksaguru_07.01">SiGu 7.1</ref>
<foreign>hana kapiṅpitunya sih saṅ paṇḍita, ri saṅ sevaka dharma, saṅ hyaṅ caduśakti saṅ paṇḍita, ĩa, apa kari mataṅ yan caduśakti, ĩa, pat śakti, ĩa, bisanya, ya ta pinakasañjata saṅ paṇḍita, ndya ya nihan, cakra jalakuna, cakra jalapakṣa, cakra sambharaṇa, cakra taraṅgabāhu</foreign>.</note>
```

### 7.2.2.2 Making a hyperlink

The element `<ref>` can also be used for regular hyperlinks with any external resources to the project. In this case, the `@target` attribute shall contain a well-formed URL, ideally a permalink. Be extra careful about filling any exterior link since we would like as much as possible to avoid such links being broken.

<caption>Example 7.2.2.2.A</caption>

```xml
<ref target="https://erc-dharma.github.io/">See DHARMA temporary static website</ref>
```
# 8. Encoding additional information in the edition

## 8.1 Milestone elements: pages, folios and lines

In the TEI context, a milestone is an empty element that marks the transition from one physical or textual unit to another.

Dedicated milestone elements to encode page beginnings <pb/> — the term “page” here also includes manuscript folios — and line beginnings <lb/> are not expected in most of the DHARMA project’s digital critical editions, since we are generally dealing with critical editions based on more than a single witness. An exception can be made if you have a limited number of witnesses and you wish to encode the place where, in relation to your edited text, a given witness switches from one folio, or folio-side, to another (see §8.1.2).

An exception must also be made when you are encoding a critical edition that has already been published in printed format, or are using a printed edition among your witnesses; for such cases, see §8.1.1.

### 8.1.1 Lines and pages for printed editions

We do not recommend that you encode any manuscript line beginnings in a critical edition. However, if you are editing a text for which there is a **published edition** of reference, you can encode its page and line beginnings using the <pb/> and <lb/> elements, in combination with the attribute @source to identify the edition in question (see §7.1.2).

We suppose that generally it will make sense to encode page beginnings of the edition of reference, and if this seems useful, then it may also also be useful to encode its line beginnings. If you do encode any page (and line) beginnings, then you must make sure that every one of them is represented in your digital edition.

You should use the attribute @n, converting any non-Arabic printed numbers to their Arabic equivalents, to record the page numbers of the printed edition. For numbers indicating printed lines, it is sufficient to mark the line beginnings with <lb/> without applying @n — the machine can do the counting, provided that you do not skip any line beginnings. Page or line beginnings occuring in the middle of a word must bear the attribute @break with the value “no”.

86

### 8.1.2 Folios

In some cases, it may also be deemed useful to represent the folio beginnings of your manuscript witnesses, though we do not expect the need to encode manuscript line beginnings to arise in many critical editions. For folio beginnings, you must use the same element <pb/> as used for the pages of printed editions. But, contrary to what might be expected on the basis of how witnesses are to be identified in your critical apparatus (§5), in this case you cannot use the

<footnote n="86">⁸⁶ EGD §3.2.4, §3.5.5 as well as §8.1.2, §8.1.3, §9.1.6.</footnote>
attribute @wit to identify them, because the TEI has not foreseen this option. As a workaround, you should use `<pb edRef="#..."/>`, and fill in the siglum of the witness as defined in `<sourceDesc>`, e.g. `<pb edRef="#B"/>`. Note that the attribute @edRef is a pointer, so that the identifier must be prefixed here with `#`.

To indicate the number and side of **manuscript folios**, you should add the attribute @n whose value shall be the folio number and one-letter indication of its side (recto/verso): "1r", "1v", "2r", "2v" and so on. Manual encoding of @n is always necessary on elements `<pb edRef="#..."/>`. As in the case of printed editions, if your `<pb/>` occurs in the middle of the word, you should add the attribute @break with the value "no".

In cases where two witnesses move from one folio or folio-side to the next at exactly the same locus — a situation that is especially common at the beginning of texts — you must use two `<pb/>` elements (`<pb edRef="#A"/><pb edRef="#B"/>`) and you must specify the respective folio numbers and sides by using @n (`<pb edRef="#A" n="3r"/><pb edRef="#B" n="4r"/>`). Note that it is this need to use @n that stands in the way of encoding in the usual way, which would be `<pb edRef="#A #B"/>`.

The following is an example of the beginning of an edition encoded from a printed edition based on a codex unicus:

Example 8.1.2.A

`<pb edRef="#EdA" n="194"/>`

`<ab type="invocation"><pb edRef="#msA" n="0v"/><lb n="1"/>siddhir astu</ab>`

## 8.2 Notes

Insertion of free-text notes into your edition is constrained. It is only possible to do so at the end of any `<app>` element and at the very end of one of only four block-level containers (after any final punctuation), namely after prose paragraphs (`<p>`), after invocations or colophons (`<ab>`), after whole stanzas (`<lg>`) or after verse-lines (`<l>`). See respectively §5.10.1 and §6.1. Of course it is also possible to insert notes into paragraphs of your translation (see §9.1.4.5) and your `<teiHeader>`. In all cases, you will use the element `<note>`. Generally, it will be necessary to make sure the contents of a `<note>` is a full sentence, beginning with a capital letter and ending with a punctuation mark (though not in a `<note>` used to record a parallel passage, §6.2). Where relevant, insert the `<note>` after any adjacent punctuation mark, not before it. The contents of notes may be structured into paragraphs by creating `<p>` elements within the `<note>`, when the note amounts to more than a few sentences. Keep in mind that in this case, all the contents of `<note>` should be contained inside a `<p>` element.

If you are not the author of the note's contents, you may use the attribute @resp or @source to declare someone else's authorship. To give credit to another member of the project, use @resp, while @source should be used only if the note is adopted verbatim from a publication. Alternatively, it is possible to declare the author of the original note using the regular
bibliographic citation system (see §8.4), or, depending on the context, simply by referring to the author's name.

We do not require the systematic use of @xml:lang with <note>. Its use would be expected to set the correct language on the content to avoid the inheritance from the one declared at the <text> level (see §8.10.1). However, to avoid repeating the same information in every <note> element, our system assumes that @xml:lang="eng" is implied by default. It means that, if you provide a note in another language, for whatever reason, the declaration of the language becomes mandatory with @xml:lang. Also, note that a similar omission of declaration of language is tolerated on elements such as <q> and <foreign> (see respectively §8.3.2 and §8.10.2), even if explicit declaration is recommended.

Finally, you can differentiate your <note>s using the @type attribute based on a subject, e.g. <note type="commentary">. The values are left to your own discretion based on the needs of your edition. Please contact the XML-TEI Data Manager before doing so.

## 8.3 Quotations

Generally, while encoding quotations, do not add any quotation marks, as they will be generated by the transformation process, provided that proper tags have been applied. However, if for any reason you do not encode the quotation with TEI tags, then type quotation marks explicitly.

When citing original-language text from a publication, you should generally follow DHARMA transliteration conventions. This also holds, for instance, when citing readings from published sources in your apparatus, when citing translations or when stating paraphrased/summarised opinions. But if they stand inside a <quote>, any transliterated words in the cited text shall be retained in their original form rather than being converted to the DHARMA system.

### 8.3.1 <cit> and <quote> – Cited Quotation

To encode quotations from an external source, with accompanying information about its origin, it is good practice (though not mandatory) to use the element <cit> as a container and a <quote> element inside the <cit>. The second child element of <cit> may be <bibl>, <ptr/> or <ref>, depending on whether the source cited is a bibliographic entry or digital resource.<fnref n="87" />

For the first situation, use the element <bibl>, if you are quoting this material from a published work (see §8.4.1 on how to do use <bibl> with <ptr/>).

<caption>Example 8.3.1.B</caption>

```xml
<cit>
  <quote></quote>
  <bibl><ptr/></bibl>
</cit>
```

<footnote n="87">⁸⁷ See TEI Guidelines, chapter 3, part 3.3.</footnote>
For the second situation, use the element `<ref>` around the reference in the manner described in §7.2.2.

<caption>Example 8.3.1.A</caption>

```xml
<cit>
  <quote></quote>
  <ref></ref>
</cit>
```

Note that it is also possible to use `<quote>` without using `<cit>`. Whether or not you use `<cit>`, the use of `<quote>` should be limited to actual (multiword) quotations from another scholar's work. In all other situations, we recommend using `<q>`.

## 8.3.2 <q> – Quoted Material

The element `<q>` is semantically less specific than `<quote>`. It can be used quite freely and the transformation routine will represent it as single quotation marks. We expect `<q>` to be applied for stating the meanings of words or phrases in commentary, for representing in an edition that a given segments is direct speech, and no doubt there are other scenarios too where `<q>` will be useful.

<caption>Example 8.3.2.A</caption>

```xml
<note>There is no verbal form in the entry s.v. <foreign>śanku</foreign> 1 (<q>a particular kind of weapon</q>).
The passive irrealis form used here is spelled with an <foreign>h</foreign>, which serves to bridge the hiatus
between base and suffix <foreign>-en</foreign>.</note>
```

When using `<q>`, as when using `<quote>`, you should not type quotation marks. Nonetheless, if you need more control on the display, it is possible not to use any tag and directly to write the desired characters. This method should be reduced to special cases as much as possible.

## 8.4 Bibliographic References

### 8.4.1 Bibliographic citations with Zotero

Bibliographic citations may be used in any part of your XML file. Their main container is `<bibl>`. The empty element `<ptr/>` should mandatorily appear as the first element within `<bibl>` and contain the attribute `@target`, whose value shall be the Zotero Short Title of the cited publication, prefixed with the string `bib:` (see §7.1.2).

To give further specification regarding the part of the publication concerned, add the element `<citedRange>` as a second child of `<bibl>`. Its content should specify the relevant
structural units of the publication being cited. If you need to refer only to page numbers, there is no need to add any other content: `<citedRange>103</citedRange>`. If you do need to refer to any other textual units, add the attribute `@unit` and fill it in with one of the following values:

* "appendix"

* "book"

* "entry"

* "figure"

* "item"

* "line"

* "note"

* "page"

* "part"

* "plate"

* "table"

* "section"

* "volume"

The content of each element should normally consist mainly in numbers. Any range should be recorded using a hyphen to separate the starting point from the ending one, both points being expressed in full (e.g. `<citedRange>123-124</citedRange>`, not 123-4 or 123-24). To list non-adjacent elements, use a comma followed by a space, e.g. `<citedRange>12, 24</citedRange>`.

Example 8.4.1.A

`<bibl><ptr target="bib:Naerssen1976_01"/><citedRange>301-302</citedRange></bibl>`

Display —

van Naerssen 1976: 301–302.

If the name(s) of the author(s) of the work has/have already been mentioned in the sentence and need not appear again in the hyperlinked display of the reference, use the attribute `@rend` with the value "omitname" in the `<bibl>` element; if you expect to show "ibid.", use the value "ibid" for `@rend`.<sup>88</sup>

Example 8.4.1.B

`<bibl rend="omitname"><ptr target="bib:Naerssen1976_01"/></bibl>`

Display —

<footnote n="88"><sup>88</sup> All this section is following recommendations established by the EGD, see §10.4.5.</footnote>
(1976)

Example 8.4.1.C

<bibl rend="ibid"><ptr target="bib:Naerssen1976_01"/><citedRange>301-302</citedRange></bibl>

Display —

ibid.: 301–302

## 8.4.2 <title> – Encoding titles

Should you need to quote a title in any notes or commentary, tag it with the element <title>. It is basically up to you what you consider to be a title, whether designations of epigraphic or non-epigraphic primary sources, designations of secondary sources regardless of whether they are cited in full, in abbreviated form or with a known acronym, etc.<fnref n="89" /> The default rendering of segments tagged with <title> will be italic.

Example 8.4.2.A

<note>This is the second of two stanzas interpolated after 8.82 recorded in Olivelle's edition, found in his witnesses GMd1 KSS Dave. Cf. <title>Ślokāntara</title> 7 <foreign>nāsti satyāt paro dharmo nānṛtāt pātakaṁ paraṁ | triloke ca hi dharma[ḥ] syāt tasmāt satyaṁ na lopayet ||</foreign>. The latter stanza is also transmitted in <title>Tantri Kamandaka</title> §63.</note>

Display —

This is the second of two stanzas interpolated after 8.82 recorded in Olivelle's edition, found in his witnesses GMd1 KSS Dave. Cf. Ślokāntara 7 nāsti satyāt paro dharmo nānṛtāt pātakaṁ paraṁ | triloke ca hi dharma[ḥ] syāt tasmāt satyaṁ na lopayet ||. The latter stanza is also transmitted in Tantri Kamandaka §63.

When this is not desired, add the attribute @level with the value "a" (for "analytic"), in which case the content will be displayed with quotation marks rather than italics, or use the attribute @rend with the value "plain" to obtain a title without any kind of typographic distinction from its surrounding text.

Example 8.4.2.B

<note>This is the second of two stanzas interpolated after 8.82 recorded in Olivelle's edition, found in his witnesses GMd1 KSS Dave. Cf. <title>level="a">Ślokāntara</title> 7 <foreign>nāsti satyāt paro dharmo nānṛtāt pātakaṁ paraṁ | triloke ca hi dharma[ḥ] syāt tasmāt satyaṁ na lopayet ||</foreign>. The latter stanza is also transmitted in <title>level="a">Tantri Kamandaka</title> §63.</note>

<footnote n="89">⁸⁹ Follow the rules given in the EGD, §10.4.2</footnote>
Display —

This is the second of two stanzas interpolated after 8.82 recorded in Olivelle's edition, found in his witnesses GMd1 KSS Dave. Cf. "Ślokāntara" 7 nāsti satyāt paro dharmo nānṛtāt pātakaṁ paraṁ | triloke ca hi dharma[ḥ] syāt tasmāt satyaṁ na lopayet ||. The latter stanza is also transmitted in "Tantri Kamandaka" §63.

Example 8.4.2.C

<note>This is the second of two stanzas interpolated after 8.82 recorded in Olivelle's edition, found in his witnesses GMd1 TMd4 Tr1 MTr4 MTr6 [Jolly Gr] Mandlik [ta] KSS Dave. Cf. <title rend="plain">Ślokāntara</title> 7 <foreign>nāsti satyāt paro dharmo nānṛtāt pātakaṁ paraṁ | triloke ca hi dharma[ḥ] syāt tasmāt satyaṁ na lopayet ||</foreign>. The latter stanza is also transmitted in <title rend="plain">Tantri Kamandaka</title> §63.</note>

Display —

This is the second of two stanzas interpolated after 8.82 recorded in Olivelle's edition, found in his witnesses GMd1 KSS Dave. Cf. Ślokāntara 7 nāsti satyāt paro dharmo nānṛtāt pātakaṁ paraṁ | triloke ca hi dharma[ḥ] syāt tasmāt satyaṁ na lopayet ||. The latter stanza is also transmitted in Tantri Kamandaka §63.

## 8.5 @resp – Attributing responsibility

It is possible to declare intellectual responsibility with the attribute @resp. It can be added to any XML element to encode the fact that a particular project participant is the author of that particular item. At the first stages of the project, since you will work mainly on your own, you will surely not need this attribute often. But when reviews will start, it will allow us to identify interventions made by various members of the project.

The attribute @resp should contain the personal identifier of the project member preceded by the prefix "part:" (see §7.2.1). To credit more than one participant, separate each identifier with a blank space.

## 8.6 Encoding diplomatic features

All features described in the project's Encoding Guide for Diplomatic Editions are also available for use in apparatus entries, particularly in <rdg>. Besides elements such as <gap>, <supplied>, <surplus>, <add>, <del>, <unclear> that we have already presented above,<fnref n="90" /> we may mention here the possibility of using <space> and <g> in the manners prescribed in the EGD.

It is also possible to expressing uncertainty using the attribute @cert="low" with the elements <unclear>, <supplied>, <num> and <seg>, as well as @precision="low" and <certainty/> with the element <gap/>, as in the following example.<fnref n="91" />

<footnote n="90">⁹⁰ EGD §4, §5 and §6.</footnote>

<footnote n="91">⁹¹ EGD §2.3.4 and §5.4.6</footnote>
<caption>Example 8.6.A</caption>

```xml
<gap reason="lost" quantity="30" unit="characters">
  <certainty match=".." locus="name"/>
</gap>
```

## 8.7 Encoding indexables

All elements useful to distinguish certain segments from the surrounding text because they can be of interest in a database, to facilitate the creation of an index, or even to support search functionality, such as names, dates, numbers and abbreviations should be encoded in the same manner as has been described in the EGD.<fnref n="92" /> Thus, the elements `<persName>`, `<roleName>`, and `<placeName>` for places and people, as well as `<abbr>`, `<num>`, `<measure>` and `<date>`, are all available for use in a critical edition, inside or outside apparatus entries. Note that `<lem>` or `<rdg>` can be used within them as needed to record variant readings. For instance, see the following example with `<abbr>`. You can decide which one of those elements, if any, should be encoded depending on your text and research aim.

<caption>Example 8.7.A</caption>

```xml
<app>
  <lem type="emn">
    <abbr>mā</abbr>
  </lem>
  <rdg wit="#L #K #M">ma:s.</rdg>
</app>
```

## 8.8 About formatting

### 8.8.1 `<hi>` – Typographical formatting

It is possible to state explicitly how characters should be formatted in the display without making any statement as to why they are formatted that way. We foresee this manner of encoding being used for defining the formatting of sigla for witnesses (see §2.1.3) and whenever you wish to cite as such the formatting of a passage quoted from another scholar's work. Use the element `<hi>` with the attribute `@rend` with one to several of the following values:

* "italic"

* "bold"

* "subscript"

* "superscript"

<footnote n="92">⁹² EGD §7.</footnote>
We also offer the possibility of using `<hi>` with `@rend="check"` during the preliminary stage of the editing process, as shown in §8.11.

### 8.8.2 `<list>` – Encoding lists

If needed, you can format text as a structured list using the elements `<list>` and `<item>`. Although our schema allows their use in most contexts, we recommend avoiding use of these elements in your text edition to avoid the code (and the display) becoming too complex. By contrast, in the context of translation, or in the metadata to your edition, you may feel free to make use of list elements.

Within an enclosing element, typically `<p>` or `<ab>`, create a list with the element `<list>` and inside it an element `<item>` to wrap each component of the list. Several styles are available by adding the attribute `@rend`. For instance, `@rend="bulleted"` creates a bulleted list and `@rend="numbered"` will create an auto-numbered one. If you require a list with headwords and their descriptions, you will need to add an element `<label>` around the first and an element `<item>` around the second, both working as an alternating sequence inside the main `<list>`.

Without any attribute or `<label>`, the default display of a list will be that each item is displayed in a new line with an indent.

## 8.9 Marking *metri causa* spellings or word forms

If your text contains spelling anomalies because the author needed to resort to such means to accommodate the meter, it is possible to mark anomalous spellings by using the diplomatic element `<orig>` within a `<seg>` and apply to the latter the attribute `@type` with the value `mc`, abbreviated for *metri causa*.

**Example 8.9.1.A**

```
yak<seg type="mc"><orig>a</orig></seg>ragaņa
```

Should you wish to record the normalized (but contextually unmetrical) spelling, you must add the element `<reg>` and wrap it together with `<orig>` in an element `<choice>`. This will notably allow you to harvest even anomalously spelled attestations of a given word when lemmatizing a text's vocabulary.<fnref n="93" />

**Example 8.9.1.B**

```
yak<seg type="mc"><choice><orig>a</orig><reg>ā</reg></choice></seg>ragaņa
```

<footnote n="93">⁹³ Even though they are verbose, those solutions seemed the best compromise between possible data treatment, TEI encoding model and coherence with DHARMA practices so far.</footnote>
## 8.10 About languages

### 8.10.1 @xml:lang – identifying languages

The language of each TEI file for a critical edition is set as English. This is done through an attribute @xml:lang="eng" furnished in the root element <TEI> in our templates. This default setting is to be understood as the language applied to all children elements. The language code "eng" is taken from the ISO standard 639-3.

Since the default language of the file is set as English, the general rule is that any segment whose contents is in another language should be explicitly marked with its own suitable @xml:lang.<fnref n="94" /> This means that your critical edition should be given its own @xml:lang on the <text> element.<fnref n="95" /> A text originally written in any Indic script and edited in Romanised transliteration should be suffixed with "-Latn", as per the ISO standard 15924. Without this suffix, it will be assumed that the edition is given in the native script associated with the language given for the region and time period.

<caption>Example 8.10.1.A</caption>

```xml
<text xml:space="preserve" xml:lang="osn-Latn">
```

Your edition being contained in <text>, whenever you yourself are speaking as editor, in English, the above logic would require you to redeclare English as the current language using attribute @xml:lang. However, we have made an exception to this rule in the case of editorial use of <note>.

Translations, being encoded in <text> elements that do not bear an @xml:lang (§9.1.2.1), automatically inherit the language value of the root element <TEI> and are hence by default understood to be in English. But if you provide a translation in French, for instance, or in another language than English, you will need to provide the language code on the <text> element.

### 8.10.2 Tagging text segments in another language

If the text you are editing takes recourse more or less exceptionally to other languages, which might be labeled ‘foreign’ from the point of view of the text’s main language (as defined in the element <text>), it will be interesting to use the element <foreign> in order to facilitate specific modes of display and data treatment.

Any smaller text segment (a word, a sentence or an even bigger portion of text below the paragraph level) that is formulated in such a ‘foreign’ language, should be marked with <foreign> in combination with the attribute @xml:lang if more than two languages have been

<footnote n="94">⁹⁴ All of the language codes relevant for the project are shown in §Appendix B.</footnote>

<footnote n="95">⁹⁵ The <div type="edition">, which may be familiar to some from EpiDoc, has not been retained in the present guide (see §3.1).</footnote>
identified in <langUsage> in the <teiHeader> (see §2.2.2). If only two languages have been identified, then it is not mandatory to encode @xml:lang on <foreign>, though we still recommend doing so systematically, especially if you require language sensitive treatment of the textual data (e.g. for indexing), and use of @xml:lang on <foreign> is mandatory in any case when more than two languages have been identified in <langUsage>. In case you are facing a segment as large as a whole block-level container (<ab>, <p>, <l>, <lg>) or even a <div>, then it is expected that the @xml:lang for the relevant 'foreign' language is indicated on the container. In that case, it is still possible to use <foreign> though its sole purpose will then be to trigger a special mode of display such as italics.

<caption>Example 8.10.2.A</caption>

```xml
<text xml:space="preserve" xml:lang="kaw-Latn">
    [...]
    <p xml:id="siksaguru_13.03" xml:lang="osn-Latn"><foreign>ma<p edRef="#B" n="38v"/>na duka ku ulahta, ku
    [...]
    <app><lem wit="#A #C">duka</lem><rdg wit="#B"/><rdg></app> ku ulahta, ku sabdata, ku
    ambəkta.</foreign></p>
    [...]
</text>
```

## 8.11 Validation and review process

To help you keep track of segments of your edition that need to be double checked in the review process, it is possible to add the attribute @rend with the value "check" to the relevant element. The resulting display of the content will be a yellow highlight.

<caption>Example 8.11.A</caption>

```xml
<app>
    <lem type="conj" rend="check">aṅkən</lem>
    <rdg wit="#L #K">hankan</rdg>
</app>
```

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

We recommend using the attribute @rend="check" as high as possible in the file's hierarchy in order to avoid needing to repeat the attribute several times on children elements. To identify a specific part of the text which does not match any already existing tags, you can add the
element `<hi>`. It is understood that the editor will gradually clear the XML file from any occurrences of `@rend="check"` as the finalization of the editions comes into sight.

Within verse lines where a given reading is not yet acceptable because non-compliant with the meter, it is also possible to use the more specific value `"unmetrical"`, yielding a pink highlight, to mark readings that will need to be rechecked and perhaps modified further down the editorial process. If your final conclusion is that the metrical irregularity is authorial, then encode the line (or stanza) as per §3.4.4.

<figure><img src="image_21.png" /><figcaption>Example 8.11.B</figcaption></figure>

Be extra careful when using both `@rend="check"` and `@rend="unmetrical"` together. The first value will always have the priority over the second, meaning that yellow highlighting will render pink highlighting invisible.

Finally, we remind you of the need to encode significant changes in the status of your work in the manner described in §2.2.3.

## 9. Encoding translations

Translations of critical editions as well as diplomatic editions are to be done in separate files. This decision has been taken to reduce the length of the files and to facilitate working with files for edition and translation in parallel. The edition file will be understood as the main source file, while translation files will be regarded as secondary and linked to the main file. Every translation file should have a structure exactly matching the structure chosen for the edition. If, for whatever reason, you decide to encode two distinct translations (for instance, one into French and one into English), they shall be encoded in separate files. Creating a secondary file to go with your edition will require you to follow some recommendations regarding metadata.<fnref n="96" />

<footnote n="96">⁹⁶ A template is available in the [project-documentation](https://github.com/project-documentation) gitHub repository.</footnote>
## 9.1 <teiHeader> for translations

The metadata of your edition as a whole shall be declared in the `<teiHeader>` element of the main source file. See section §2 of this guide. The translation `<teiHeader>` shall not contain any repetition of those metadata already declared about the edition and the witnesses for instance, though some basic information is required for the sake of traceability. Indeed, one of the downsides of separating the edition and translation into distinct files is the risk of losing the link between the translation(s) and the edition. For this reason, metadata need to be provided to identify the file and allow restoring the relationship with the main source file.

The main parts of the `<teiHeader>` are respected, meaning that you will find a `<fileDesc>` gathering a `<titleStmt>`, a `<publicationStmt>` and a `<sourceDesc>`, followed by an `<encodingDesc>` as well as `<revisionDesc>`. This section will only give rules specific to the translation and suppose you know the basics of encoding a `<teiHeader>` as already explained above for the edition.

It is expected that you give a `<title>` with attributes `@type="main"` and `@subtype="translation"`. If necessary, you can reuse the possibilities offered by the model of the edition, by adding another title with the attribute `@type="subtitle"` and `@subtype="translation"`. We don't expect any copy and paste of the `<editor>` and `<respStmt>` elements declared in the main file, but rather that you declare the people involved specifically with the translation work and provide a description of their role with the element `<resp>`. However, if the `<editor>`s are the same, feel free to declare them identically.

You will also need to provide a full `<publicationStmt>`; follow the section §2.1.2 of this guide to fill it in. The only difference will concern the `<idno type="filename"`. Indeed, it has to follow the file naming conventions set for the translation file and not for the critical editions files. See FNC §2.2.4.

The main changes will be situated in the `<sourceDesc>` element. First, you will need to declare a `<biblFull>` element and copy and paste the `<titleStmt>` and `<publicationStmt>` sections of the edition file. If your translation reproduces one that has already been published in another format, add an element `<biblStruct>` to declare it. Declare sources for the translation even if you have reworked it, and without consideration for the length of elements that have been integrated into your translation. But if it is unpublished, you can declare all the authors in the `<teiHeader>` thanks to the `<respStmt>`. If you are dealing with a complicated case, you may provide a `<notesStmt>` section, with a `<note>` to explain more precisely the work of each person involved, in free-text.

<caption>Example 9.1.1.A</caption>

```xml
<sourceDesc>
  <biblFull> <!-- Copy and paste the titleStmt and publicationStmt of the edition file -->
    <titleStmt>
      <title type="main">Svayambhu</title>
      <title type="sub" subtype="editorial">Digital Critical Edition and Translation of an Old Javanese Juridical</title>
    </titleStmt>
  </biblFull>
</sourceDesc>
```
<figure><img src="image_22.png" /></figure>

The `<encodingDesc>` will at least contain the `<projectDesc>` element with its first mandatory `<p>` about the DHARMA project. If you have provided another explanation about your own project, please copy and paste it into your translation file as well. Any other elements used for the main edition in `<projectDesc>` are available for the translation, but none are mandatory. Use them depending on your needs to describe specific choices regarding the translation itself. See the section §2.2 to identify all the elements at your disposal.

Finally, keeping track of the important steps in the development of your work is still recommended with the element `<revisionDesc>` and the use of the `<change>` elements. See the section §2.2.3.
## 9.2 Structuring the translation

### 9.2.1 `<text>` and `<body>` elements

To structure the translation, follow the main rules set out for the edition and explain under §3. Add the mandatory elements `<text>` (with an attribute `@xml:space="preserve"`) and `<body>`.

If your translation is given in English, then you won't need to declare a new attribute `@xml:lang` on the `<text>` element, since it will be declared by default of the `<TEI>` root. However, if your translation is given in any other language, please declare the `@xml:lang` with the matching ISO standard 639-3 code. See §Appendix B.

### 9.2.2 `<div>` – Sections of translations

Then use the `<div>` elements to reproduce the main sections of your edition. We expect you to keep the `<div>` used for invocations and colophons, as well as those used for chapters and cantos, keeping both attributes `@n` and `@type`.

The editorial element `<head type="editorial" xml:lang="eng">` can be kept in your translation. It is not required that you keep it, if you have added one in your edition. However, if you decide to keep it, make sure to encode it right after the opening part of the relevant element, as the first child of `<div>`; delete the `@xml:lang` element if you are in an English translation. If you want to keep the `<head type="editorial">`, even if it does not match the language of the translation itself, then keep the attribute `@xml:lang="eng"`.

### 9.2.3 Structural organization of the translation

The main unit level for translated text will be the paragraph. All three of the elements `<p>`, `<ab>` and `<lg>` used in the edition will be represented in the translation with `<p>` elements.

For paragraphs translating an original in verse form, you can use the attribute `@rend="stanza"` to obtain a verse-type display. In that case, it is necessary to reproduce the attribute `@n` from the `<lg>` in the edition in its corresponding `<p>`.

## 9.3 Identifying correspondence with editions

### 9.3.1 Parallelism with the edited text

To match segments of translation with the corresponding segments of edited text, we will make use of the `@xml:id` attributes on the elements `<div>`, `<p>`, `<ab>`, `<lg>` and `<quote>` declared in the edition. In the corresponding `<p>` elements of the translation, apply the attribute `@corresp` and assign as value the `@xml:id` of the relevant block of edition preceded by a `#`.
Example 9.1.3.1.A

<div type="chapter" n="1" xml:id="#siksaguru_01">

<head type="editorial" xml:lang="eng">Pure
Circle of Three Bodily Domains</head>

<p xml:id="siksaguru_01.01"><pb edRef="#A"
n="1v"/><pb edRef="#B" n="1v"/>ndah nihan
varahakna mami rumuhun ri sañ sevaka dharma,
katēkan kita rumēñēkēn kavivekan sañ hyañ dharma,
mvañ kabyavasthānikañ sañ hyañ ajñāna, hana trikāya
maṇḍala pariśuddha*, āranya, inujarakēn sañ paṇḍita
ri sañ sevaka dharma, nyāpan tahan kveki ulah śabda
lavan ambēk, yan kva hana ma<pb edRef="#B"
n="2r"/>līna ri hṛdayanta*, ya teka prih
pēgēñēn<supplied reason="omitted">,</supplied>
rakṣa pahayu juga ya, apan hetuniñ manēmvakēn
sukhaduhkha halahayu.</p>

[...]

</div>

<div corresp="#siksaguru_01">

<p n="1" corresp="#siksaguru_01.01">I will first
teach the servant of the <foreign>dharma</foreign> as
follows. You will succeed in listening to the discussion of
the holy <foreign>dharma</foreign> and the determined
state of the holy gnosis. There is what is called the pure
circle of three bodily domains,<note><foreign>trikāya
maṇḍala pariśuddha</foreign>:</note>: On the concept of the
pure circle of three bodily domains, see Chapter 10,
§Dharma and Three Bodily Domains.</note> uttered by
the teacher to the servant of the
<foreign>dharma</foreign>. That is possibly the action,
speech, and mind. If there is a feeling of loss in your
heart,<note>The emendation of
<foreign>prdayanta</foreign> into
<foreign>hṛdayanta</foreign> is not only easily
justifiable on palaeographic grounds (the similarity of
<foreign>aksara pa</foreign> and
<foreign>ha</foreign>), but also based on the
connection of <foreign>līna</foreign> 'feeling of lost'
with <foreign>hati</foreign> 'heart' in several OJ texts.
Cf. RY 24.41: <foreign>aḍā kalana līna riñ
hati</foreign>.</note> it is them that should be
practiced and restrained. You should just guard them
and fix them, for they are the causes of finding joy and
sorrow, good and bad.</p>

9.3.2 Declaring the authorship of on a translated segment of text

In case of a translation written by several authors and/or encoding parts or a whole previously
published translation, you can use both the attributes @resp and @source to provide a sharper
delimitation of the authorship than what is possible with declaring it in the <teiHeader>:

* use the attribute @source on structural elements, such as <div> or <p>, for which you want to declare the author and its publication. Fill it in with the prefix "bib:" and the Zotero Short Title of the publication.

* Use the attribute @resp on structural elements to credit a member of the DHARMA project. Add the prefix "part:" and her/his DHARMA unique identifier.

If several publications or project members are involved, it is possible to declare several
references in those two attributes, as long as you add a space between each.
## 9.4 Markup available with a <p> of translation

If you have encoded an edition, you do not need to replicate all its encoded features in the translation. You may, however, want to mark up segments of the translation itself, for instance when the translation skips segments of the edition or, inversely, when the translation contains segments that find no correspondence in the edition. Note that miscellaneous encoding elements such as `<foreign>` or `<hi>` are available as well as `<note>` to insert remarks of the translator that are not part of the translation per se.<fnref n="97" />

### 9.4.1 Additions into the translated text

Restoration of segments in edited texts should be translated. When the restored text corresponds to a lost content, use the attribute `@reason` with the value `"lost"` in combination with the element `<supplied>`. But if the content was omitted by the scribe, use the value `"omitted"` for the attribute `@reason`.

Any addition made in the translation that does not find its equivalent in the edition should be identified with the element `<supplied>`. But we will distinguish between additions made in order to clarify the translation in the target language, those made to obtain a clear syntax and those used for disambiguation purposes. The first case shall be expressed with the attribute `@reason` with the value `"subaudible"`. Those parts don't find any equivalent in the edited texts. Their use isn't mandatory and it is left to the encoders to use them or not depending on how literal the translation is.

The second case should be identified with the value `"subaudible"`. It must be used for words that are not explicit in the edited texts, but that need to be made explicit to arrive at a proper sentence in the target language. Use it for cases where you need to signal accuracy of your translation.

The final case will be encoded with the value `"explanation"` for the attribute `@reason`. You should use it to tag any supplementary words provided for clarification which are motivated by the syntax of the target language. The `<supplied reason="explanation">` can also be used in combination with the element `<foreign>` to provide the original words from the edited text inside your translation.

### 9.4.2 Lacunae

Lacunae that can't be restored should be encoded with the `<gap/>` element and the attribute `@reason` with value `"lost"` (cf. the rules concerning use of `<gap/>` in various subsections of §5.5). If your intent is to represent a segment of text that has been skipped in the translation because it is not intelligible, then use the element `<gap/>` with `@reason="ellipsis"`. In the former case, we might expect either, for short segments of text, the `<supplied reason="explanation">`

<footnote n="97">⁹⁷ Most of this section will follow features already made available in DHARMA EGD from section §9.2.9 to §9.2.14.</footnote>
with the child element `<foreign>` replicating the unintelligible text, or else, in case of larger
segments of text, a `<note>` element to provide an explanation of what the missing part is.

The approach with `<gap reason="ellipsis"/>` can also be used to encode any extent of
texts that you deem unnecessary to translate (e.g. in the case of highly repetitive texts). We
recommend in this case to also provide an explanatory `<note>` element right after the ellipsis.

### 9.4.3 Expressing doubts and flagging problems

It is possible to express your doubts or uncertainty for any translated word or sentence by
adding an attribute `@cert="low"` on the semantic elements. If no element is available around the
segment of text you would like to identify as an attempt, use the element `<seg cert="low">`.

This doubt might arise from your own tentativeness or from the edited text being unclear,
illegible, or restored, or by the language itself.

When text seems inappropriate as well as unexpected, tag the equivalent in the
translation with the element `<sic>`.

### 9.4.4 Indicating bitextuality

It is possible to represent both meanings in a double entendre in your translation. To do so,
wrap the secondary and less literal meaning between an element `<seg>` with the attribute
`@rend` with the value `pun`. The meaning you have chosen to identify as the most literal won't
bear any markup.

### 9.4.5 Providing notes

You may add any necessary `<note>` in your translation as long as they are contained inside the
`<p>` that structure the translation and as long as the basic rules already stated in the section
§8.2 are followed. It is possible to distinguish notes based on their content to distribute them in
different blocks or levels of footnotes. In this case, use an attribute `@type` which values are left
to your consideration. Please contact the XML-TEI Data Manager, if you intend to use `@type` on
`<note>` in your translation.

## 10. Encoding published books

If you are encoding an edition that has already been published in traditional book format, you
might wish to encode all its sections like the preface, the introduction and so on. Two elements
are available to reproduce what comes before and after the edition itself: `<front>` and `<back>`.
They should be used as children of the `<text>` element. Logically, the element `<front>` should
come before the `<body>`, while the `<back>` must come after it. Two possibilities are offered to
you:
1. you adapt the edition to fully match the rules stated for natively digital editions, i.e. separating in different files the content and declaring the witnesses in the `<teiHeader>`.

2. you favor a sort of facsimile version of the published critical edition. In this scenario, follow the rules stated here to organize the content in a single file using the elements `<front>` and `<back>`. Whatever the published edition does, it is expected that you reproduce the apparatus as an internal one, but if you deem it impossible, you can always revert to an external kind of apparatus following rules provided under §6.3.

## 10.1 `<front>` – Front Matter

If you have chosen the second encoding strategy to deal with an already published critical edition, you will store all the content coming before the edition itself inside the `<front>` element. It can contain an introduction with a survey of witnesses and sources, and possibly other content as well. Each subsection of the front matter should be given its own `<div>` with a unique `@xml:id` identifying it.

In this case, which amounts to creating a kind of facsimile of the published critical edition, your `<front>` will probably contain a survey of the witnesses and sources, the bibliography, and other information that may be of interest. It means that no witness information shall be declared in the `<teiHeader>`. Instead, please follow rules to encode the witnesses as if they were declared in the `<teiHeader>` (see §2.1.3), especially the rules for making machine-actionable sigla. Contact the XML-TEI Data manager if you are in this situation. Every globally permitted element is available to encode the content of the front matter.

<figure><img src="image_23.png" /><figcaption>Example 10.1.A</figcaption></figure>
## 10.2 <back> – Back Matter

By contrast, the content of the back of an already published edition shouldn't be encoded. Indeed, the edition being encoded, all of the traditional content found at the end of a text edition (glossary, indexes, bibliography) can be generated automatically and adding it manually in the xml file will be redundant. Nevertheless, if it is necessary, the <back> element is still available as the last child of <text>. Before starting to encode <back>, we recommend that you contact the XML-TEI Data manager.

If a <back> element is added, use the same kind of structure as the one used for the front matter. A <div> shall enclose each subsection and needs to have its own @xml:id attribute.

<caption>Example 10.2.A</caption>

```xml
<text>
  <front>
    <div></div>
  </front>
  <body>
    <div></div>
  </body>
  <back>
    <div type="section" xml:id="bibliography">
      <head>Bibliography</head>
    </div>
  </back>
</text>
```

# Appendix A: Editorial Conventions

## 1. How to represent punctuation?

For **Indian texts** entirely formulated in Sanskrit, follow the convention of ending half stanzas with a single *daṇḍa* | and whole stanzas with a double *daṇḍa* ||. In prose contexts, use single *daṇḍas* as lowest level punctuation mark while reserving double *daṇḍa* to mark paragraph ends. A text edition shall not normally make use of any western punctuation marks such as colon or semicolon. Many editors declare that the punctuation of their editions are entirely editorial and make no attempt to record the actual punctuation found in their witnesses.

For **texts transmitted on Java and Bali**, by contrast, we recommend making exclusive use of western punctuation marks, especially comma and full-stop, and you may also use colon and semi-colon if they seem useful. In our (limited) experience, the punctuation of witnesses tends to be relatively uniform from one witness to another and tends to be a useful guide to
parsing texts. If you find this to be the case also in the text you are editing, then you may make it a principle to retain use comma when your witnesses use a lower-level punctuation sign and a full-stop when they use a higher-level sign. Should you adopt the principle that punctuation of your edition is normally compliant with the transmission, the you must use <supplied> to insert any untransmitted punctuation and can use <surplus> to suppress any transmitted punctuation. Or you can decide upon a policy that leads to fewer editorial brackets in your edition.

Whatever you do, declare explicitly what is your policy, using the <punctuation> element in <editorialDecl> (see §2.2.1.1).

## 2. Spelling normalization in editing Indonesian texts

As stated in the preliminaries, a critical edition is supposed to follow the loose transliteration scheme offered in the DHARMA Transliteration Guide. This means, i.a., that a critical edition should not contain any vowel killers, and that some distinctions made in strict transliteration need to be abandoned. Notably, strict *ṁ* and *ṅ* should merge into loose *ṅ* while strict *h* and *h* should merge into loose *h*. If your text contains any Sanskrit, retain these distinctions only in the Sanskrit context. The distinction between lowercase and uppercase for independent vs. dependent vowels should also be abandoned in your critically edited text.

The following normalization rules apply to the constituted Old Javanese and Old Sundanese text:

* freely insert ə in order to make lexical items and affixes closer to the normalized spelling familiar from OJED

* some examples within a base: *tmən* → *təmən*, *vnaṅ* → *vənaṅ*

* a frequently occurring case involves the suffix -akən/-akəna, often spelled -akn/-akna, to be normalized as -akən/-akəna.

* freely adjust manuscript readings involving the signs s, ś, and ṣ to effect compliance with dictionary spellings

* freely remove spelled *h-* if the dictionary spelling of a word as an initial vowel

* freely simplify geminate spellings at word or morpheme boundaries to effect compliance with dictionary spellings

* The *visarga* (*h*) followed by the fricative (h) is merged into *h*, for example

* maḥhala → mahala

* The *anusvāra* (*ṁ*) followed by the velar nasal (*ṅ*) becomes a single *ṅ*

* paṁṇaduA → paṇadua

* The combination of *layar* followed by *r* is reduced to *r*

* kasampərīran → kasampəran

* interpret any *ulu ricem* in **Sanskrit** segments as plain *m*

* normalize vowel length of words borrowed from Sanskrit as well as indigenous words

* in **Old Sundanese** context, any vowel marker added to a ligature with *pasangan* *y*, intended to be pronounced before the *y* (*Cyi* and *Cye*) is to be rendered as intended (*CViya* or *CVeya*), for example *syi* → *siya*, *rye* → *reya*.
### 3. Variant readings deemed insignificant in Indonesian texts

Unless there is any other reason to report witness readings, feel free not to consider any instances of the following list as insignificant variants and hence to ignore them altogether in your apparatus (§5.2.2):

* the difference between <lem> and <rdg> would concern only the normalization implemented pursuant to the above rules for the constituted Old Javanese text

* the difference between <lem> and <rdg> would concern only presence/absence of comma punctuation

* the difference between <lem> and <rdg> would only concern vowel length

* the difference between <lem> and <rdg> would only concern difference between single and geminate consonant

* the difference between <lem> and <rdg> would only concern the fact that one or more witnesses show a *m̃* on the wrong syllable without the misplacement of *m̃* generating any possible meaning

* the difference between <lem> and <rdg> would only concern difference between *dm* and *nm*

* the difference between <lem> and <rdg> would only concern sibilants (ś/ṣ/s)

* the difference between <lem> and <rdg> would only concern *a* and *ə*

* the difference between <lem> and <rdg> would only concern aspirated/unaspirated consonants

* the difference between <lem> and <rdg> would only concern intrusion of *h* in *pasangan* for vowel initial suffixed (type *tinulishakən* for *tinulisakən*)

* the difference between <lem> and <rdg> would only concern dental/retroflex consonants

* the difference between <lem> and <rdg> would only concern *e/ai* or *o/au*

* the difference between <lem> and <rdg> would only concern *Cva/Co* or *Cya/Ce* (with *C* standing for any consonant)

* the difference between <lem> and <rdg> would only concern *C/Cra/Crə/Cru* (with *C* standing for any consonant)

* the difference between <lem> and <rdg> would only concern *a/aha/ā*

* the difference between <lem> and <rdg> would only concern the difference *v/uv/h/Ø*

* include under this heading variants such as

* *mavyavahāra/mavyava:ra*

* *mamuhaka/mamvaka*

* *sa:kṣyakna/sakṣihakna*

As per §5.4, the reading of any @wit inside <lem> should in most circumstances be silently normalized on the same points. E.g., even if witness L actually shows manavādi, it may still be cited in support of a <lem>mānavādi</lem> because the difference between ā and *a* is among the cases listed above.
As per §5.5.1, strict transliteration is to be used when you do cite any readings from a witness in <rdg>.
Appendix B: Language Codes

<table><thead><tr><td>Language</td><td>Code</td></tr></thead><tbody><tr><td>Undetermined language</td><td>unknown</td></tr><tr><td>Arabic</td><td>ara</td></tr><tr><td>Balinese, old or modern</td><td>ban</td></tr><tr><td>Batak, old or modern</td><td>btk</td></tr><tr><td>Burmese, modern</td><td>mya</td></tr><tr><td>Burmese, old</td><td>obr</td></tr><tr><td>Cham, modern (of Phanrang)</td><td>cjm</td></tr><tr><td>Cham, modern (of Cambodia)</td><td>cja</td></tr><tr><td>Cham, old (also known as "Old Cam")</td><td>ocm</td></tr><tr><td>Dutch</td><td>ndl</td></tr><tr><td>English</td><td>eng</td></tr><tr><td>French</td><td>fra</td></tr><tr><td>German</td><td>deu</td></tr><tr><td>Indonesian</td><td>ind</td></tr><tr><td>Japanese</td><td>jpn</td></tr><tr><td>Javanese, modern</td><td>jav</td></tr><tr><td>Javanese, old</td><td>kaw</td></tr><tr><td>Kannada, old or modern</td><td>kan</td></tr><tr><td>Khmer, Middle</td><td>xhm</td></tr><tr><td>Khmer, modern</td><td>khm</td></tr><tr><td>Khmer, old</td><td>okz</td></tr><tr><td>Malay, modern (Bahasa Malaysia)</td><td>zlm</td></tr><tr><td>Malay, old</td><td>omy</td></tr><tr><td>Mon, old</td><td>omx</td></tr><tr><td>Oriya</td><td>ori</td></tr><tr><td>Pali</td><td>pli</td></tr><tr><td>Prakrit</td><td>pra</td></tr><tr><td>Pyu</td><td>pyx</td></tr><tr><td>Sanskrit</td><td>san</td></tr><tr><td>Sasak</td><td>sas</td></tr><tr><td>Sundanese, old</td><td>osn</td></tr><tr><td>Tagalog, old or modern</td><td>tgl</td></tr><tr><td>Tamil, old or modern</td><td>tam</td></tr><tr><td>Telugu, old or modern</td><td>tel</td></tr><tr><td>Vietnamese</td><td>vie</td></tr></tbody></table>