- even characters that are only slightly damaged or have been executed with only slight awkwardness may need to be marked up as <unclear cert="low"/> if the context permits a variety of plausible alternative readings, chiefly in unintelligible or only partly understood contexts (e.g. names, words foreign to the language of the inscription, or in case of extensive damage to the context)

### 5.3.3. Ambiguous characters

- if a damaged or malformed character affords a **limited number of alternative interpretations** and the context gives no clear indication of which is correct, each alternative must be listed in individual <unclear> tags, wrapping the list in the <choice> element to show that only one of these goes in the given locus

- e.g. `g<choice><unclear>ŋ</unclear><unclear>ra</unclear></choice>ha`

- alternative readings may affect the editorial spacing of the text differently; see §8.1.2 for some guidance in such cases

- ambiguities involving **more than two alternatives** may be marked up simply by adding further <unclear> elements within <choice>

- it is, however, recommended that you limit the number of alternatives to no more than three, and in the rare case where a higher number of genuinely plausible alternatives are possible, instead record the most likely one as <unclear> and mention the others in your commentary or apparatus

- also keep in mind that those readers of your edition who are interested in possible alternatives can be expected to be familiar enough with the script in question to be able to work out those possible alternatives once they have received indication that a certain character is unclear

- we shall not attempt to rigorously **assign probabilities** to each alternative, not even by using @cert for some of the alternatives

- instead, put what is by your judgement the most likely alternative first, and the others in order of decreasing probability

- as for unclear markup in general, feel free to **ignore trivial ambiguities** that can be resolved confidently on the basis of the context

- in particular, when some pairs of characters look very similar (or wholly identical) in the script of your inscription, it is recommended that you record the expected reading without any markup, e.g.

- if a word looks like *ṣahārāja* in an inscription where *ṣa* and *ma* are very similar, simply record *mahārāja*

- if a word looks like *sambatsara* in an inscription where *ba* and *va* are very similar, simply record *samvatsara*

- **but**, if these words were to occur in an inscription which elsewhere clearly distinguishes the relevant pairs of characters, you would record *ṣahārāja* (marked up as a scribal error, §6.2) and *sambatsara* (as a valid alternative spelling, optionally marked up as non-standard, §6.3)

- and if an alternative reading alters the meaning **in a non-trivial way**, e.g. if in an inscription where the *akṣaras* A and *su* are very similar, a word could be read as *Adharma* or *sudharma*, then the ambiguity should definitely be marked up (unless, again, you are absolutely confident that it is ruled out e.g. by sandhi or by the wider context)

### 5.3.4. Reading difficulties below the akṣara level

- do not resort to sub-*akṣara* markup (§4.1.2) just because there is some uncertainty regarding one or more specific components of a complex *akṣara*; instead, aim to make the most of Romanisation, which allows you to single out precise segments of text smaller than one *akṣara* of the original

- thus, if only a certain character component of the original script is unclear or ambiguous, then do not use tags around the transliteration of the entire *akṣara*, e.g.

- `sph<unclear>u</unclear>rad` and NOT `<unclear>sphu</unclear>rad`

- `<ut<orig>ph</orig>annasya` and NOT `<u<orig>tpha</orig>nnasya`

- likewise, for local markup affecting several transliterated characters, feel free to put the start and end tags at boundaries not perceptible in the original script, e.g.

- `jayamit<unclear>ray</unclear>ā` and NOT `jayami<unclear>trayā</unclear>`
- localising markup in this precise way allows you to rely on the expertise of the readers of your edition to figure out the exact locus of doubt within a complex original character and its possible implications

- both in fairly straightforward situations, where the reading of a particular component is doubtful:

- if you have a reasonable guess for the identity of this component, then simply mark it up as unclear (§5.3.1), e.g.

- rddh with a tentatively read *e*: rddh<unclear cert="low">e</unclear>

- readers conversant with the language and the script will still be able to think of other possible readings (e.g. what looks like an *e* marker may be damage, in which case the vowel is *a*; or the marker may be a damaged *ai* or *i* or *o*)

- if you have a small number of reasonable guesses for an unclear component, then mark it up as ambiguous (§5.3.3), e.g.

- rddh with what may be *i* or *ī*:

rddh<choice><unclear>i</unclear><unclear>ī</unclear></choice>

- if you do not know and prefer not to guess whether a vowel marker was attached to a damaged character, then you may still choose to mark it up as a tentative *a* (implying that a different vowel is conceivable) instead of using complex markup, e.g.

- *k* with plenty of damage around it, which may obscure a vowel mark: *k<unclear*

cert="low">a</unclear>

- and in more complicated situations, such as

- when the **identification of a component may affect its place in the reading sequence:**

- if you have a reasonable guess for the identity of this component, then still simply mark it up as unclear (§5.3.1), e.g.

- *ddha* with a probable *repha*: <unclear>r</unclear>ddha

- readers conversant with the language and the script will still be able to think of other possible readings (e.g. what looks like a *repha* may be damage, in which case nothing is to be read in its place; or it may be a damaged marker for *ā* or *e*, in which case the *r* is to be dropped and the vowel is to be read after the other consonant(s) of the *akṣara*)

- if you have a small number of reasonable guesses, then mark up the entire sequence involved as ambiguous, e.g.

- *ddh* with what may be either a *repha* or an *ā* marker attached to its top:

<choice><unclear>rddha</unclear><unclear>ddhā</unclear></choice>

- when the uncertainty concerns a sequence of **strokes**, some of **which may belong to** either **one character or to another**, you will necessarily have to tag entire sequences as unclear (leaving it to readers to think up alternatives) or ambiguous, e.g.

- if in the Tamil sequence ஓப the right-hand set of strokes may be an *ā* marker attached to the preceding *k* or a separate character such as ங *ra*:

- *k<unclear>ā</unclear>*

- OR *k<choice><unclear>ā</unclear><unclear>ara</unclear></choice>*^26*

- if in the premodern forms of Nagari that use so-called *prṛṣṭhamātrā* notation, the sequence **पात** the central stroke may be an *ā* marker attached to the first character, or an *e* marker attached to the second:

- *p<unclear>ā</unclear>*

- or *p<choice><unclear>āta</unclear><unclear>ate</unclear></choice>*

<footnote>^26 In the interest of preserving your sanity, it is advised that you avoid encoding the full spectrum of possibilities, *k<choice><unclear>ā</unclear><unclear>ara</unclear><unclear>ar</unclear><unclear>ra</unclear><choice>* unless all are indeed plausible and worth recording.</footnote>
## 5.4. Lacunae

### 5.4.1. The EpiDoc element `<gap/>`

- this section concerns lacunae, i.e. situations where the originally inscribed text cannot be read at all because it is severely damaged, or because part of the support is altogether gone

- the TEI element `<gap/>` has a wide range of application, indicating "a point where material has been omitted in a transcription [for various reasons including that] the material is illegible, invisible, or inaudible"<fnref n="27" />

- in our EpiDoc editions, this element must always have the following attributes

- `@reason`

- either `@extent` or `@quantity`

- `@unit`<fnref n="28" />

- see the following subsections for detailed instructions on these attributes

- since a gap is, by definition, a point where text is not available, this element can **never contain text** (i.e. it is an empty element)

- note that **if you supply the contents of a lacuna** (e.g. by conjecture or from a parallel text), then the lacuna itself must not be marked up as a gap; instead, see §5.5 about supplied text

- however, if only part of the missing text is supplied, the remaining segment(s) of the lacuna are to be marked up as discussed here and separately from the supplied segment(s)

### 5.4.2. The reason for a lacuna: illegible or lost

- where parts of the support have been lost altogether, or where the support itself is extant, but its surface has peeled off so that not even the faintest traces of writing remain, the attribute `@reason` shall have `"lost"` as its value:

- `<gap reason="lost"/>`

- where the inscribed text cannot be read at all, but the support is extant and vestiges of writing remain (i.e. there is a chance, however narrow, that with new insights, technological advances or sheer luck, some of the text can be recovered), the attribute `@reason` shall have `"illegible"` as its value:

- `<gap reason="illegible"/>`

- where it is impossible to make the above distinction for a certain lacuna, you may use the attribute `@reason` with the value `"undefined"`:<fnref n="29" />

- `<gap reason="undefined"/>`

- resort to this if and only if

- you are encoding your text from a printed edition without access to the original inscription or a visual representation of it

- and the previous editor gives no indication whether a lacuna is illegible or wholly lost

- and you cannot make a reasonable guess as to which of these it is

### 5.4.3. Inline lacunae

- in most situations, lacunae shall be treated as inline, i.e. line beginnings are to be marked up as usual (§3.2) and lacunae starting in one line and continuing in the next are to be marked up as two separate `<gap/>` elements

- this applies even to lines that are wholly illegible, provided that you are certain about the presence and number of such lines

- for exceptions, see §5.4.6 to §5.4.8 below

<footnote n="27">²⁷ https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-gap.html. This definition uses the term "transcription" in a generic sense of the transposition of text from one medium to another, not in the specific sense in which it is distinct from transliteration (see TG §1.4.3).</footnote>

<footnote n="28">²⁸ The EpiDoc schema permits the use of `@extent` without `@unit`, but in our practice, `@unit` shall always be specified.</footnote>

<footnote n="29">²⁹ This was not permitted in earlier versions of the EpiDoc schema, but has been added at our request in January 2020 and will be available in the next release of the schema.</footnote>
- if you **know the number of characters lost** accurately, encode the length of the lacuna in the same way as that of spaces (§4.3.1), using `"character"` as `@unit` and a numeric value as `@quantity`

- e.g. `<gap reason="lost" quantity="1" unit="character" />`

- unlike spaces, where length expressed in characters is understood by default to be approximate, the length of lacunae expressed in the above way should be quite precise, as in the following circumstances:

- the text is in syllabic verse which lets you determine the exact number of *akṣaras* lost (give or take a few potential final consonants and/or punctuation marks)

- although the characters are damaged beyond recognition, they can nonetheless be counted with a very small margin for error

- if you **estimate the number of characters lost** but do not know them precisely, expand the above markup with the attribute `@precision` with the value `"low"`

- e.g. `<gap reason="illegible" quantity="7" unit="character" precision="low" />`

- although TEI affords the facility to do so, we shall not encode any other degrees of precision, nor use minimum and maximum possible values for the length of a lacuna

- use this method when your estimate can be expected to differ by no more than 20% or so from the actual number of characters lost, as in the following circumstances:

- you can count the number of characters in the previous or next line for a span of the same width as that of the lacuna

- the text is in quantitative verse, and you estimate the number of syllables lost on the basis of the number of morae missing from the verse<fnref n="30" />

- if the **size of a lacuna cannot be counted or estimated in characters**, use the attribute `@extent` with the value `"unknown"` to encode this, e.g.

- `<gap reason="lost" extent="unknown" unit="character" />`

- note that there is no separate encoding method for lacunae from the beginning of a line to a certain point, or from a certain point to the end of a line

- these cases shall simply be encoded by whichever of the above three options is applicable

### 5.4.4. Lacunae with known metre

- if text cannot be restored, but the prosodic pattern of a lacuna is known, encode an inline lacuna as above, and in addition

- wrap the `<gap/>` element in a `<seg>` element with the attribute `@met`, encoding its prosody as per Table 2 of Appendix B

- thus, in fully syllabo-quantitative verse (e.g. *vasantatilakā*), encode a lacuna as `<seg met="++---+--"><gap reason="lost" quantity="9" unit="character" /></seg> suvarṇṇa-dāne

- note that the number of lost characters in syllabic verse can always be calculated accurately, but in moraic verse the size of the lacuna expressed in characters may be only an estimate, requiring the use of `@precision="low"` in the `<gap/>` element

- thus, in moraic verse (e.g. *āryā*), encode a lacuna as `yo vīkṣya <seg met="3|4|4|4|-"><gap reason="lost" quantity="12" unit="character" precision="low" /></seg> bandhana-niruddhaM`

- when encoding the metre of lost text, disregard:

- caesurae (which may or may not have been observed by the composer)

- complex nuanced constraints, as in the first half of an *anuṣṭubh* line

- instead, any syllable that is not fully determined by the template should be denoted as anceps, e.g. `<seg met="====-+"><gap reason="lost" quantity="6" unit="character" /></seg>vyāpi candraguptākhyam adbhutaM`

<footnote n="30">³⁰ In Sanskrit quantitative verse, the number of lost syllables may be estimated at 75% of the number of missing morae. Thus, if a 12-mora chunk is missing from a verse line, estimate the length of the lacuna at 9 characters if you have no better indication. This figure is based on a quick statistical look at a small sample; feel free to use a better approximation if you can, and do not worry too much about the accuracy of the character count.</footnote>
- legitimate metrical variations, as in *vipulā anuṣṭubh* (instead, treat all lost *anuṣṭubh* verse as *pathyā*)

- and optional constraints such as *vipulā* and *capalā āryā* (instead, treat all lost *gāthā*-type verse as *pathyā*)

### 5.4.5. Lacunae below the akṣara level

- when a particular character component (such as the consonant body, a subscript consonant or the vowel marker) is lost or illegible and cannot be restored even tentatively, but you do have text (of any sort, including unclear and supplied) for other parts of the same *akṣara*, encode special inline lacunae as follows

- 1. at its logical position in the transliterated text, encode the lacuna with the element `<gap>`, using `"component"` as the value of its `@unit`

- mark up the gap as illegible or lost as you would normally

- if more than one component of a character is affected, encode a separate `<gap/>` for each

- 2. wrap the `<gap/>` element (or each `<gap/>` element separately) in `<seg type="component">` with an applicable value of `@subtype` as per §4.1.2

- if the lost component is a vowel whose prosodic length is known (because it is in verse, or deduced from the extant phonemic context) then add the attribute `@met` (as per §5.4.4) to the `<seg type="component">` wrapper (instead of adding an extra `<seg>` element to be qualified by `@met`)<fnref n="31" />

- 3. if you deem that there is potential ambiguity regarding *akṣara* boundaries, feel free to wrap transliterated characters and lacunae belonging to a single original character in the element `<seg type="aksara">` as per §4.1.1

<caption>**Example 5.4.5.A: lost consonants**</caption>

a vowel marker for ā and an *anusvāra* are visible in the last partial line of a fragment

```html
<seg type="aksara"><seg type="component"
    subtype="body"><gap reason="illegible" quantity="1"
    unit="component"/></seg>ā</seg>
<seg type="aksara"><seg type="component"
    subtype="body"><gap reason="illegible" quantity="1"
    unit="component"/></seg><unclear
cert="low">a</unclear>m</seg>
```

<figure><img src="image_31.png" /><figcaption>**Example 5.4.5.B: lost vowel marker**</figcaption></figure>

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

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

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

the consonant *t* has so much damage around it that it may have had any of several vowel marks or none, as in the hypothetical image here

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

some candidates are shown on the right

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

this is a scenario which some of us are used to transliterating as *tV*

```html
t<seg type="component" subtype="vowel"><gap reason="illegible" quantity="1"
    unit="component"/></seg>
```

<footnote n="31">³¹ Keep in mind that the markup should reflect the positional value of the vowel and not its length by nature: if a vowel is followed by more than one consonant, then it is positionally long even if it is a short vowel by nature.</footnote>
<figure><img src="image_37.png" /><figcaption>Example 5.4.5.C: lost body with subscript component</figcaption></figure>

* a clear subscript y survives but the principal consonant(s) are obliterated along with any vowel marker, as in the hypothetical image above

* some candidates are shown on the right

```
<seg type="component" subtype="body"><gap reason="illegible" quantity="1"
unit="component"/></seg>y<seg type="component" subtype="vowel"><gap reason="illegible"
quantity="1" unit="component"/></seg>
```

<caption>Example 5.4.5.D: a complex sequence of partially lost characters</caption>

* a sequence comprised of the following elements, which are known to follow the prosodic pattern —-

* the legible character *ku*, which is simply transliterated

* one wholly illegible *akṣara*, which we prefer not to encode simply as a lacuna of one character which is prosodically long, as this would obscure the fact that since the preceding (clear) *ku* is prosodically long, the present lost *akṣara* must be a conjunct

* a clear regular y that may or may not have had a vowel marker attached
```
ku<seg type="aksara"><seg type="component" subtype="conjunct"><gap reason="illegible"
quantity="1" unit="component"/></seg><seg type="component" subtype="vowel" met="+"><gap
reason="illegible" quantity="1" unit="component"/></seg></seg>y<seg type="component"
subtype="vowel" met="+"><gap reason="illegible" quantity="1" unit="component"/></seg>
```

* in the above example, the tag `<seg type="aksara">` around the second (wholly lost) character is not strictly necessary, but it has been added to make it explicit that the illegible conjunct consonant and the illegible vowel comprise one *akṣara*

### 5.4.6. Entire lines lost

- when a small and precisely known number of lines is lost, encode each line beginning (§3.2.1) and populate each line with separate inline `<gap/>` elements (§5.4.3) with estimated quantity or unknown extent

- e.g. for a gap of two full lines, `<lb n="3"/><gap reason="lost" quantity="30"
unit="character" precision="low"/><lb n="4"/><gap reason="lost" quantity="30"
unit="character" precision="low"/>>`

- the size of larger lacunae may be encoded using `"line"` instead of `"character"` as the value of `@unit`

- see §5.4.7 below for additional considerations in such cases

- to encode a precisely known number of lost or illegible lines,

- use `"line"` as the value of `@unit`

- e.g. `<gap reason="lost" quantity="3" unit="line"/>`

- to encode an *unknown* or *uncertain* number of lost or illegible lines,

- if the number of lost lines can only be estimated, but not counted precisely

- use `@precision="low"` to show that the number of lines lost is an estimate

- e.g. `<gap reason="lost" quantity="3" unit="line" precision="low"/>`

- if the number of lost lines is *unknown*

- use `@extent` with the value `"unknown"` instead of `@quantity`, but retain `@unit` with the value `"line"` to distinguish such spaces from inline spaces of unknown length

- e.g. `<gap reason="lost" extent="unknown" unit="line"/>`

- to encode *lines possibly lost*,<fnref n="32" /> i.e. situations where it is impossible to tell whether there were more lines to an inscription than are now extant

<footnote n="32">³² Or, in principle, lines possibly illegible. But such a situation seems unlikely: if vestiges are so scant that you cannot even tell whether there ever was writing in a certain area, then that text is for all purposes better marked up as “possibly lost” instead of “possibly illegible”.</footnote>
- within the `<gap>` element, add `<certainty match=".." locus="name"/>`, where

- `@match=".."` indicates that we are encoding uncertainty regarding the parent element (i.e. `<gap>`), and

- `@locus="name"` indicates that the uncertainty concerns the name of the parent element (i.e. the fact that what we have there is a lacuna)

- note that in this single case, the `<gap>` element is not empty but comprised of separate opening and closing tags wrapping the `<certainty>` element

- for example,

- one line possibly lost: `<gap reason="lost" quantity="1" unit="line"><certainty match=".." locus="name"/></gap>`

- up to approximately two lines possibly lost: `<gap reason="lost" quantity="2" unit="line" precision="low"><certainty match=".." locus="name"/></gap>`

- any number of lines possibly lost: `<gap reason="lost" extent="unknown" unit="line"><certainty match=".." locus="name"/></gap>`

### 5.4.7. Massive lacunae

- extensive lacunae can disrupt the extrinsic and intrinsic structure of the encoded text and shall therefore be handled as follows

- see also §5.4.8 below for the special case of lost copper plates

- if you can restore part of the lost text, encode your restored text as per §5.5, but do not include any reconstructed structural elements in `<supplied>` tags

- in the instructions below, all points concerning extant text apply equally to text restored by you in the edition

- for instructions concerning the numbering of elements where massive lacunae are involved, see the specific passages on final, initial and medial lacunae below

- the **general procedure** for encoding massive lacunae is as follows

- carefully encode block-level containers (`<p>`, `<ab>`, or `<lg>` and `<l>`):

- all (extant or restored) text must be within such a container, but do not create additional containers to hold only lacuna markup (and no text)

- if the beginning or end of one of these containers falls within a lacuna, place the start-tag or the end-tag at the point where (extant or restored) text begins or ends, and add the attribute `@part` to the container,

- with the value `I` if the initial part of the container is extant (the end is lost in a massive lacuna)

- with the value `F` if the final part of the container is extant (the beginning is lost in a massive lacuna)

- with the value `M` if only the medial part of the container is extant (both the beginning and the end are lost in a massive lacuna)

- note that if an `<l>` element is interrupted by a massive lacuna, you will need to close both the current `<l>` and, after it, the `<lg>` element wrapping it, and add the attribute `@part` to both of these elements

- while if the start of the lacuna coincides with the start of a line, `@part` is not applicable to that `<l>` element, but may still be applicable to the enclosing `<lg>` element if the stanza is incompletely preserved

- carefully encode pointlike structural elements (`<lb/>`, `<pb/>` and `<milestone/>`), paying attention to the following:

- when an epigraphic line is partially present, i.e. it has at least a little bit of (extant or restored) text at the beginning or end,

- make sure the `<lb/>` for that line is present, but do not encode `<lb/>` elements for any additional lines believed or known to be lost

- encode an inline lacuna for the final or initial part of that line where no text is available
- if pages or a pagelike partitions are involved, make sure the `<pb/>` or `<milestone type="pagelike"/>` is present for any such unit that includes any (extant or restored) text, but do not encode these elements for any additional units believed or known to be lost

- see §5.4.8 for specific guidance on dealing with incomplete copper plate sets

- encode the rest of the lacuna outside any reconstructed elements, as a known, estimated or unknown number of lost lines or, if applicable, as possibly lost lines (see §5.4.6 for all of these methods)

- when according to the above instructions it would be **necessary to create a structural element** (a container or an empty element representing a transition point) **only for the sake of restored text**, i.e. when a restoration extends into a text container, line or page of which no part is extant,

- you may **optionally forgo the creation** of such an element and, instead of including the restoration in the text of your edition, mention the restoration in an apparatus note (§9.1.7)

- this method is recommended especially in the following cases:

- for very short restorations (smaller than one word)

- for the restoration of widely occurring text such as standardised genealogies or stock admonitory verses in land grants

- for restorations where several alternatives are deemed possible

- the points below summarise specific applications of the above general procedure for final, initial, medial and bilateral lacunae, and give guidance on the numbering of elements when massive lacunae are involved

- to encode **a text whose end is lost** (a massive final lacuna):

- close the currently open block-level container (`<p>`, `<ab>`, or `<lg>` and `<l>`) directly after the last (extant or restored) bit of text

- add the attribute `@part` with the value `"I"` (for initial) to the interrupted container unless it is filled up to its end by extant or restored text

- encode an `<lb/>` for the last line that has any (extant or restored) text and an inline lacuna for the end of that line if incomplete

- outside the last block-level container, encode a multiline lacuna for subsequent lost text

- number your lines and stanzas consecutively up to the last extant or restored item

**Example 5.4.7.A: massive final lacuna**

```xml
<p part="I">...</p>
<lb n="5"/>tāpasāśrama-va<unclear cert="low">ne</unclear>
</p>
<gap reason="lost" extent="unknown" unit="character"> <!-- Lacuna to the end of the Last Line -->
<gap reason="lost" extent="unknown" unit="line"> <!-- Lacuna after the Last Line -->
```

- to encode **a text whose beginning is lost** (a massive initial lacuna),

- open the first block-level container (`<p>`, `<ab>`, or `<lg>` and `<l>`) directly before the first (extant or restored) bit of text

- add the attribute `@part` with the value `"F"` (for final) to the interrupted container unless the lacuna happens to end at the precise point where the container begins

- encode an `<lb/>` for the first line that has any (extant or restored) text

- if the beginning of this line is also lost, encode an inline lacuna after the `<lb/>` element

- if the beginning of this line is extant, but the first word is incomplete (i.e. if the beginning of that word was in the lost previous line), add `@break="no"` to the `<lb/>` element (§3.2.4)

- outside the first block-level container, encode a multiline lacuna for preceding lost text

- number your lines and stanzas consecutively

- generally, start with 1 at the first encoded element of each type

- but if the number of lost lines is precisely known, then assign numbers to each of those (in the `<lb/>` element for each, if you encoded them individually; or mentally, if you encoded a single lacuna of multiple lines) and start numbering the extant lines in logical succession
<caption>Example 5.4.7.B: massive initial lacuna</caption>

```html
<gap reason="lost" extent="unknown" unit="line"/><!-- Lacuna before the first line -->
<lb n="1"/><gap reason="illegible" precision="low" quantity="7" unit="character"/><!-- Lacuna from
the beginning of the first line -->
<p part="F">bhagavat-paśupati-bhaṭṭāraka-pādānugṛhīto bappa-pādānu<lb n="12" break="no"/>dhyātaḥ
parama-bhaṭṭāraka-mahārājādhirāja-śrī-narendradevaḥ kuśali ...
</p>
```

- to encode a text with a chunk lost from the middle (a massive medial lacuna),

- encode the initial chunk of extant text as one with a final lacuna, but do not encode lost lines at the end

- encode the final chunk of extant text as one with an initial lacuna, but do not encode lost lines at the beginning

- if the total number of lost medial lines cannot be estimated confidently, encode the extant sections as textpart divisions (§3.4)<fnref n="33" />

- here, you are essentially treating your inscription as consisting of unconnected fragments, even if the massive lacuna is merely due to surface damage

- putting the final extant chunk in a new textpart division allows (and compels) you to restart line and stanza numbering from 1

- since textpart divisions encoded as fragments necessarily imply the presence of lacunae between the textparts, lines lost between the fragments shall not be encoded explicitly

- however, do encode an inline lacuna for the remainder (end or beginning) of any line that contains (extant or restored) text

- if the total number of lost lines is known or can be confidently inferred, there is no need to split your edition into two textparts; instead,

- between the last block-level container of the first extant chunk and the first block-level container of the second, encode a multiline lacuna

- preferably by creating `<lb/>` elements for each lost line and populating these with inline `<gap/>` elements with an estimated number of characters

- in this case, number the reconstructed `<lb/>` elements as you would normally, and continue numbering in the second extant chunk

- or, if the number of lost lines is large (yet still known precisely), by encoding a single `<gap/>` element of multiple lines

- in this case, mentally assign a line number to each lost line, and in the second chunk of text, continue the numbering of your encoded `<lb/>` elements in logical succession

- if your inscription includes stanzas, ignore potential fully lost stanzas in the lacuna and continue numbering in the second extant chunk where you left off in the first

- or, if you can infer the number of lost stanzas confidently (e.g. because stanzas are numbered in the original), mentally assign numbers to the lost stanzas and continue the numbering of encoded stanzas in logical succession

- or, if you can infer both the number of lost stanzas and their position relative to line beginnings (e.g. because the inscription has exactly one stanza per line throughout), reconstruct the `<lg>` and `<l>` elements for each stanza and populate these with separate inline `<gap/>` elements instead of encoding a single inline `<gap/>` for each epigraphic line

- to encode a text with chunks lost from both the beginning and the end (a massive bilateral lacuna),

- apply the considerations for an initial lacuna at the beginning of your extant chunk and those for a final lacuna at the end of your chunk

- should it be the case that the surviving text is a single block-level element (`<p>`, `<ab>`, or `<lg>` and `<l>`) that is incomplete on both ends, add the attribute `@part` with the value `"M"` (for medial) to the interrupted container

<footnote n="33">³³ See Example 3.4.5.A for an illustration of such encoding.</footnote>
### 5.4.8. Lost copper plates

- incomplete sets of plates shall be handled like any other massive lacuna (§5.4.7), with the following additional considerations

- although it would be theoretically permissible to use "page", "plate" or "folio" as the value of `@unit` in a `<gap/>` element, we see no practical advantage to doing so

- lost pages do not as a rule need to be reconstructed in your edition, except for the special considerations for lost initial and medial plates, set out below

- instead of encoding lacunae for lost pages, the fact that entire plates are lost shall be recorded in the commentary

- if a restoration extends into a lost plate, it is preferable to record that restoration in an apparatus note (§9.1.7) rather than in the edition

- however, if you deem it essential to restore text for a lost plate within your edition,

- then create all necessary `<lb/>` and `<pb/>` elements to accommodate the restored text

- if only one face (recto or verso) of a lost plate is involved in restoration, then it is sufficient to reconstruct a `<pb/>` element only for that face

- whenever you reconstruct a `<pb/>` for the sake of a line with restored text, the remaining (unrestored) lines on that page must be encoded as a multiline lacuna of a known, estimated or unknown number of lines

- depending on your corpus, it may be possible to **confidently estimate the number of lost pages, and** even that of **lines** on each lost page

- if this is the case, feel free to reconstruct `<pb/>` elements for each face of each lost plate

- in this case, populate each reconstructed page with a multiline lacuna of a known, estimated or unknown number of lines

- in a text with **lost final plate(s)**, simply end your edition at the end of the (extant or restored) text, closing the currently open block-level container and adding `@part="I"` to it if it is incomplete

- in a text with **lost initial plate(s)**,

- number pages as follows:

- if the number of lost plates is certain, then number each encoded page logically

- i.e. if you reconstructed `<pb/>` elements for all lost pages, number them starting with 1r; otherwise, mentally start numbering with the first lost page, and in your edition, start your encoded numbering with the page number applicable to the first actually encoded (extant or reconstructed) page

- if the number of lost plates is uncertain, start your numbering with the first actually encoded (extant or reconstructed) page as follows:

- if there is no restored text before the extant text, start page numbering with 1r for the first extant page

- if a restoration precedes the extant text, then start page numbering with 1v for the reconstructed page, and 2r on the first extant page

- if the first line on the first extant page begins inside a word, then remember to add `@break="no"` to both the `<lb/>` and the `<pb/>` element encoding the beginning of that line and page (§3.2.4)

- number lines as follows:

- if the total number of lost lines is certain (because the number of lines per lost page and the number of lost pages are both known), then depending on the general preference for your corpus (§3.2.2), you may

- either number lines consecutively in a logical scheme, i.e. mentally start numbering with the first lost line, and in your edition, start your encoded numbering with the line number applicable to the first actually encoded (extant or reconstructed) line

- this is applicable regardless of whether you reconstruct page beginnings for the lost pages or not

- if you do reconstruct lost pages, keep in mind that the line beginnings on those pages need not be reconstructed individually, but may be encoded as a lacuna of a known number of lines

- or restart line numbering on each page, and use complex line numbers
- if the total number of lost lines is not known for certain (because there is uncertainty as to the number of lost pages, or to the number of lines per lost page), then depending on the general preference for your corpus (§3.2.2), you may

- either number lines consecutively, but starting from the first actually encoded (extant or reconstructed) line (and ignoring the lost lines)

- or restart line numbering on each page, and use complex line numbers

- in a text with **lost medial plate(s)**,

- if the number of lost pages is known or can be confidently inferred,

- end any open block-level containers before the lacuna (using `@part="I"` if applicable)

- open new block-level containers after the lacuna (using `@part="F"` if applicable)

- for the sake of consistency, open the new container before the first extant `<pb/>` element in the final part of the text

- outside the above block-level containers, reconstruct `<pb/>` elements for each lost page (i.e. two per plate) regardless of whether they hold restored text or not

- populate each of these with a multiline lacuna of a known number of lines

- number all actually encoded `<lb/>` elements

- if the number of lost lines per page is certain, you may number lines consecutively throughout your edition (in this case, mentally assign line numbers to the lost lines encoded as multiline lacunae, and after the lacuna, continue numbering the actually encoded `<lb/>` elements with the next number)

- depending on corpus preferences, the option of restarting line numbering on each page (and using complex line numbers) is of course available even if the number of lost lines is certain

- if the number of lost lines per page is uncertain or unknown, you must restart line numbering on each page (and use complex line numbers) even if the general preferences for your corpus dictate otherwise

- note that if the last line of a lost medial page contains restored text and is preceded by an unknown or approximate number of lost lines, the number of that reconstructed line should be 1 in this numbering scheme (because it is the first actually encoded `<lb/>` element on that page)

- see Case study 2B in Appendix C for an illustration of the encoding of a reconstructed medial plate

- if the total number of lost medial pages cannot be estimated confidently, encode the extant sections as textpart divisions (§3.4, §5.4.7) to eliminate difficulties with page and line numbering

- within each textpart, encode the relevant pages exactly as prescribed above for lost final and initial plates respectively

- do not reconstruct any page or line beginnings believed or known to be lost, except when you find it essential to include a restoration in your edition that requires these

- in the second textpart, restart page and line numbering

- see Case study 2C in Appendix C for an illustration of the encoding of a missing medial plate with textpart divisions

### 5.4.9. Fractured inscriptions

- when an initial, medial or final fragment of an inscription is lost, the general guidelines for massive lacunae apply (§5.4.7)

- inscriptions consisting of only one extant fragment need no markup for partitions

- inscriptions with two or more extant fragments need to be encoded differently depending on whether the fragments can be connected (with the help of the extant text, through a restoration of at least some of the lost text, or through a reconstruction of the extrinsic structure)

- if **fragments are connected by** one or more lines of extant or restored **text** running across them, then they can be edited without resorting to textpart divisions

- it is recommended that you encode the boundaries of such fragments using gridlike partitions (§3.6 and Example 3.6.6.C)

- when encoding gridlike partitions, lacunae resulting from weathering at the fractured edges or from the loss of one or more fragments may be joined to either adjacent segment
- but when lacunae are partially restored in such a case, it is preferable to join each restoration to the fragment whose surviving text serves as the basis of the restoration

- the same method is applicable if no extant or restored text connects the fragments, but the number of lines lost between them can be confidently estimated (for instance on the basis of metre and content)

- if **no** extant or restored **text connects** some **fragments**, but it is possible to deduce their reading order and to confidently estimate the number of lines lost between them, then the above method is applicable with the following additional considerations

- if the number of lost lines is more than zero, the lacuna must be encoded as a gap extending over a known number of lines

- even in this case, the fragments shall be encoded as gridlike partitions (if at all), not as pagelike partitions

- if the number of lost lines is zero (one or more lines of one fragment are assumed to belong to the same original line as one or more lines on another fragment even though no extant or restored text fills up the gap), then the overlapping lines of the fragments shall be encoded as parts of the same encoded line

- if **nothing** extant or restored **connects** some **fragments**, and thus the number of lines lost between them is uncertain and even their reading order may be doubtful, then they must be encoded as boxlike partitions (§3.4 and Example 3.4.5.A)

- the corresponding textpart divisions shall follow one another in the (presumable) order in which they appeared in the original

- lacunae shall not be encoded for any text between the surviving fragments

- restorations shall be encoded attached to the fragment which serves as the basis of restoration

- the same method is applicable if parts of the same original line may be preserved on several fragments, but the original structure cannot be reconstructed as a gridlike partition

## 5.5. Restoring Lacunae

### 5.5.1. Marking up restored text

- where you as editor restore parts of the text that can no longer be made out in the original, the restored segments must be wrapped in the element `<supplied>`, normally using `"lost"` as the value of `@reason`

- e.g. `<supplied reason="lost">sodra</supplied>ŋgah soparikaro`

- instead of `"lost"`, you may use the value `"undefined"` for `@reason` if and only if

- you are encoding your text from a printed edition without access to the original inscription or a visual representation of it

- *and* the previous editor gives no indication whether the supplied text was omitted (for which see §6.2.4) or lost

- *and* you cannot make a reasonable guess as to which of these it is

- bear in mind that, as discussed in §5.1, restoration with `<supplied>` is for cases where the basis of restoration is solely the (immediate or wider) context

- conversely, if vestiges of text can be made out to a degree sufficient to corroborate a restoration, then (regardless of how scant these vestiges are) the text should be treated as an unclear reading rather than a restoration (see also §5.1)

- e.g. `<supplied reason="lost">pitṛ</supplied><unclear>bhiḥ</unclear> saha pacyate` (where vestiges give some confirmation for `bhiḥ`, whereas `pitṛ` is wholly gone)

- the element `<gap/>` must not be used for a restored lacuna:

- from a text-encoding point of view, `<supplied>` marks a stretch of text as a restoration, while `<gap/>` stands for an absence of text in the edition, and not for a lacuna on the support

- in partially restored lacunae, `<supplied>` and `<gap/>` must, of course, be used side by side

- restored text must, like extant text, be marked up for extrinsic and intrinsic structure
- however, structural markup (including both containers and empty elements) must never be inside the `<supplied>` tag

- therefore, some longer restorations will need to be split up into several `<supplied>` elements

- in addition to the mandatory attribute @reason, the optional attribute @cert with the value `"low"` may be added to indicate a **tentative restoration**, where different restorations (of a similar or a different ultimate meaning) may be feasible

- e.g. nirodha-parimokṣa-śīghram iva pāṇḍu gāṅgāṁ <supplied reason="lost" cert="low">payaḥ</supplied>

### 5.5.2. The basis of restoration

- by default, restoration will be assumed to be conjectural

- conjectural restoration thus needs no explicit encoding beyond that outlined above

- the attribute @evidence may be added to `<supplied>` to indicate a restoration based on something other than conjecture, with the following permitted values:

- `"parallel"` - restoration on the basis of one or more parallel texts

- in standard EpiDoc usage, this means a parallel specimen of a text as a whole, but in our usage, it can be expanded to epigraphic parallels of certain segments of a text, such as:

- a genealogy found in (nearly) identical form in many copper plates or seals of a dynasty

- a repeatedly used standard title of a ruler

- a stanza found in more than one instance in your corpus

- if your edition includes a restoration of this type, the parallel text(s) used as evidence should be identified in the commentary to your edition

- such identification shall be in a human-readable form, but if the parallel text already has an ID in the DHARMABase, then this ID should be mentioned (and may be encoded as a reference, see §10.4.6)

- `"previouseditor"` - text that has been read by a previous editor of the inscription, but which is no longer possible to make out at present

- note that there is no facility to distinguish between multiple previous editors within this tag; if such a distinction is necessary, it shall be made in the apparatus attached to your edition (§9.1)

- likewise, alternative conjectural restorations should be recorded in the apparatus (if at all); `@evidence="previouseditor"` is only for cases where an earlier editor reports an actual reading for text now lost
# 6. Editorial Intervention

## 6.1. Correction and Normalisation

### 6.1.1. Correction versus normalisation

- the editorial rectification of a phenomenon deemed to be a scribal mistake is here referred to as **correction**

- a correction is thus a restoration of the text to the form that you believe the composer of the text had intended

- as a corollary, just because the text is not up to textbook standards does not mean that it requires correction, and the text as corrected by us need not necessarily be up to textbook standards

- the editorial alteration of a phenomenon deemed to be non-standard usage into something that fits the standard more closely is here referred to as **normalisation**

- if what you believe to have been the composer's intent differs from the standard for the language in question (inasmuch as a standard may be said to exist), you may normalise the original usage for purposes such as:

- to help readers understand the text and to show how you interpret it

- to facilitate text queries by ensuring that the standard form is present in the XML file and can thus be returned as a match for searches even if the actual text differs from the standard

- **distinguishing scribal error from non-standard usage** may be problematic and will often involve a subjective decision

- deviations that involve the exchange of a character to a graphically similar one are likely to be scribal errors

- deviations from expected forms are more likely to be non-standard usage if they occur repeatedly in an inscription

- deviations that seem to be governed by the immediate phonemic context are more likely to be non-standard usage

- deviations that involve the exchange of a character to a phonetically similar one are likely to be non-standard usage

- grammatical solecisms are to be considered non-standard usage, not scribal error

- when in doubt, prefer normalisation and use correction only in clear cases of scribal error

### 6.1.2. Markup methods for correction and normalisation

- TEI and EpiDoc afford the following methods for the editorial treatment of incorrect or non-standard text

- **no action**: depending on the nature of your text and corpus, you may opt not to mark up at all certain trivial scribal errors and common non-standard usage

- **flagging** without further action serves to highlight an erroneous or non-standard spot

- the purpose of flagging is twofold:

- it calls the attention of the reader to unexpected text, and

- it makes it clear to the reader that the unexpected text is not your editorial mistake

- see §6.2.1 about flagging erroneous or unintelligible text, and §6.3.1 about flagging non-standard usage

- **rectification by substitution**: when an error can be corrected or a non-standard form can be normalised by substituting some received characters with others, your encoded edition must include both the received and the rectified reading

- both of these alternatives must be tagged as such, and wrapped together in an element signifying that one is an alternative to the other

- see §6.2.2 about correcting errors in this way, and §6.3.2 about normalising usage in this way

- each of the above methods is available for both correction and normalisation, using the tags described in the subsections referred to above
- in addition, TEI and EpiDoc allow two more methods dedicated to the suppression of superfluous characters and the restitution of omitted characters

- **correction by suppression:** erroneously engraved superfluous characters may be marked up for editorial suppression

- see §6.2.3 about suppressing scribal errors of redundancy

- **correction by restitution:** erroneously omitted characters may be supplied and marked up as an editorial restitution

- see §6.2.4 about supplying erroneously omitted characters

- our project has chosen to dedicate these encoding methods solely to the rectification of anomalies deemed to be erroneous (i.e. not in accordance with the composer's intent) as opposed to non-standard (i.e. deliberately used by the composer)

- therefore, when you wish **to normalise orthography by adding or suppressing individual characters**, you must resort to substitution as described above

- see §6.3.4 for advice on how best to do this in various situations

### 6.1.3. Good practice in editorial intervention

- keep in mind that everything in §5.5 concerns alterations made by a modern editor; premodern editorial alterations to the actual inscribed text are covered in §4.5

- the foremost rule for editorial alterations of the received text is that they must **never be silent**

- your digital edition must always include the text as found on its support, and any changes you make to create an abstract text must be shown in markup, as detailed below

- apparent exceptions to this rule (such as editorial hyphenation, *avagrahas*, etc.) are only apparent, as our system will know that they are editorial and will be able to strip them away to obtain a purely diplomatic edition

- **editorial rectification** of the text is **optional**; in many cases less is better

- in particular, do not supply stanza punctuation or numbering where such are not present in the original (but do restore them as per §5.5 whenever you are certain that such things *were* present and have been lost to damage)

- when you rectify a feature by substitution, keep in mind that it must always be possible to produce the received text by ignoring the segment tagged as editorial and, vice versa, to produce the corrected text by ignoring the segment tagged as received

- see §6.2.2 erroneous text and §6.3.2 for the specific markup involved and for examples

- editorial intervention should make it easy for a scholarly reader to see why the editor has flagged or altered the text, and this purpose can be facilitated by avoiding complex markup where possible

- in general: try to find a common-sense optimum between minimising the scope of markup and minimising the complexity of markup

- the **size of segments** to which you apply any of the tags discussed throughout §5.5 **is technically irrelevant** and there are no hard and fast rules to decide it

- so long as the received text is faithfully reproduced (and, as mentioned in the previous point, if an editorial rectification is present, then that too is accurate), the tagging of a short segment and the tagging of a longer segment that includes characters not directly involved in the anomaly are functionally equivalent

- the outcome of this is that you need not worry too much about the size of a text segment you flag or rectify: simply proceed as feels most appropriate in the given circumstances

- see §6.2.6 and §6.3.4 for further guidance specific to correction and normalisation

### 6.1.4. Correction and normalisation in verse

- the guidelines in this subsection apply when the prosody of a metrical segment is disrupted by the presence of a scribal error or non-standard usage, or by the correction/normalisation thereof

- the leading principles are the following:
- if a correction or normalisation is encoded in the text, then it shall be the prosody of the text **after** correction/normalisation that determines whether or not it is necessary to encode a metrical deviation (with the attribute @real, as per §2.3.5)

- correct prosody should be prioritised over linguistic neatness, so

- you should always intervene where an intervention can restore faulty prosody to the expected

- but preferably abstain from encoding either a correction or a normalisation (and instead, merely flag the spot) if doing so would disrupt otherwise correct metre

- thus, in specific cases, proceed as follows

1. if the **prosody is anomalous**, and the **correction** of an error or the **normalisation** of non-standard orthography or morphology **can restore it** to the expected pattern, then

- mandatorily carry out this intervention, even if you would ignore or merely flag the same non-standard feature in other circumstances

- moreover, mandatorily encode this as a correction, even if in other circumstances you would encode the same intervention as normalisation

- do not add @real to the `<1>` element affected (see also §2.3.5)

- the underlying assumption in this case is that the composer had the correct or standard form in mind, but that has been replaced by an incorrect or non-standard form in the process of the creation of the inscription

- e.g. in an odd pāda of an anușțubh stanza, `<1 n="c">șașți <choice><sic>varușa</sic><corr>varșa</corr></choice>-sahasrāṇi</1>`, where varușa is a vernacularised spelling of varșa that is hypermetrical here, so its alteration to varșa is encoded as a correction, and since the intervention restores the expected metre, @real is not encoded on the line

2. if the **prosody is anomalous**, and there is **no straightforward way to restore it** to the expected pattern **by correction or normalisation**, then

- it is generally preferable in such cases to merely flag the spot and to add @real to the `<1>` element affected (§2.3.5), optionally mentioning the possible correction/normalisation in an apparatus note (§9.1.7)

- however, if you judge it essential, you may choose to encode a correction or normalisation in the text itself

- if you do apply correction/normalisation which still leaves the prosody deficient, then the pattern encoded in @met must correspond to the prosody of the text **after** correction/normalisation

3. if the **prosody is anomalous**, but the text is linguistically **standard, correct and meaningful**, then

- keep in mind that incorrect/non-standard metre does not in itself constitute grounds for correction or normalisation

- if you as editor perceive the metrical anomaly as an error on the part of the composer or the engraver and you can rectify it without disrupting the prosody and altering the meaning, then you are free to do so (i.e. to proceed as in case 1 above)

- if, however, you cannot restore the prosody without altering the meaning and/or you believe the prosodically anomalous text may have been what the composer actually had in mind, then flag the spot of text associated with the prosodic anomaly as non-standard, but do not encode a correction or normalisation

- in this case always add @real to the `<1>` element affected (§2.3.5)

- e.g. in an even pāda of an anușțubh stanza, `<1 n="a" real="-+---+---">sva-dattāṁ para<lb break="no" n="20"/>-dattāṁ <orig>vāpi</orig></1>`

- instead of vāpi, the standard version of this frequently used stanza has vā, which is metrically correct; but since vāpi is morphologically and orthographically correct, fully standard, and meaningful in the context, it is assumed to be deliberate and only flagged as original and not corrected to vā

4. finally, if the text as received is prosodically regular while being erroneous or non-standard in such a way that **correction or normalisation would disrupt the metre**, then

- preferably abstain from carrying out the correction or normalisation, instead simply flagging the spot as erroneous or non-standard, and mentioning the correct/standard form in an apparatus note (§9.1.7)
- e.g. in a vasantatilakā stanza, `<l n="a">sa<orig>h ssa</orig>rvva-satva-satat<orig>ārtthibhi</orig> nitya-dātā</l>` (the metre is correct, but the form °ārtthibhi is a solecism for expected °ārtthibhyo, which in turn would be metrically incorrect)

- if you deem that correction or normalisation within the text is essential, then you may encode it

- but in this case, do add @real to the `<l>` element affected (§2.3.5), with a value corresponding to the prosody of the text after correction/normalisation

- e.g. normalising the above example, `<l n="a" real="++++++++++++">sa<orig>h ssa</orig>rvva-satva-satat<choice><orig>ārtthibhi</orig><reg>ārtthibhyo</reg></choice> nitya-dātā</l>`

- it may occasionally be the case that **the text as received is linguistically standard but prosodically irregular**, and the **prosody could be corrected** by the application of a straightforward “de-normalisation”

- in such cases, leave the text without encoding, add @real to the `<l>` element affected (§2.3.5), and explain the situation in an apparatus note (§9.1.7)

- e.g. in an even pāda of an anuştubh stanza, `<l n="a" real="-+++--+-">kşitīsa-siṅhavarmaṇas</l>` (accompanied by a note explaining that the non-standard form siṅhavarmasya, known to occur in related texts, would be metrically correct)

## 6.2. Encoding Correction

### 6.2.1. Flagging erroneous and uninterpretable text

- **to flag items** without correction, wrap the relevant characters with the element `<sic>`

- by EpiDoc convention, this markup is used for text that is legible but does not seem intelligible

- uninterpretable tentative readings of mostly unclear characters do not require flagging in this way, but it is permitted to flag a segment of text that includes unclear characters

- for example,

- `mahār<sic>a</sic>ja` (ā would be correct)

- `<sic>marnta kali-kulanām</sic>` (uninterpretable)

### 6.2.2. Correcting erroneous text

- **to correct** scribal errors **by substitution**,

- flag the original text with `<sic>` as above

- add the corrected alternative directly after this, wrapped in the element `<corr>`

- and wrap both these elements in the element `<choice>`

- for example,

- `mahār<choice><sic>a</sic><corr>ā</corr></choice>ja` (a corrected to ā)

- when correcting by substitution, keep in mind that it must always be possible to produce the received text by ignoring the segment tagged with `<corr>` and, vice versa, to produce the corrected text by ignoring the segment tagged with `<sic>`

- thus, when for example encoding a correction of *pautrā* to *pautraḥ*, each of the following are **incorrect**:

- `pautr<choice><sic>ā</sic><corr>a</corr></choice>h` (this encodes a correction of *pautrāh* to *pautraḥ*)

- `pautr<choice><sic>ā</sic><corr>raḥ</corr></choice>` (this encodes a correction of *pautrā* to *pautraḥ*)

- `paut<choice><sic>rā</sic><corr>aḥ</corr></choice>` (this encodes a correction of *pautrā* to *pautaḥ*)

### 6.2.3. Editorial deletion

- where you find that one or more characters were **erroneously added** by the scribe, and you correct the text by suppressing the superfluous segment (without substituting anything else for it),

- enclose the superfluous characters in the element `<surplus>`
- before marking up an editorial deletion, be sure that you have read and understood §6.2.5 and that editorial deletion is the correct encoding in your case

- editorial deletion should always be used to highlight instances of dittography, e.g.

- *naika-samara-śata<surplus>ta</surplus>vijayinā* (*śatata* was inscribed instead of *śata*)

- *veda-vyāsena vyāsena <surplus>vyāsena</surplus>* (three iterations of *vyāsena* where two iterations are correct)

- other superfluous characters or components may, at your discretion,

- be deemed erroneous and corrected in this way,

- e.g. *datta<surplus>ḥ</surplus>s tataḥ*

- or be considered non-standard usage and treated as such

### 6.2.4. Editorial addition

- where you find that one or more characters were **erroneously omitted** by the scribe, and you correct this omission by restituting the expected segment

- wrap your editorial addition in the element `<supplied>`, using the mandatory attribute `@reason` with the value `"omitted"` to distinguish this from a restoration of a lacuna (§5.5)

- before marking up an editorial addition, be sure that you have read and understood §6.2.5 and that editorial addition is the correct encoding in your case

- for example,

- *dhanada-varuṇendrānta<supplied reason="omitted">ka</supplied>-samasya* (the *akṣara ka* was omitted by the scribe)

- *tasya <supplied reason="omitted">tasya</supplied> tadā phalaM* (*tasya* should have been written twice, but one was omitted in haplography)

- omissions of a single character may, at your discretion,

- be deemed erroneous and corrected in this way,

- e.g. *dha<supplied reason="omitted">r</supplied>mma*

- or be considered non-standard usage and treated as such

- small components (such as a superscript *r* or an *anusvāra*), which are expected to be present but cannot be made out in the original or a facsimile, might better be marked up as lost and restored (as per §5.5) unless you are certain that the cause is scribal omission, not damage to the support

### 6.2.5. Distinguishing correction from deletion and addition

- in some cases it may not be immediately obvious whether a certain editorial intervention is a case of correction (and thus requires a `<choice>` with `<sic>` and `<corr>`) or a case of suppression/restitution (and thus requires `<surplus>` or `<supplied reason="omitted">` respectively)

- the nature of intervention must always be considered on the level of phonemes, and not on that of characters or glyph components in the original script or the transliteration

- therefore, all of the following situations require correction and cannot be handled by means of suppression or restitution

- 1. quite obviously, **if the presence or absence of a stroke (glyph component) changes one character to another** (as with uppercase Latin F and E), then the suppression or restitution of that stroke is in fact a substitution of one character by another; thus:

- in a script where *ka* differs from *ra* only in the presence of a cross-stroke in the former, and the scribe erroneously engraved *lora* instead of *loka*, your rectification of that error is a correction of *r* to *k*:
    > *lo<choice><sic>r</sic><corr>k</corr></choice>a*

- and not an editorial restitution (of the cross-stroke), even though the scribe's physical error was the omission of a glyph component

- in a script where *śa* differs from *ga* only in the presence of a cross-stroke in the former, and the scribe erroneously engraved *śuṇa* instead of *guṇa*, your rectification of that error is a correction of *ś* to *g*:
    > *<choice><sic>ś</sic><corr>g</corr></choice>uṇa*

- and not an editorial suppression (of the cross-stroke), even though the scribe's physical error was the engraving of a superfluous glyph component
2. analogously to the above, but perhaps less self-evidently, a **vowel marker** added to a consonant character in most of the scripts we work with *changes* the inherent *a* of that character to a different vowel (rather than adding a vowel to a standalone consonant), and therefore the restitution of a single omitted vowel marker and the suppression of a single superfluous vowel marker are cases of editorial correction, and not of restitution/suppression; thus,

– if the scribe engraved *mahāraja* and you correct this to *mahārāja*, your rectification of that error is a correction of *a* to *ā*: **mahār<choice><sic>a</sic><corr>ā</corr></choice>ja**

– and not an editorial restitution (of the vowel marker), even though the scribe's physical error was the omission of a glyph component

– note that the encoding **mahār<supplied reason="omitted"/>ā</supplied>ja** is not incorrect, only inappropriate in this situation, as it encodes the fact that *mahārja* was engraved, which you correct to *mahārāja*

– if the scribe engraved *viditim* and you correct this to *viditam*, your rectification of that error is a correction of *i* to *a*: **vidit<choice><sic>i</sic><corr>a</corr></choice>m**

– and not an editorial suppression (of the vowel marker), even though the scribe's physical error was the engraving of a superfluous glyph component

– note that the encoding **vidit<surplus>i</surplus>m** is not incorrect, only inappropriate in this situation, as it encodes the fact your intended correction is *viditim*

3. conversely, **digraphs in our transliteration system** represent a single phoneme, so the correction of a digraph (e.g. *th*) to a single character employed in that digraph (e.g. *t*) or vice versa (e.g. correcting *t* to *th*) are cases of substitution, not suppression or restitution; thus,

– if the scribe engraved *sukhya* and you correct this to *saukhya*, your rectification of that error is a correction of *u* to *au*: **s<choice><sic>u</sic><corr>au</corr></choice>khya**

– and not an editorial restitution (of *a*), even though in transliteration you are only adding a single character

– if the scribe engraved *utphannasya* and you correct this to *utpannasya*, your rectification of that error is a correction of *ph* to *p*: **ut<choice><sic>ph</sic><corr>p</corr></choice>annasya**

– and not an editorial suppression (of *h*), even though in transliteration you are only removing a single character

### 6.2.6. Good practice in correction

– the **size of segments** flagged as scribal errors or corrected should normally be kept to a minimum (i.e. restricted to the affected transliteration characters)

– however, to **avoid non-essential complexity**, feel free to use a single set of tags on a chunk of text that contains several errors along with correct characters

– e.g. **mahārāj<choice><sic>adhijājā</sic><corr>ādhirāja</corr></choice>**

– rather than the meticulous markup:

**mahārāj<choice><sic>a</sic><corr>ā</corr></choice>dhi<choice><sic>j</sic><corr>r</corr></choice>āj<choice><sic>ā</sic><corr>a</corr></choice>**

– in the **orthography** of your editorial corrections, attempt to

– respect the orthography and, if applicable, the language usage of the rest of the document, e.g.

– correct *karppa* to *karmma* (rather than fully standard *karma*) if the inscription normally doubles nasals after *r*

– if a text consistently uses *upadhmānīya* or *jihvāmūlīya*, and your correction involves the restitution of an omitted *visarga* in a phonemic context that would call for one of these forms, then supply *upadhmānīya* or *jihvāmūlīya* instead of a regular *visarga*,

– e.g. *sarvva-rājocchettu<supplied reason="omitted"/>h</supplied>* prthivyām apratirathasya

– presuppose a plausible minimum of scribal error, e.g.

– correct *karpa* to *karma* (rather than an expected *karmma*), assuming the engraver made the simple mistake of inscribing *p* for *m* (rather than the complex mistake of inscribing *p* for *mm*)
- correct *viṅgati* to *viṁśati* (rather than fully standard *viṁśati*, since engraving *nga* in place of *ńśa* is a very plausible mistake, while engraving *nga* in place of *śa* and simultaneously omitting an *anusvāra* is not)

- but correct *viśati* to *viṁśati* (even if the text tends to use *ńś* elsewhere, since omitting an *anusvāra* is a much more plausible mistake than engraving *śa* instead of *ńśa*)

- should you feel the need, feel free to add normalisation on top of a correction (§6.3.3)

## 6.3. Encoding Normalisation

### 6.3.1. Flagging non-standard usage

- to flag non-standard text without normalisation, wrap the relevant characters with the element `<orig>`

- for example,

- dine `<orig>Āśvoja</orig>`-śuklasya (Āśvayuja or 'śvayuja is expected)

- sahasrā<orig>n</orig>i (sahasrāṇi is expected)

### 6.3.2. Normalising non-standard usage

- to normalise usage by substitution,

- flag the original text with `<orig>` as above,

- add the normalised alternative directly after this, wrapped in the element `<reg>`

- and wrap both these elements in the element `<choice>`

- for example, `e<choice><orig>ś</orig><reg>ş</reg></choice>a` (eśa normalised to eşa)

- when normalising by substitution, keep in mind that it must always be possible to produce the received text by ignoring the segment tagged with `<reg>` and, vice versa, to produce the normalised text by ignoring the segment tagged with `<orig>`

- thus, when for instance encoding a normalisation of *yathāruha* to *yathārhaṁ*, each of the following are incorrect:

- `<choice><orig>yathāruha</orig><reg>yathārha</reg></choice>ṁ` (this encodes a normalisation of *yathāruhaṁ* to *yathārhaṁ*)

- `<choice><orig>yathāruha</orig><reg>rhaṁ</reg></choice>` (this encodes a normalisation of *yathāruha* to *rhaṁ*)

- `yathār<choice><orig>uha</orig><reg>rhaṁ</reg></choice>` (this encodes a normalisation of *yathāruha* to *yathārrhaṁ*)

### 6.3.3. Nesting normalisation and correction

- should you find it necessary to do so, it is acceptable to use error markup (including flagging, deletion, correction and insertion) within the markup for non-standard usage (including flagging and normalisation)

- for example, either of the following methods may be used to mark up the fact that the word *mahārajñāḥ* is non-standard (the standard genitive being *mahārājasya*) and also contains a mistake (as the “proper” non-standard form would be *mahārājñāḥ*)

- `<orig>mahār<choice><sic>a</sic><corr>ā</corr></choice>jñāḥ</orig>`

- `<orig>mahār<sic>a</sic>jñāḥ</orig>`

- however, you should avoid nesting in all other combinations, i.e.

- do not nest a correction within another correction

- do not nest a normalisation within a correction

- do not nest a normalisation within another normalisation

- in situations where you feel that a received non-standard form is the result of two successive stages of non-standard alteration (e.g. non-standard morphology written with non-standard orthography), we recommend one of the following strategies

- encode only the received form (as `<orig>`) and the ultimate normalisation (as `<reg>`), and record your ideas about an intermediate stage in an apparatus note (§9.1.7)
– e.g. pāñcavarṣ<choice><orig>aI</orig><reg>i</reg></choice>kā, accompanied by an apparatus note explaining that the received form is probably a non-standard way of writing the form *pāñcavarṣayikā, itself of non-standard derivation

– or encode the intermediate stage as the correction of an error in the received text, and encode a normalisation with that correction nested inside it

– e.g.

pāñcavarṣ<choice><orig>a<choice><sic>I</sic><corr>yi</corr></choice></orig>
<reg>i</reg></choice>kā

### 6.3.4. Good practice in normalisation

– it is recommended that your normalisations should conform to the **orthographic style** of the rest of the document in details that you would not normalise elsewhere

– e.g. normalise varnna to varṇṇa (rather than fully standard varṇa) if the inscription normally doubles nasals after r

– the **size of segments** flagged as non-standard or normalised should generally be whatever you deem to be a reasonable minimum to which the non-standard feature can be localised

– when non-standard orthography manifests in a single character or short character sequence, it is sufficient to tag that character or sequence, but you may also include its immediate phonemic context in the following cases:

– if it is not possible to apply the desired tag to just the affected character (see the points below on the difficulties of orthographic normalisation); or

– if you feel that including additional characters in the tag is useful for highlighting the nature of the non-standard feature

– “immediate phonemic context” is not an objectively defined entity and shall be judged on a case by case basis, but will generally consist of

– adjacent characters representing phonemes that would normally determine or influence the nature of the non-standard one

– the whole string of transliterated characters corresponding to a single complex character of the original that includes the non-standard feature, when this seems to be the most straightforward and convenient way of highlighting a non-standard feature

– choosing the size of a segment to flag or normalise is thus not a wholly objective choice, and the choice has very little ultimate effect on our corpus so long as the text as received is faithfully reproduced in your encoding along with any normalisation you add

– to **avoid non-essential complexity**, feel free to use a single set of tags on a chunk of text that contains several non-standard features among standard text

– in particular, for the stock admonitory stanzas cited in land grants, whose error-rate is often much higher than in the remainder of an inscription, feel free to include the contents of an entire <l> element in a single substitution, e.g.

– <l><choice><orig>sva-datnā para-datnā vvā</orig><reg>sva-dattāṁ para-dattāṁ vā</reg></choice></l>

– as indicated in §6.1.2 above, there is no encoding method dedicated to the **suppression or restitution of individual characters in the framework of normalisation**

– in order to prevent anomalies in display, we will, moreover, avoid using normalisation by substitution in such a way that one of the children of <choice> (i.e. <orig> or <reg>) is empty; therefore,

– when non-standard orthography manifests as **the presence of an alternative character** (e.g. nikki instead of nīkki; phālguṇa instead of phālguna), then there is no difficulty in limiting your tags to the affected character

– whether you only flag it, e.g.

– n<orig>i</orig>kki;

– phālgu<orig>ṇ</orig>a;

– or normalise it, e.g.

– n<choice><orig>i</orig><reg>i</reg></choice>kki
- phālgu<choice><orig>ŋ</orig><reg>n</reg></choice>a

- when non-standard orthography manifests as the **presence of a superfluous character** (e.g. *en̥n eluttu* instead of *en eluttu*; *sam̥mvat* instead of *samvat*)

- then flagging can be limited to the superfluous character without difficulty, e.g.

- e<orig>ŋ</orig>ŋ eluttu

- sa<orig>m̥</orig>mvat

- but when normalising by substitution, you must extend the markup to the immediate phonemic context in order to avoid the creation of an empty <reg> element, e.g.

- e<choice><orig>ŋŋ</orig><reg>ŋ</reg></choice> eluttu

- sa<choice><orig>m̥m</orig><reg>m</reg></choice>vat

- when non-standard orthography manifests as the **absence of an expected character** (e.g. *satva* instead of *sattva*; *qacu* instead of *qaṇcu*; *umulata* instead of *umulat ta*), then the immediate phonemic context must always be included in the markup in order to avoid the creation of an empty <orig> element

- in flagging, e.g.

- sa<orig>tv</orig>a

- qə<orig>c</orig>u

- umula<orig>t</orig>a

- and in normalisation, e.g.

- sa<choice><orig>tv</orig><reg>ttv</reg></choice>a

- qə<choice><orig>c</orig><reg>ñc</reg></choice>u

- sakuli<choice><orig>li</orig><reg>liṁ</reg></choice> ḍayəh

- umula<choice><orig>t</orig><reg>t</reg></choice>a

- the last example also shows that a word break rendered invisible by the substandard spelling may be made visible and marked by a space in the normalized reading

### 6.3.5. How non-standard is non-standard?

- this subsection offers some general guidance on the level of editorial attention that various kinds of non-standard features merit

- whether you should ignore a specific phenomenon, flag it as non-standard, or normalise it by substitution should always be judged on an individual basis, and no objective and universal criteria can be established for such a decision

- in addition to the general guidance below, see Appendix F for some specific phenomena in specific languages

- (near-)**universal features of inscriptional orthography** prevalent throughout South and Southeast Asia, or throughout a particular region

- should generally be ignored or, if considered important in a particular instance, preferably only flagged and not normalised

- such features include for instance:

- the doubling of plosives, nasals and glides after an *r* (e.g. *dharmma* for *dharma*)

- the use of an *anusvāra* instead of the class nasal or vice versa (e.g. *maṁtra* for *mantra*; *kin tu* for *kiṁ tu*)

- less than universal, but still **common features of inscriptional orthography**

- may be ignored or flagged depending on how widespread they are in a subcorpus (or even in a single text), but should not as a rule be normalised

- such features include for instance:

- the doubling of consonants in certain conjuncts that do not begin with *r* (e.g. *puttra* for *putra*; *sattya* for *satya*)

- the exchange of a consonant for a phonetically similar one (e.g. *muṇi* for *muni*)

- infidelity to the correct length of vowels in words borrowed from Sanskrit, in languages where inconsistency in spelling of vowel-length is rampant (e.g. *bhima* for *bhīma*)

- **non-orthographic deviations from standard language**

- should normally be at least flagged and preferably also normalised

- such features include for instance:
- non-standard or substandard grammar (e.g. rājasya for rājñāḥ; kṛtedam for kṛtam idam; sā gataḥ for sā gatā)

- presumable non-standard sandhi (e.g. anugrahāya-m udaka-pūrvveṇa; paṁca-s-triṁśottaratame)

- see also TG §2.6.2 on the use of hyphens in non-standard sandhi

- presumable hyper-Sanskritisation (e.g. dattvā instead of dattā; rakṣya instead of rakṣa; prārk-kriyamāṇaka instead of prāk-kriyamāṇaka)

### 6.3.6. Supplying punctuation

- while original punctuation marks present in the text must always be transliterated and encoded as per §4.2.4, editorial punctuation marks must never be added silently to a text

- emphatically, the silent addition of punctuation marks for the segmentation of verse into stanzas and half-stanzas must be avoided, since verse is always segmented by the encoding of intrinsic structure (§2.3)

- however, in some circumstances you may feel the need to supply editorial punctuation, and this is possible and permitted so long as editorial punctuation is clearly marked up as supplied

- editorial punctuation may be particularly useful in the following circumstances:

- for semantic segmentation of long paragraphs into sentences or other semantic units, when no original punctuation is present, and you are not creating separate semantic paragraphs or anonymous blocks (§2.2) for each unit

- supplying editorial punctuation at the end of a paragraph or block is, however, pointless

- in lists (e.g. lists of donees), to mark the end of each list item

- and especially if in either of the above circumstances the original does use punctuation marks, but does so inconsistently (i.e. only after some sentences or list items), because in this case the most logical assumption is that the lack of punctuation marks after certain items is a scribal omission

- to encode supplied punctuation,

- use the transliteration character . (period, full stop) as per TG §4.2.1, but do not add a `<g>` tag around this character as you would for original punctuation (EGD §4.2.4)

- this is to express the fact that this punctuation character is an abstract one, without any assertion of its physical appearance

- and wrap the . in `<supplied reason="subaudible">`<fnref n="34" />

**Example 6.3.6.A: supplied punctuation at the end of a sentence**

```p``` ... anumantavyo varddhanīyaś ca<supplied> reason="subaudible"</supplied> yo vājñānād ...</p>

**Example 6.3.6.B: supplied punctuation in a list with sporadic original punctuation**

```p``` ... Āruvaśarmmaṇa Ekkaṁśaḥ<supplied> reason="subaudible"</supplied> puna vedaśarmaṇa Ekkaṁśaḥ<supplied> reason="subaudible"</supplied> ... jakkiśarmaṇa Ekkaṁśaḥ<supplied> reason="subaudible"</supplied> ... vebaśarmaṇa Ekkaṁśaḥ<g type="dandaPlain">.</g> ... sarvvaśarmaṇa ... </p>

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

the original punctuation mark is tagged with `<g>`

### 6.3.7. Automated normalisation

- some specific cases of normalisation will be automated in our workflow, so certain characters in your transliteration will be converted to markup

- **editorial long vowels in Dravidian languages** where the script does not distinguish short and long *e* and *o*

- as per TG §3.2, the transliterated characters ē and ō will be automatically marked up as normalised, i.e. that *e* or *o* were originally inscribed, but these represent long vowels, e.g.

- `<choice><orig>e</orig><reg>ē</reg></choice>`

- **explicit short vowels in Sanskrit loanwords** where a long vowel is expected

<footnote n="34">³⁴ The rationale behind the choice of attribute value is that punctuation is implied by the semantic context, so in a way, a punctuation mark is “subaudible” to the native or informed reader.</footnote>
- as per TG §3.3.7, the transliterated characters ă, ĩ or ũ will be automatically marked up as short in the original and normalised to their long equivalents, e.g.

- `<choice><orig>a</orig><reg>ā</reg></choice>`

- **editorial** *avagrahas*

- as per TG §2.6.3, any *avagraha* (i.e. ' [right single quote] or ' [plain apostrophe] followed by an alphabetic character) found within the `<div type="edition">` will be assumed by default to be non-original and automatically marked up as `<supplied reason="subaudible">'</supplied>`<fnref n="35" />

- original *avagrahas* transliterated as '! will not be auto-tagged in this way, but the exclamation mark will be removed automatically

<footnote n="35">³⁵ The rationale behind the choice of attribute value is that the presence of an *avagraha* is implied by the phonetic and lexical context, so in a way, an *avagraha* is “subaudible” to the native or informed reader. Alternative encoding choices would imply that the scribe made an error or used non-standard language, which is not the case.</footnote>
# 7. Encoding Additional Information in the Edition

## 7.1. Numeral Values

### 7.1.1. Generic numeral markup

- all numbers recorded in numeral signs in the original inscription must be mandatorily wrapped in the element `<num>`

- when a glyph that would normally be a numeral sign is used in a function other than to represent a number (such as the glyph normally meaning 1, occasionally used as an auspicious opening mark), then the `<num>` tag must not be added to it (§4.2.7)

- this tag does not replace the `<g>` tags discussed in §4.2.2 for numeral signs transliterated by something other than a single Unicode character, but must be used in addition to (and outside) those

- the element `<num>` must, as a rule, have the attribute `@value`, recording in a machine-readable form the final value of the entire number within the element

- **fractions** shall be represented here as decimal fractions, never dropping the 0 before fractions smaller than 1 and always using a decimal point, not a different decimal marker, e.g. `<num value="0.5">`

- round the value to three digits after the decimal point for any fractions that would require a longer sequence of digits, e.g. encode ⅜ as `<num value="0.333">`

- **some examples of numerals with full markup:**

- the number three denoted by a numeral character: `<num value="3">3</num>`

- the number three denoted by three vertical bars in a Cambodian inscription: `<num value="3"><g type="numeral">III</g></num>`

- one hundred and twenty-three, written in place value notation: `<num value="123">123</num>`

- one hundred and twenty-three, written in additive notation with a sign for 100, one for 20 and one for 3: `<num value="123"><g type="numeral">100</g> <g type="numeral">20</g> 3</num>`

- ninety written as the Khmer digit 80 and digit 10: `<num value="90"><g type="numeral">80</g> <g type="numeral">10</g></num>`

- one thousand, written with one sign meaning "1000": `<num value="1000"><g type="numeral">1000</g></num>`

- one half, written as a single character: `<num value="0.5">½</num>`

- one eighth, written as a single character: `<num value="0.125"><g type="numeral">1/8</g></num>`

- three and one third, written as a digit 3 and one character standing for "one third": `<num value="3.333">3 ⅜</num>`

- three and one eighth, written as a digit 3 and one character standing for "one eighth": `<num value="3.125">3 <g type="numeral">1/8</g></num>`

<figure><img src="image_39.png" /><figcaption>Example 7.1.1.A: complex Tamil numeral</figcaption></figure>

> the numeral 1830 is written as 1000 (plus) 8 (times) 100 (plus) 3 (times) 10

`<num value="1830"><g type="numeral">1000</g> 8 <g type="numeral">100</g> 3 <g type="numeral">10</g></num>`

### 7.1.2. Difficulties in reading numbers

- problems with reading numeral signs (e.g. lacunae, unclear and ambiguous readings) can and must be marked up in the same way as other reading difficulties (§5)

- if a numeral sign is **unclear or ambiguous**, the applicable **tags** go **outside** any `<g>` elements applied to numeral characters, but they go **inside** the `<num>` element that wraps numbers as a whole
- numbers whose reading is problematic will usually not have a definite value that you can encode in the `<num>` element; to deal with this problem, choose one of the following methods<fnref n="36" />

- 1. if you can establish a **range** that covers the **possible values** of a problematic numeral:

- instead of the attribute `@value`, use `@atLeast` and `@atMost` in the `<num>` element to record the lowest and highest possible value of the number as a whole

- e.g. for three digits in place value notation, where the first two digits are 1 and 0, and the last digit is illegible: `<num atLeast="101" atMost="109">10<gap reason="lost" quantity="1" unit="character"/></num>`

- because of its relative simplicity, this method is also recommended for situations where only some figures in a relatively limited range are possible

- e.g. for an unclear numeral sign that may be 80 or 90 with equal likelihood, you may use `<num atLeast="80" atMost="90"><choice><unclear><g type="numeral">80</g></unclear><unclear><g type="numeral">90</g></unclear></choice></num>` even though the values 81 to 89 are not possible

- 2. if you can establish a **single tentative value** for a problematic numeral:

- encode this in the attribute `@value` and add the attribute `@cert` with the value `"low"` to flag the value as tentative

- e.g. for three digits in place value notation, where the first two digits are 2 and 4, and the last digit seems to be 6: `<num value="246" cert="low">24<unclear>6</unclear></num>`

- 3. the above methods may be combined to encode a **range of tentative values**

- e.g. for three digits in place value notation, where the first two digits are probably 1 and 0, and the last digit is illegible: `<num atLeast="101" atMost="109" cert="low"><unclear>10</unclear><gap reason="lost" quantity="1" unit="character"/></num>`

- 4. if none of the above seems adequate for a partially legible numeral,<fnref n="37" /> or if a numeral is **wholly lost or illegible** (yet you are certain it was a numeral):

- use the `<num>` element without `@value` around the partial reading or the lacuna

- e.g. for one lost/illegible numeral character: `<num><gap reason="lost" quantity="1" unit="character"/></num>`

### 7.1.3. Editorial intervention and numerals

- occasionally, an editor may be able to restore a lost number, or even emend an incorrectly inscribed one, e.g. on the basis of the number being also written out in words

- tags for **editorial restoration** may be used inside or outside the `<num>` element depending on the scope of the restoration, but they must never be inside any `<g>` elements applied to numeral signs

- a longer stretch of restored text may freely include both text and a numeral

- the `@value` attribute of the `<num>` element should reflect only the restored value

- tags for **editorial correction** must be **outside** the `<num>` elements, which must separately encode both the pre- and post-correction number

- e.g. `<choice><sic><num value="6">6</num></sic><corr><num value="7">7</num></corr></choice>

### 7.1.4. Numbers expressed in words

- although the TEI element `<num>` may be used to tag anything that has a numerical meaning, our project policy shall be never to use this element for numbers written out in alphabetic characters

<footnote n="36">³⁶ Whichever method you use, possible values and their relative probabilities may be elaborated in your commentary to the edition.</footnote>

<footnote n="37">³⁷ The EpiDoc Guidelines offer a further method for dealing with partly lost numerals whose range of possible values is not sequential (http://www.stoa.org/epidoc/gl/latest/trans-numnoncongruent.html). We discourage the use of this method because we do not foresee that our project would benefit from the increased accuracy to an extent that would justify the complexity of the markup involved.</footnote>
- thus, neither numbers spelled out in words (such as *ekah* and *astottaraśataṁ*), nor chronograms (*bhūtasaṁkhyā*, *candrasengkala/sengkalan*) shall be tagged in this way

- the rationale behind this choice is that complex numbers expressed in words may be distributed over stretches that also contain non-numeral words and that the interpretation of numerals expressed as phrases, especially chronograms, is sometimes ambiguous: the complexity of the markup required to encode such cases rigorously dwarfs the anticipated advantages of having such numbers encoded

## 7.2. Tagging Language in the Edition

- this section concerns encoding language within the edition

- see §10.3 for wider applications of language encoding

- see §10.3.3 for specific instructions applicable in other parts of your XML file

- the language(s) used in an inscription must be specified in your metadata

- the attribute `@xml:lang` may be attached to elements to encode the language of their contents; see §10.3.1 for details

- normally, the edition division of your XML file must mandatorily carry this attribute, e.g. `<div type="edition" xml:lang="san-Latn">`

- wherever language change is concomitant with script change, the script should not be marked up separately (as per §7.5.4)

- instead, your metadata should specify the scripts used for each language in your inscription

### 7.2.1. Inscriptions consisting of sections in different languages

- when two (or more) **major sections** of an inscription are in two (or more) different languages, consider the degree to which these sections are independent of each other

- if the inscription may be perceived as a **single, coherent text** with one or more language shifts,

- select a primary language to encode as the `@xml:lang` of the edition division

- apply `@xml:lang` to each of the block-level elements (viz. `<p>`, `<lg>` or `<ab>`) containing text in a language other than the primary one

- if one section **cannot be perceived as an integral continuation** of the other, because they are visually clearly distinct and semantically unconnected with no straightforward order in which they should be read (e.g. they convey the same message in two languages, or cover unrelated topics)

- first, consider if it would be better to edit the inscription as two separate texts

- if that is not feasible, then

- encode the language-based sections as textpart divisions (§3.4)

- add `@xml:lang` to each corresponding `<div type="textpart">` element

- in this case only, the edition division should not carry the attribute `@xml:lang`

- note, however, that in an inscription consisting of textparts in the same language, the language must still be encoded for the edition division, not separately for the textparts

### 7.2.2. Inscriptions containing foreign words or phrases

- if an inscription includes **foreign words** which are **followed by translations** into a local language (glosses),

- use the element `<term>` to wrap each foreign word, and

- use `<gloss>` to wrap each translation into the default language of the inscription

- the attribute `@xml:lang` is not required in this scenario

- if a different language applies to **isolated words or phrases** of an inscription,

- use `<foreign>` to wrap it and apply `@xml:lang` to that element

- loanwords and foreign names should not, as a rule, be marked up as being in a different language, but do tag

- complete sentences using vocabulary and morphology/syntax foreign to the default language

- Sanskrit compounds which are not established as loanwords (i.e. do not appear in a standard dictionary of the local language such as the *Old Javanese-English Dictionary* or the *Madras Tamil Lexicon*)
- in less clear-cut cases, use your own discretion to decide whether or not to tag a segment as foreign

### 7.3. Abbreviations

- if your text includes abbreviations, it is recommended that you wrap these in the element `<abbr>` to flag them for computer processing

- for the time being, we shall not encode expansions or resolutions for any abbreviations in our texts, though TEI and EpiDoc offer methods to do so

- we may, at a later stage, automatically or semi-automatically add resolutions to the abbreviations flagged in this way

### 7.4. Optional Encoding of Semantic Features

Besides the tags prescribed in other sections of this Guide, TEI offers the possibility of using many others to encode additional semantic information in a text. Such tags, whose use is **optional and not recommended at this stage of the project**, enable the creation of indexes, for instance of all the persons or places mentioned in a (sub-)corpus with an exhaustive list of occurrences.

As adding such tags to XML editions renders the files less legible, we recommend postponing the application of such tags as long as two conditions are not fulfilled: (1) the entire (sub-)corpus has been encoded according to the guidelines exposed in other sections of this Guide and, (2) the choice of such tags has been determined after ripe reflection and in response to concrete aims of your (or the whole project's) research. Any such tagging that you do choose to apply should be implemented in accordance with the workflow of your task-force as determined by and in consultation with the PI of your task-force.

At the time this version of the Encoding Guide is released, only TF-A has started reflecting on which tags, types and subtypes could be used to answer specific research questions. The preliminary results of these reflections are given below, so that members of other task-forces can look at examples of what is possible and to stimulate a process of reflection on what tagging might be implemented in other corpora. The present section is thus provisional and mainly illustrative. It will be developed in a future version of this guide.

#### 7.4.1. Personal names

- personal names may be tagged with the element `<persName>`

- this element can be used to encode a complex name, tagging individually all elements of a personal name

- a first categorisation can be effected with attribute `@type`

- propositions for the value of `@type`:

- `"divine"`

- `"human"`

- `"personification"`

- subcategorisation is effected with `@subtype`, which may only be used if `@type` is also present

- propositions for the value of `@subtype`:

- `"coronation"` (Rājarāja, Rājendra, ...)

- `"sobriquet"` (biruda)

- `"title"` (`pōttaraiyar`, (`kōp`)parakēcarivarmaṇ / (`kō`)rājakēcarivarmaṇ)

- `"other"` (pre-coronation name, e.g. Arumoṇli, Arumoṇivarmaṇ)

- to indicate that the name in question is an alternative of some other name (perceived as a standard form), follow instructions in §10.6.3

<caption>**Example 7.4.1.A: encoding a complex personal name**</caption>

```xml
<persName type="human" subtype="sobriquet">caturummallaṇ</persName> <persName type="human" subtype="sobriquet">kuṇaparaṇ</persName> <persName type="human" subtype="coronation">mayēntira</persName>-p-<persName type="human" subtype="title">pōtt-arēcaru</persName>
```
### 7.4.2. Adding ranks and roles to names

- the element `<roleName>` can be used to encode a position in society like a rank or status (`@type`) and associate it with a role (`@subtype`) in the transaction recorded

- the element `<roleName>` is to be nested inside the element `<persName>

- propositions for the value of the attribute `@type`:

- `"king"`

- `"subordinateRuler"` (e.g. pallavaraiyaṇ)

- `"landlord"` (e.g. uṭaiyar, ki
    lavar)

- `"godLegalEntity"` (e.g. uṭaiyar)

- `"priest"`

- `"brahmin"`

- `"monk"`

- `"merchant"` (e.g. nakarattār)

- `"artisan"`

- `"brahminDelegate"` (e.g. sabhaiyār, sabhaiyōm)

- `"regionalDelegate"` (e.g. nāṭṭār, nāṭṭōm)

- `"officer"` (e.g. temple officer, royal officer)

- `"dancer"`

- `"singer"`

- `"peasant"`

- `"shepherd"` (maṇrāṭi)

- `"unknown"` (this value is to be used when you do not know the rank/status of the person but want to encode a value for `@subtype`)

- propositions for the value of the attribute `@subtype`:

- `"donor"`

- `"donee"`

- `"founder"` (of a temple or a monastery)

- `"administrator"` (overseer of donation; e.g. the one who makes sure that the in-charge of a donation supplies what he has to supply).

- `"inChargeDonation"` (e.g. the one who has to supply oil every day)

- `"witness"`

- `"orderIssuer"`

- `"orderAddressee"`

- `"auditor"` (controller of transaction)

- `"beneficiaryMerit"` (e.g. transfer of merit; donation "on behalf of", "in the name of")

- `"commemoratedPerson"` (e.g. "in the honour of (a deceased warrior)")

- `"scribe"` (exact role undetermined)

- `"composer"` (i.e. author of the text or part of the text; e.g. poet of the Sanskrit eulogy).

- `"handwriter"` (i.e. the one writing in chalk on the plate/stone for the engraver)

- `"engraver"` (i.e. the artisan who engraved the text on the support)

- `"sealer/solderer"` (i.e. the one who fabricated/sealed/soldered the seal)

**Example 7.4.2.A: encoding ranks and roles**

<persName type="human" subtype="coronation"><roleName type="king" subtype="donor">Mahendravarman</roleName></persName> gave 25 gold coins to the <persName type="divine" subtype ="standard"><roleName type="godTemple" subtype="donee">Śiva</roleName></persName> of Tillaisthānam so that <roleName type="shepherds" subtype="inChargeDonation">the shepherds</roleName> supply daily oil for a lamp for <roleName type="king" subtype="beneficiaryMerit">his father</roleName> under the supervision of <roleName type="priest" subtype="trustee">the priests</roleName> of the temple
### 7.4.3. Place names

- place names (including territorial and administrative divisions as well as built places) can be encoded using the element `<placeName>

- we recommend using the attribute `@type` using the values `"territorialDivision"` and `"builtPlace"`

- places can be described more precisely with the attribute `@subtype`, for which the following values have been proposed by the TF-A:

- `@subtype` for territorial and administrative divisions:

- `"province"` (`kōṭṭam`, `rāṣṭra`, `maṇḍala`, `vaļanāṭu`, etc.)

- `"district"` (`viṣaya`, `nāṭu`, `kūṛtam`)

- `"site"` (town, village)

- `"sitePart"` (e.g. quarter, hamlet, cēri)

- `@subtype` for built places:

- `"temple"`

- `"shrine"` (e.g. for a secondary shrine in a temple complex)

- `"monastery"` (e.g. `vihāra`, `maṭha`)

- `"feedingHall"` (`cālai`, Skt. śālā, mess for devotee pilgrims)

- `"tank"` (artificial)

- `"pavillion"` (`maṇḍapa`)

- `"garden"` (`nandavaṇam`)

- to indicate that the name in question is an alternative of some other name (perceived as a standard form), follow instructions in §10.6.3

**Example 7.4.3.A: encoding place names**

```xml
in <placeName type="territorialDivision" subtype="village">Cārukūr</placeName> in the <placeName type="territorialDivision" subtype="district">Āṭaiyārunāṭu = province</placeName> and the <placeName type="territorialDivision" subtype="province">Paṭuvūrkōṭṭam = district</placeName> in <placeName type="builtPlace" subtype="shrine">the shrine of the Goddess</placeName> in <placeName type="builtPlace" subtype="temple">the temple of Mahādeva</placeName> at <placeName type="territorialDivision" subtype="village">Tillaisthānam</placeName>
```

### 7.4.4. Measurements

- when necessary, the tag `<measure>` allows encoding references of quantity

- use the attribute `@type` to record the typology used to measure, e.g. volume, weight, currency...

- usually, measure requires encoding the quantity, the unit used, and possibly the commodity measured

- it can be done using the attributes: `@unit`, `@quantity` and `@commodity`

- `@unit` indicates the unit used for the measurement expressed by its standard symbol, e.g. cm, m, ml, km, in ...

- `@quantity` records a numeric value

- `@commodity` for the measured substance

- the numeral values for measurement should be encoded as per §7.1

**Example 7.4.4.A: encoding place names**

```xml
<measure unit="kaļañcu" quantity="100" commodity="gold">nūṛru-k kaļañcu poṇṇum</measure> <measure unit="kāṭi" quantity="28" commodity="paddy">Irupatteṇ kāṭi nellum</measure> kuṭuttēṇ</p>
```

- "I have given one hundred kaļañcu of gold and twenty-eight kāṭi of paddy"

### 7.4.5. Tagged semantic features interacting with text or markup

- this subsection applies to each of the elements `<persName>`, `<placeName>`, `<roleName>` and `<measure>`

- for semantic features with **ends or beginnings merged in sandhi** to an adjacent word, tag the entire name including the character(s) partly belonging to adjacent words
- e.g. `<persName type="human" subtype="coronation">siṁhavarmmā</persName>dhipāt`

- **empty elements** (such as `<lb/>` and `<milestone/>`) may be freely included within tags for semantic features

- **phrase-level elements overlapping with a semantic tag** shall be split into two segments, prioritising the semantic tag

- e.g. `<persName type="human" subtype="coronation">siṁhavar<unclear>mmā</unclear></persName><unclear>dhi</unclear>pāt`

- in the case of a **semantic tag interrupted by** the start or end of a **block-level element**, the semantic tag must be split into two segments, prioritising the block-level element

- in this case, the two parts of the semantic tag will have to be linked as follows:

- add an `@xml:id` (§10.6.4) to both parts, with a value composed of

- the filename followed by an underscore

- followed by “name”, “place”, “role” or “measure” as applicable

- followed by the number “1” (or the next higher number, should a single document contain more than one instance of split tags of the same nature)

- followed by an uppercase A for the first part and an uppercase B for the second part

- to link the two parts, add `@next` to the first part and `@prev` to the second part,

- with the XML ID of the *other* part (prefixed with a # character) as the value of these attributes

<caption>Example 7.4.5.A: personal name split across block-level containers</caption>

```xml
<1> ...
<persName type="human" subtype="sobriquet" xml:id="Pallava00001_name1A"
next="#Pallava00001_name1B">guṇa</persName></1>
<1><persName type="human" subtype="sobriquet" xml:id="Pallava00001_name1B"
prev="#Pallava00001_name1A">bharah</persName>...</1>
```

<caption>Example 7.4.5.B: personal name split across block-level containers</caption>

```xml
<1> ...
<persName type="human" subtype="sobriquet" xml:id="Pallava00001_name1A"
next="#Pallava00001_name1B">guṇa</persName></1>
<1><persName type="human" subtype="sobriquet" xml:id="Pallava00001_name1B"
prev="#Pallava00001_name1A">bharah</persName>...</1>
```

## 7.5. Visual Features

### 7.5.1. The scope of visual features encoded in attributes

- the attributes described in this section for encoding visual features may be used with the following XML elements as the situation demands:

- structural containers, i.e. textpart divisions (§3.4) and forme work (§3.3.5)

- block-level containers, i.e. units of prose (§2.2) and verse (§2.3)

- `<lb/>` elements,<fnref n="38" /> when a localised feature applies to an entire physical line

- the dedicated phrase-level tag `<hi>`,<fnref n="39" /> when the scope of a visual feature is not a pre-existing element

- it may occasionally be necessary to use **multiple values of the attribute @rend** on one element

- attributes cannot be iterated, so in such cases, add both (or all) applicable values within the same set of quote marks, separated by a space

<footnote n="38">³⁸ Though this element is not a container, by EpiDoc convention “Any rend or numbering attributes on ... lb refer to all text between the current and the following line-break” (http://www.stoa.org/epidoc/gl/latest/trans-linebreak.html).</footnote>

<footnote n="39">³⁹ This element is intended in TEI to encode highlighted text, defined as words or phrases graphically distinct from the surrounding text (https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-hi.html). EpiDoc generalises the use of this element to characters with distinguishing graphical features regardless of whether or not these serve the purpose of highlighting (http://www.stoa.org/epidoc/gl/latest/trans-charactershighlighted.html).</footnote>
- in order to reduce the complexity required for processing these, when using multiple values, please
  observe a strict order as follows

- 1. directionality and orientation

- 2. script

- 3. lettering

- e.g. <lb n="01" rend="bt-rotated ornate"/>siddham

### 7.5.2. Alignment

- we assume by default that the lines of an inscription are aligned to the left and more or less justified to the right margin

- large-scale deviations from this pattern shall not be encoded in the markup but rather discussed in your description of the layout

- lines aligned differently than the majority of the lines in an inscription shall be encoded by adding the attribute @style to one of the following elements (but not to any other element):

- `<div type="textpart"/>` to describe all lines in a textpart (§3.4)

- `<lb/>` to describe individual lines (see also §7.5.1)

- the permitted values of @style for encoding alignment are as follows:

- `"text-align: right"` for right-aligned text

- `"text-align: center"` [note the mandatory US spelling] for centre-aligned text

- `"text-align: left"` for left-aligned text

- to be used only if the majority of the lines are aligned differently and this is mentioned in your layout description or encoded for the enclosing textpart division

- `"text-align: justify"` for text conspicuously justified to both margins

- to be used only if the content of a line would fit in a much narrower space and the creator of the inscription deliberately made it flush with both the left and right margin by increasing inter-word or inter-character spaces in a relatively regular manner (i.e. increased spaces are present between all or most separable words of the line, or between all or most characters as applicable)

- spaces within a line that function as semantic segmentation are better encoded as such (§4.3.2) even if they also happen to serve the justification of a line

<figure><img src="image_40.png" /><figcaption>Example 7.5.2.A: encoding line alignment</figcaption></figure>

```
<lb n="1" style="text-align: center"/>J. R. R. Tolkien: The Hobbit
<lb n="2"/>In a hole in the ground...
...
<lb n="4"/>hobbit-hole...
<lb n="7" style="text-align: right"/>28 September 2019
```

### 7.5.3. Directionality and orientation

- the default writing mode for our inscriptions is horizontal top-to-bottom, which means that lines run horizontally (and left to right in the scripts we work with), while successive lines are placed one below the other
- some inscriptions may be written throughout in a different writing more (e.g. vertically, with lines proceeding left to right; or horizontally, with lines proceeding left to right, but in a bottom to top order); if this is the case, it should be recorded in your metadata

- lines oriented differently than the majority of the lines in an inscription may be encoded by adding the attribute @rend<fnref n="40" /> to one of the following elements (but not to any other element):

- `<div type="textpart">` to describe all lines in a textpart (§3.4)

- `<fw>` to describe the contents of a forme work item (§3.3.5)

- `<lb/>` to describe individual lines (see also §7.5.1)

- the permitted values of @rend for encoding directionality and orientation are as follows:

- "bt-rotated" - written vertically from bottom to top, with the tops of characters facing left (A in the illustration)

- "tb-rotated" - written vertically from top to bottom, with the tops of characters facing right (B in the illustration)

- "bt-upright" - written vertically from bottom to top, with the tops of characters facing upward (C in the illustration)

- "tb-upright" - written vertically from top to bottom, with the tops of characters facing upward (D in the illustration)

- "rl-upright" - written horizontally from right to left, with characters in their regular orientation (E in the illustration)

- "rl-flipped" - written horizontally from right to left, with characters mirrored around their vertical axis as in true boustrophedon (F in the illustration)

- "rl-rotated" - written horizontally from right to left, with the tops of characters facing downward (G in the illustration)

- should you encounter any other combination of directionality and orientation (e.g. right to left), contact the authors and the XML-TEI Data Manager to agree on a new authorised value

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

### 7.5.4. Script

- the default script of an inscription must be specified in your metadata and described in the Hand Description (§11.2.1)

- the instructions in this subsection do not apply to inscriptions that employ a single script, nor to inscriptions in which script varies in one of the following ways:

- changes in the style of lettering, are covered in §7.5.5 below

- if script change is concomitant with a language change, then your metadata should specify the scripts used for each language in your inscription, and language changes must be encoded as per §7.2, without explicitly encoding script change

- changes in the scribal hand do not qualify as script changes and should be encoded as per §4.4

- to tag a chunk of text as being written in a different script, add the attribute @rend to its containing element or, if not coterminous with an existing block-level container, use `<hi>` to wrap the chunk of text concerned and add @rend to this element

- the permitted values of @rend for script classification are at present limited to the following:

- "grantha"

- if you wish to encode a different script that alternates with the primary script of an inscription you are working on, please contact the authors of this Guide and the XML-TEI Data Manager to settle on an authorised value

- when encoding Grantha characters interspersed in Tamil or Vaṭṭeuttu script, note that only characters graphically distinct from the default script of the inscription should be marked up in this way

<footnote n="40">⁴⁰ Although the TEI guidelines (https://www.tei-c.org/release/doc/tei-p5-doc/en/html/WD.html#WDWMEG) recommend the use of CSS styling instructions to encode text directionality and orientation, these instructions provide no clear solution for handling case C in the illustration below and handle cases A and B very differently from D. To minimise complexity, we prefer to introduce custom values of @rend for this purpose, since our objective is to document the way the original text was written, and not to create machine-actionable code for reproducing the original orientation on screen or in print.</footnote>
- e.g. திழடுவண <hi rend="grantha">tribhu</hi>vaņa if the default script is Tamil (where the va is considered Tamil, though it has the same form in Grantha);

- but <hi rend="grantha">tribhuva</hi>ņa for the same text if the default script is Vaṭṭeuttu (where the va is definitely not Vaṭṭeuttu and is thus classified as Grantha; though it could also be classified as Tamil)

7.5.5. Lettering

- this subsection concerns changes in lettering, i.e. the style in which the glyphs of a particular script are formed

- the following variations are not changes in lettering:

- change to a different class of script, covered under §7.5.4 above

- changes in scribal hand, covered under §4.4

- to tag a chunk of text as being written in different lettering, add the attribute @rend to its containing element or, if not coterminous with an existing block-level container, use <hi> to wrap the chunk of text concerned and add @rend to this element

- the permitted values of @rend for lettering are at present limited to the following:

- "ornate"

- "large"

- "small"

- "tall"

- "wide"

- "expanded" (for character spacing)

- if more than one of the above is definitely relevant for a particular segment of text, encode them in the order of the list above

- if you wish to encode a different style of lettering, please contact the authors of this Guide and the XML-TEI Data Manager to settle on an authorised value

- e.g. <ab rend="ornate">svahasto mama mahārājādhijrāja-śrīharṣasya</ab>
# 8. General Guidance for Tidy XML Code

## 8.1. Spaces and New Lines in the Code

### 8.1.1. White space

- in coding terminology, **white space** (or whitespace) means a blank space in a document, i.e. any combination of spaces, tabs and new line (carriage return) characters<fnref n="41" />

- white space that affects the processing and transformation of an XML document is called **significant**, while white space that does not is called **insignificant**

- **white space inside XML tags** is as a rule insignificant

- thus, each of the following are perfectly equivalent:

- `<lb n="1" break="no"/>`

- `<lb n="1" break = "no" />`

- `<lb n="1" break="no"/>`

- some form of white space must, however, be present before all attribute names, so the above are not equivalent to the following:

- `<lb n="1" break="no"/>`, which is incorrect XML

- white space within attribute values is significant, so the above are also not equivalent to either of the following:

- `<lb n=" 1" break="no"/>`, which is a different value than "1"

- `<lb n="1" break="no" />`, which is not meaningful in TEI

- when **an element contains only other elements and white space**, this space is as a rule insignificant; thus, `<p><lb n="1"><gap reason="lost" extent="unknown"/></p>` is perfectly equivalent to each of the following:

- `<p> <lb n="1"/> <gap reason="lost" extent="unknown"/> </p>`

- `<p> <lb n="1"/> <gap reason="lost" extent="unknown"/> </p>`

- the handling of **white space within text-containing elements** is a complex matter controlled by the software processing and transforming the XML document; for our purposes

- in general, white space in content is significant, but in the course of processing it is *collapsed* and *trimmed*

- **collapsing** means that any type and quantity of white space is reduced to a single space character

- **trimming** means that space is stripped from the beginning and end of the text content of an element

- thus, `<p>In a hole in the ground there lived a hobbit.</p>` will normally produce the same transformed text as any of the following:

- `<p> In a hole in the ground there lived a hobbit. </p>`

- `<p> In a hole in the ground there lived a hobbit. </p>`

- moreover, the transformed text generated from `<p><lb n="1"/>In a <unclear>hole</unclear> <supplied reason="omitted">i</supplied>n the ground there lived a hobbit</supplied></lb></p>` will normally not be affected by any of the following alterations:

<footnote n="41">⁴¹ See https://wiki.tei-c.org/index.php/XML_Whitespace for a more detailed discussion of white space in XML.</footnote>
- ... `<unclear> hole </unclear> ...` (the white space at the beginning and end of the text content of the `<unclear>` element is trimmed)

- ... `<supplied reason="omitted"> i </supplied> n the...` (the white space at the beginning and end of the text content of the `<supplied>` element is trimmed)

- however, each of the following alterations **will** affect the output:

- `<p><lb n="1"/>` In a ... (the added space before "In" is not the first in the content of any element, so it will not be trimmed)

- `<p><lb n="1"/>` In a `<unclear> hole</unclear>` (the space moved from a position after "a" to one before "hole" within `<unclear>` will be trimmed, since it is now the first in that element)

- ... `<unclear>hole</unclear><supplied reason="omitted">i</supplied> n the...` (the deleted space between `<unclear>` and `<supplied>` will not be automatically added in processing)

- ... there lived a hobbit <g type="floret"/></p> (the added space after "hobbit" is not the last in the content of any element, so it will not be trimmed)

### 8.1.2. Editorial spaces and markup

- see TG §2.6.1 for general guidance about where and how editorial spaces (for word separation) should be employed, and §8.1.1 above about how spaces in your XML document will be processed

- the above summary of white space in the processing of XML documents will not necessarily apply to the processing of our encoded files, chiefly for the following reasons

- the attribute `@xml:space="preserve"` is added to the `<text>` element of our documents in order to tell processing algorithms not to trim white space, but the behaviour of various processing algorithms in complex situations is not entirely predictable

- as we progress with the development of display transformations, white space may be deliberately added or removed in certain markup contexts

- therefore, do not bother memorising the subtleties of whitespace handling theory; instead, **as a rule of thumb**

- avoid adding spaces to your text except where a space is required for word separation

- but make sure to add all spaces required for word separation even if an XML element is also present at the same point

- any kinks appearing due to the presence or absence of space at certain spots can be ironed out later on

- but to be able to reduce the number of kinks that need to be ironed out, read the specific guidelines below

- with **block-level containers**, feel free to enter their contents in a new line after the start tag and/or to put the end tag in a new line if that makes your work easier for you

- **transition points** (`<lb/>`, `<pb/>` and `<milestone/>` of any kind) are not text containers, so white space after such an element will not be trimmed, therefore pay attention to the following:

- never add white space after these elements

- it is acceptable to add white space before these elements provided that they occur between words (and thus do not take `@break="no"`)

- but it is not necessary to add white space before them; the applicable space or new line will be created in our transformation if `@break="no"` is not present

- to prevent anomalies in processing, avoid adding white space before these elements if they occur within words (and thus take `@break="no"`)

- however, to make your XML file easier to scan, you may use a carriage return within the `<lb>` tag (at a point where a space is present); this will not interfere with the processing of the code

- thus both of the following arrangements are permitted and equivalent:

- catur-udadhi-salilāsvā<lb break="no" n="2"/>dita-yaśaso

- catur-udadhi-salilāsvā<lb break="no" n="2"/>dita-yaśaso

- moreover, for transition points not interrupting words, all of the following arrangements are permitted and equivalent:
- saimhaļakādibhiś ca<lb n="24"/>sarvva-dvīpa-vāsibhir

- saimhaļakādibhiś ca <lb n="24"/>sarvva-dvīpa-vāsibhir

- saimhaļakādibhiś ca
  <lb n="24"/>sarvva-dvīpa-vāsibhir

- saimhaļakādibhiś ca<lb
  n="24"/>sarvva-dvīpa-vāsibhir

- **phrase-level elements enclosing text** (e.g. those encoding reading difficulties, editorial intervention and restoration) are text containers, therefore pay attention to the following:

- spaces outside such elements should be used wherever necessary, i.e. wherever the text within a phrase-level container belongs to a word separate from its neighbour outside the container, e.g.

- evam <unclear>etaT</unclear> must have a space before the container

- evam e<unclear>taT</unclear> must not have a space before the container

- white space at the inner edges of such containers may be trimmed from their content

- therefore any necessary spaces must be placed outside these containers, e.g.

- evam<unclear> etaT</unclear> is incorrectly spaced

- while evam <unclear> etaT</unclear> is correct, though it contains a superfluous space within the <unclear> tag

- in elements that encode two (or more) alternative readings for a stretch of text, it may be necessary to add a space at the beginning or end of only one of these alternatives

- to avoid anomalies in processing, in such cases you should increase the scope of the elements so that the space is not at the edge of the content, e.g.

- in an ambiguous reading that may be tathāpi or tathā hi,

- tathā<choice><unclear>p</unclear><unclear> h</unclear></choice>i is incorrectly spaced (since the space before *h* may be trimmed)

- to eliminate the problem, use <choice><unclear>tathāpi</unclear><unclear>tathā hi</unclear></choice> or tath<choice><unclear>āp</unclear><unclear>ā h</unclear></choice>i

- in an editorial correction of *gatakāle* to *gate kāle* (assuming that *gatakāle* is plausible in the context as a compound, but inferior to *gate kāle*)

- gat<choice><sic>a</sic><corr>e</corr></choice>kāle is incorrectly spaced (since the space after *e* may be trimmed)

- to eliminate the problem, use <choice><sic>gatakāle</sic><corr>gate kāle</corr></choice> or gat<choice><sic>ak</sic><corr>e k</corr></choice>āle

- **elements representing or enclosing non-alphabetic characters**, i.e. <g> and <num>

- use spaces around (and outside) these elements as you would expect to see them in an edition, e.g.

- between numerals and text

- between symbols and following text, but not, as a rule, between symbols and preceding text

- should such an element interrupt a word, do not add editorial spaces around it

- the content of these elements, when they have any content at all, should not include spaces

- except when a <num> element encloses <g> elements or vulgar fraction signs, which for the sake of consistency should be separated by a space from each other and from any Arabic digits within the same <num>

- **encoded space**, <space>

- as a rule, add an editorial space on either or both sides of a <space> element where it meets text or numerals

- but do not add a space when <space> interrupts a word, as can happen with <space type="binding-hole">

- when one of these elements occurs at a point where an editorial space is already required for word spacing, add a space on either side or both sides of the element as you would expect to see spaces in your displayed edition
- that is to say, add a space on any side where such elements meet text, but not where they meet other elements of this nature

- the content of these elements, when they have any content at all, should not include spaces

- except when a `<num>` element encloses `<g>` elements or vulgar fraction signs, which for the sake of consistency should be separated by a space from each other and from any Arabic digits within the same `<num>`

- **lacunae** (i.e. `<gap>` elements), where they are adjacent to extant or restored text, should normally be separated from text by a space

- unless you are reasonably confident that the lacuna included part of a word whose other part is preserved outside the lacuna, in which case the text should precede or follow the `<gap>` element without an intervening space

- by convention we shall take a lacuna encoded without an intervening space as a definite indicator of an editorial hypothesis that the word preserved adjacent to the lacuna is not complete

- whereas a lacuna encoded with an intervening space will not be regarded to imply any hypothesis about the completeness or incompleteness of the preserved word

- **unintelligible text** (marked up as `<unclear>`, or as `<sic>` if they are clear but unintelligible), where adjacent to extant or restored text, should be spaced in the same way as lacunae

- in any stretches of text where - due to damage, scribal errors or sub-standard language use - word spacing cannot be allocated definitively but becomes possible after editorial intervention (restoration and emendation), feel free to space the text only as required for your editorial text, i.e. do not feel bound to encode all your spaces as parts of your editorial alterations

### 8.1.3. Editorial hyphens and markup

- see TG §2.6.2 for general guidance about editorial hyphens (for compound segmentation)

- hyphens should never be used at the ends of epigraphic lines

- if a line beginning interrupts a word, the element encoding the new line must take the attribute `@break="no"`

- the same applies to `<pb/>` and `<milestone/>` elements

- when an editorial hyphen (marking an in-compound word boundary) coincides with one of the above elements or with a `<space/>`, the hyphen shall be placed at the beginning of the text after the intervening element(s)

- for other cases where editorial hyphenation interacts with markup, follow the directions for editorial spaces in §8.1.2 above, except that unlike space, hyphens may be used without worries at the beginning or end of text-containing elements

## 8.2. Top to Bottom Hierarchy

- while applying markup to encode various features, it is useful to keep in mind the rough hierarchy outlined below

- any element of a particular level may contain elements of a lower level and in many cases also elements of the same level, but may not contain elements of a higher level

- in case of overlap, elements lower in the hierarchy must give way to higher-level elements, i.e. the lower-level element must be split into two parts across the boundary of the higher-level element (examples below)

### 8.2.1. Block-level elements representing XML structure and extrinsic structure

- text divisions: the edition `<div>` wraps everything within your edition

- if textpart divisions (§3.4) are present, then these are the direct children of the edition `<div>` and wrap everything else
### 8.2.2. Block-level elements representing intrinsic structure

- all text in your edition must be contained in one of the block-level elements representing intrinsic structure: `<p>`, `<ab>`, or `<lg>` and `<l>`

- these elements must appear directly within the divisions, never outside them

- these elements must never be nested inside another element of this class, except that `<l>` elements must always be nested in `<lg>` elements

- as a special block-level container, `<fw>` will normally be nested within one of the above regular block-level containers, but may in some unlikely cases be outside them (§3.3.5)

### 8.2.3. Empty elements representing extrinsic structure

- elements marking transition points, namely line beginnings (§3.2.1), page beginnings (§3.5.2) and pagelike milestones (§3.5.3), must normally be placed within level-2 elements<fnref n="42" />

- *except* special cases where such transition points cannot be integrated into the text following them, namely

- page beginnings for the first and last blank pages of a set of copper plates (§3.5.2), which have no associated text

- reconstructed transition points (of any kind) in massive initial or medial lacunae (§5.4.7)

### 8.2.4. Empty elements representing local features

- elements belonging to this level are spaces (§4.3) and unrestored lacunae (§5.4) including lacunae with known metre (§5.4.4)

- these empty elements with a spatial extent must by default be contained within level-2 elements and must not be placed before the first level-3 elements of a document

- *except* that when necessary, lacuna markup may appear outside an element of intrinsic structure and before the first level-3 element (§5.4.7)

- these empty elements with a spatial extent must give way to elements of level 3 and above in case of conflict

- thus, a space or lacuna interrupted by the start-tag or end-tag of any element of intrinsic structure (e.g. a verse line) or by an element of extrinsic structure (e.g. a line break) must be encoded as two separate instances

**Example 8.2.4.A: lacuna split across line break**

```html
<lb n="1"/><gap reason="lost" extent="unknown"/>devyām utpanna<gap reason="lost" extent="unknown"/><lb n="2"/><gap reason="lost" extent="unknown"/>ṭṭārikā-devyām utpannaḥ śrī-mahārājeśvaravarummā...
```

- here, the lacuna between utpanna and ṭṭārikā is encoded as two separate lacunae, one at the end of line 1, and another at the beginning of line 2; the line beginning element stands between these two

### 8.2.5. Phrase-level elements

- elements belonging to this level include:

- feature markup, e.g. for reading difficulties (§5.3) and script (§7.5.4)

- semantic markup, e.g. for numerals (§7.1), abbreviations (§7.3) and language (§7.2)

- editorial intervention, e.g. restoration (§5.5), correction (§6.2) and normalisation (§6.3)

- such phrase-level markup encoding semantic or descriptive information about specific characters must

- always be contained within level-2 elements

- in case of conflict give way to elements of level 4 and above

- thus, a phrase-level element interrupted by the start-tag or end-tag of any element of intrinsic structure or by an element of extrinsic structure must be encoded as two separate instances

<footnote n="42">⁴² This is not a technical requirement and its violation does not result in your code becoming invalid. However, since in many cases these elements will have to appear within block-level containers, we consider it better practice to always place them so, for consistency's sake.</footnote>
### Example 8.2.5.A: editorial restoration split across verse lines

```html
<lg n="1" met="anuṣṭubh">
  <l n="a">svadattām para-dattām vā</l>
  <l n="b">yo hareta va<supplied reason="lost">sundharām</supplied></l>
  <l n="c"><supplied reason="lost">sa viṣṭhāyām kṛmir bhūtvā</supplied></l>
  <l n="d"><supplied reason="lost">pitṛ</supplied>bhiḥ saha pacyate</l>
</lg>
```

* the lost and supplied text in the middle of the stanza is encoded as three separate instances of supplied text: the end of *pādas b*, all of *pāda c*, and the beginning of *pāda d*

- phrase-level elements may usually be nested inside others except for `<unclear>`, for which see below

- otherwise, you may nest phrase-level markup as logic dictates, so long as you avoid overlaps, which must be eliminated by creating separate instances of interrupted markup elements

### Example 8.2.5.B: overlapping phrase-level elements

```
uktañ ca bhagavatā veda vyāsena vyāsena vyāsena
```

* the stretch struck out in the text above represents unclear text in the original

* the last iteration of vyāsena is scribal dittography, which you as editor suppress
```
uktañ ca bhagavatā ve<unclear>da-vyāsena vyāsena</unclear>
<surplus><unclear>vyā</unclear>sena</surplus>
```

* the `<unclear>` element is split into two parts, one in the retained text and one in the suppressed segment

- the element `<unclear>` must, by EpiDoc rules, contain only text and may never contain any markup elements except `<g>`; thus,

- when `<unclear>` overlaps with another markup element, it is always `<unclear>` that must be split into separate parts inside and outside the other element, as in Example 8.2.5.B above

- when a different element (other than `<g>`) needs to be nested inside `<unclear>`, then again, `<unclear>` must be split into separate parts as in Example 8.2.5.C below, to allow the nesting of `<unclear>` within the other element instead of the other way round

### Example 8.2.5.C: overlapping phrase-level elements

```
puṇyābhi vṛiddhaye
```

* the stretch struck out in the text above represents unclear text in the original

* the spelling *ri* is non-standard and you, as editor, flag it as such
```
puṇyābhi<unclear>v</unclear><orig><unclear>ri</unclear></orig><unclear>ddhaye</unclear>
```

* the `<unclear>` element is split into three parts, one before the flag, one for the flagged segment within the `<orig>` tag, and one after it
# 9. Additional Content Divisions

## 9.1. The Critical Apparatus

### 9.1.1. Overview

- the primary purpose of an apparatus in our project's diplomatic editions is to record significant alternative readings, restorations and emendations by previous editors

- unless a specific sub-corpus or a particular text requires this, a complete record of minor differences (e.g. typing and printing errors, orthographic normalisation or whether a reading is shown as unclear or tentatively read/reconstructed) is not desirable

- the apparatus is not normally the place to record your own editorial choices such as preferred readings, restorations, emendations, and flagging of any original text as unexpected or inappropriate

- all of these must be encoded in the inline markup within your `<div type="edition">` wherever possible

- however, apparatus notes may be used to add details or reasoning to such choices, and to record highly tentative proposals you are not confident enough to include in the edition itself

- TEI and EpiDoc allow a variety of ways to encode a critical apparatus for a scholarly edition; within the DHARMA project we shall limit ourselves for epigraphical work to an **external apparatus criticus**

- this means that the apparatus entries are encoded in a section separate from the edition (namely, within the `<div type="apparatus">`) and referenced to locations within the text

- for the sake of project-wide consistency and ease of processing, the external apparatus shall be encoded as follows

- after your `<div type="edition">` element, your document shall include a `<div type="apparatus">` containing the element `<listApp>`

- within `<listApp>`, each apparatus entry must be individually wrapped in the element `<app>`, which

- must **mandatorily** have the attribute `@loc` to indicate the location (epigraphic line) to which your entry pertains, as per §9.1.2 below

- must **mandatorily** contain `<lem>` as its first child element, containing a lemma as per §9.1.3 below

- may contain one or more `<rdg>` elements (one for each alternative reading/restoration/emendation), as per §9.1.4 below

- may contain one or more `<note>` elements containing a human-readable note in freeform text pertaining to that particular lemma, as per §9.1.7 below

- if your edition division includes **boxlike partitions** (§3.4), then mandatorily **replicate** those **textpart divisions** within the `<div type="apparatus">`

- see §9.1.8 below for details
<caption>Example 9.1.1.A: critical apparatus</caption>

a snippet from the edition <div> of the Allahabad *praśasti* of Samudragupta

```xml
<div type="edition" xml:lang="san-Latn">
  [...]
  <lg n="2" met="śārdūlavikriḍita">
    <1 n="a"><lb n="7"/><supplied reason="lost" cert="low">ā</supplied><unclear>ry</unclear>y</supplied reason="lost" cert="low">ai</supplied><unclear>h</unclear>īty upaguhya bhāva-piśunair utkarṇṇitai romabhiḥ</1>
    [...]
  </lg>
  [...]
</div>
```

9.1.2. Indicating location

- the value of the attribute @loc must unambiguously specify the location to which the apparatus entry pertains

- the primary purpose of this value is to be intelligible to a human reader, but we may wish to make it machine-actionable in the future and therefore adopt rigorous rules from the beginning

- locations shall normally be identified as epigraphic lines, using line numbers as reference, because they are (almost) ubiquitous and unique in our editions

- therefore, the value of @loc shall normally be the line number, i.e. the @n attribute of the <lb/> element representing the beginning of the target line

- if the entry refers to a segment of text that extends across a line break, then @loc shall be the number of the first line where the segment begins; see also §9.1.6 below about the inclusion of line (and other) beginning tags in a lemma

- the sole exception to the ubiquitous presence of line numbers in our editions is forme work (§3.3.5)

- it is therefore not possible to refer to the contents of forme work using line numbers

- should you need to add an apparatus entry for a forme work item, the value of @loc shall be the number of the forme work item prefixed with the letters "fw", e.g. `<app loc="fw2r"/>` to refer to the forme work element with the number 2r

- the sole exceptions to the uniqueness of line numbers are **editions comprised of textpart divisions** (§3.4), where line numbers will be restarted in each division

- however, since the apparatus division of the document must replicate the textpart divisions of the edition division, @loc references in the apparatus still only need to include the @n of the target line and will remain unambiguous
- although some of us may be used to referring to stanza numbers in apparatus entries, we have chosen not to allow this in order to reduce the complexity of referencing

- apparatus entries for lemmas in verse shall be referred to by line number like those in prose

- notes concerning entire stanzas shall be added to the commentary, not to the apparatus

### 9.1.3. Specifying a precise spot by a lemma

- the exact spot (locus) to which an apparatus entry pertains is specified by a lemma, tagged with the XML element `<lem>`

- there are no strict rules for the **extent of your lemmas**; as with any critical apparatus, lemmas should be large enough to make them unambiguous within the line referred to in the `@loc` attribute and small enough to remain concise

- lemmas should preferably consist of whole words, which may be members of compounds in the text

- when the lemma boundary does not coincide with a word boundary (i.e. an editorial space) in the text, indicate this in the lemma as follows:

- when a lemma cuts a non-compound word, use the character ° (but preferably use a whole word as a lemma), e.g.

- text *puṇyābhivṛddhaye*; lemma °vṛddhaye (where *abhivṛddhaye* is not a compound word)

- when a boundary between independent words or compound members is obscured by sandhi, use the character °, e.g.

- text *puṇyābhivṛddhaye*; lemmas *puṇyā*° and °ābhivṛddhaye (*not* *puṇya*° and °abhivṛddhaye)

- text *yathāsmābhiḥ*; lemmas *yathā*° or °āsmābhiḥ (*not* °asmābhiḥ)

- text *maharṣi*; lemmas *maha*° or °rṣi

- when a boundary between compound members is not obscured by sandhi, then depending on whether or not you hyphenate that word in your edition, use

- the character ° if you do not hyphenate, e.g.

- text *śrīpolekeśivallabhasya*; lemmas *śrī*° or °polekeśi° or °vallabhasya

- a hyphen if you do hyphenate, e.g.

- text *śrī-polekeśi-vallabhasya*; lemmas *śrī-* or -*polekeśi-* or -*vallabhasya*

- avoid very long lemmas, if possible, by breaking them up into several smaller ones

- long lemmas that cannot be split up in this way may be shortened by replacing a section of them with `<gap reason="ellipsis"/>` (which will be displayed as “...”)

- the lemma should appear **exactly as it appears in your digital edition**,<fnref n="43" /> including any markup that encodes information about reading difficulties and editorial intervention

- see §9.1.6 for some concerns pertaining to the use of markup in lemmas

- `<lem>` may take the attribute `@source` (§10.6.2) to show that a **previous edition supports the reading adopted in your edition**

- see §9.1.5 below for guidance on deciding whether a reading supports yours

- if your apparatus entry consists only of a lemma (without either `<rdg>` nor `<note>`), then `@source` must be present on the lemma, since the sole purpose of such an entry is to credit a previous editor for a difficult reading or ingenuous restoration

- such apparatus entries will be rare; only create them if you feel they are necessary

- if your apparatus entry contains a `<note>` but no alternative readings, then there is no need to credit the lemma to a source unless credit is particularly due to a previous editor for an ingenious reading adopted in your edition

- if your apparatus entry contains alternative readings, then (whether or not it also contains a `<note>'), any previous editors who agree with the lemma must be credited with `@source`

- keep in mind that whenever you use `@source` on a lemma, the bibliographic citation of that publication in bibliography division must include an encoded siglum for use in the apparatus, as per §9.4.3

<footnote n="43">⁴³ That is to say, in addition to preserving the markup in your edition, you must also not add any further markup such as italicisation.</footnote>
### 9.1.4. Alternative readings, restorations and emendations

- alternatives to your edited text should be recorded as the contents of an `<rdg>` element

- text within this element should be marked up with XML tags to clearly indicate what the cited editor deemed unclear, emended or supplied

- that is to say, convert the original editor's markup and/or additional explanation into XML tags endorsed by this guide as best possible

- since the markup found in many printed editions is less expressive and/or less rigorously consistent than our EpiDoc conventions, you may need to interpret the intention of the original editor and mark up alternatives accordingly

- we deem this method to be preferable to the disadvantages inherent in the alternative, namely recreating all brackets etc. precisely as observed in the previous edition

- never retain any traditional editorial markup (such as brackets or asterisks)

- see §9.1.6 for some concerns pertaining to the use of markup in readings, in particular about the encoding of line breaks within a reading

- the **extent of an alternative text segment** should always correspond exactly to the extent of its lemma

- as in lemmas, use ° or a hyphen at the beginning or end of an alternative if its boundary does not coincide with the boundary of an independent word of the text

- see §9.1.3 for details and examples

- if a printed edition shows nothing (i.e. not even a lacuna) at a locus where your edition has content (including a tentative reading or a lacuna), the reading of the edition in question may be represented by an empty element, e.g.

- `<rdg source="bib:VenkatasubbaAyyar1943_01"/>`

- alternatives **must always be credited** to the editor(s) who proposed or endorsed them, using the attribute `@source` in `<rdg>`; see §10.6.2 for details

- see §9.1.5 below for guidance on deciding whether two editors' readings may be deemed identical

- if your apparatus includes at least one lemma with alternative readings *and* you cite more than one previous editor, your apparatus entries should always be formulated in a **"positive"** manner: for any lemma with one or more alternative readings, clearly indicate (either under the lemma or under one of the alternative readings) what the readings of **all** previous editors were

- however, keep in mind that your apparatus does not have to list every minor divergence from previous editions (see §9.1.1)

- also keep in mind that whenever you cite a reading from a publication, the bibliographic citation of that publication in your bibliography division must include an encoded siglum for use in the apparatus, as per §9.4.3

### 9.1.5. Identical lemmas, identical readings

- when **deciding whether two readings may be deemed identical**, i.e. whether a certain previous edition's reading agrees with your lemma or with the reading cited from another previous editor, you should normally consider only the actual received text shown in each edition

- ignore differences that consist only in the presence or absence of markup for unclear or restored characters

- e.g. if one reading is `ya<unclear>thā</unclear><supplied>reason="lost"</supplied>` and another is `yathāsmābhiḥ` without any markup, then the two readings are to be deemed identical

- ignore previous editors' emendations or normalisations if they do not affect the interpretation of the text, i.e. if you (or another editor) have chosen only to flag a phenomenon as erroneous or non-standard, or chosen to ignore one, whereas a previous editor reads the same but emends or normalises it, then their reading is still to be deemed as identical to your lemma

- if a previous edition contains a minor orthographic mistake that does not affect the meaning and that may well be a typographic error in that edition, feel free to ignore it if their reading is otherwise identical to yours (or to another previous edition's)
- if your edition's textpart divisions have `<head>` elements, these should likewise be replicated in the apparatus, immediately after the start-tag of each textpart division

- the apparatus container `<listApp>` must in this case be enclosed within `<div type="textpart">`

- if you have apparatus entries for more than one textpart, then create a `<listApp>` within each textpart to wrap the `<app>` elements belonging to that textpart

- if one or more textparts have no pertaining apparatus entries, then the textpart division (with attributes) must still be created for these in the apparatus, but that division shall not contain anything (except, if applicable, `<head>`), i.e. there should not be a `<listApp>` wrapper, nor any `<app>` items there

<caption>Example 9.1.8.A: critical apparatus with more than one textpart, each with content</caption>

```html
<div type="apparatus">
  <div type="textpart" n="A">
    <head xml:lang="eng">Seal</head>
    <listApp>
      <app loc="1">
        <lem>ku<unclear>mā</unclear>rāmātyādhikaraṇasya</lem>
        <note>Our restitution ... </note>
      </app>
    </listApp>
  </div>
  <div type="textpart" n="B">
    <head xml:lang="eng">Plate</head>
    <listApp>
      <app loc="2">
        <lem>°bhi<supplied reason="omitted">h</supplied> mekhalayā</lem>
        <note>Absence of doubling ... </note>
      </app>
      ...
    </listApp>
  </div>
</div>
```

<caption>Example 9.1.8.B: critical apparatus with more than one textpart, one without content</caption>

```html
<div type="apparatus">
  <div type="textpart" n="A">
    <head xml:lang="eng">Seal</head>
  </div>
  <div type="textpart" n="B"><head xml:lang="eng">Plates</head>
    <listApp>
      <app loc="6">
        <lem>-pu<unclear reason="eccentric_ductus">ñja</unclear></lem>
        <note>While <foreign>puñja</foreign> must have been intended ... </note>
      </app>
      ...
    </listApp>
  </div>
</div>
```

## 9.2. The Translation

### 9.2.1. Overview

- whenever possible, a translation should be included in your XML document along with your edition

- the translation must be wrapped in `<div type="translation">`

- this division follows the edition division and the apparatus division

- use the following attributes for `<div type="translation">`

- mandatorily, `@xml:lang` to encode the target language (see Appendix D for a list of language codes permitted as values for this attribute)

- generally, one of the following:
- `@source` (§10.6.2), if a published translation is adopted verbatim

- `@resp` (§10.6.1), if the translation is by you and/or another project member

- in more complicated situations, such as a collaborative translation or the use of an unpublished translation by another person, finer details of authorship may be recorded in a credit note (§9.2.2), which may be used in addition to or instead of `@source` or `@resp`

- your translation should be a convenient representation of the intent of the original, hence it should be as literal as seems useful, but as free as seems necessary

- translations of your own should correspond to the text as you have edited it, including restorations and emendations

- by contrast with our epigraphic editions, where the spelling of the original is always retained in xml and viewable in display (notwithstanding any editorial interventions that may be marked up), in translation you are advised to ignore the original's superficial irregularities/oddities of punctuation and spelling

- in particular, normalise the spelling of original personal names, toponyms and terms retained from the original, as suggested for "loose transliteration" in TG §2.2.2

### 9.2.2. Front matter in a translation

- we foresee that headings for translations will be generated automatically on the basis of the `@xml:lang` and `@source` or `@resp` attributes of the translation division

- e.g. `<div type="translation" xml:lang="eng" resp="part:daba">` displayed as a heading "Translation into English by Dániel Balogh"

- to create a custom header for a translation where the above is insufficient,

- include the element `<head>` as the first item within `<div type="translation">`

- containing free text that is to be displayed as a heading above the translation

- such headers, if used, will replace the auto-generated header, so it is recommended that you include the word "Translation" and a specification of the target language

- a credit note may be added after the header where necessary, e.g. to give credit to someone

- who has helped with the translation as a whole, or

- whose published translation you have reworked, or

- whose unpublished translation you are adopting in whole or in part

- to create a credit note, include the element `<note type="credit">` as the first item within `<div type="translation">` (or as the second item, immediately after the custom `<head>` if one is used)

- containing free text consisting of one or more complete sentences (with a capital initial and final punctuation) and, if applicable, including a citation (§10.4.5) of the published translation credited

- this `@type` of `<note>` will only be used in the translation division, for this particular purpose

- keep in mind that a credit note should not be used in translations adopted verbatim from a publication, nor for translations created by project members

- in both these cases, authorship must be encoded in the attributes of the translation division (using `@source` or `@resp` as applicable, see §9.2.1 above)

### 9.2.3. Attaching multiple translations

- if you wish to include more than one translation, simply repeat `<div type="translation">` for each of them, with attributes applied as above

- there is no requirement to include multiple translations just because they are available

- new translations created by you, the encoder of the inscription, are preferred

- pre-existing translations may be added

- when a new translation is not feasible or a previous translation is so satisfactory that a new translation is unnecessary

- when you deem them good enough and are in a major modern language other than the one you are translating to

- when you deem them relevant to the history of the understanding of the inscription
- when you include more than one translation in your XML document, these should be presented in an order of decreasing usefulness, prioritising those which are more recent, more accurate, and in more widely spoken languages

<caption>Example 9.2.3.A: multiple translations</caption>

```xml
<div type="edition" xml:lang="x-oldcham-Latn">
  ...
  <ab>pu vyà</ab>
  ...
</div>

<div type="translation" xml:lang="eng">
  ...
  <p>Her majesty the queen</p>
  ...
</div>

<div type="translation" xml:lang="fra">
  ...
  <p>Sa majesté la reine</p>
  ...
</div>
```

### 9.2.4. Reproducing a published translation

- when encoding a previously published translation without changes, the **author** of that translation **must be credited** using the attribute `@source` (§10.6.2)

- to credit a contributor other than the author of a published translation, or to indicate the author of a published translation that you have improved on, attach a credit note (§9.2.2) to the beginning of the translation

- as far as feasible, **convert** any character-based **markup** used by the original translator to XML-based markup

- translator's marks that cannot be converted to XML equivalents may be retained (as an exception to the rule of not using non-XML markup)

- clarify any such markup within the credit note

- any **words transliterated** from an Indic script appearing in a translation you adopt, or the notes attached to it, should be silently converted to our transliteration system whenever feasible

- however, when the element `<quote>` (§10.4.4) is used to cite parts of a translation, the original transliteration should be preserved

- **notes attached to a published translation** do not have to be reproduced verbatim or in their entirety

- however, any notes attached to a translation will by default be assumed to be by the author credited in the attributes of the translation as a whole (as per §9.2.1), therefore any notes that are not reproduced verbatim from the published translation must be attributed explicitly as follows:

- when adding notes of your own, use `@resp` (§10.6.1) on each such note to encode your authorship

- when supplementing a published translation with notes from another source, use `@resp` (§10.6.1) or `@source` (§10.6.2) to assign credit to a project member or to a publication, as applicable

- when paraphrasing notes that are not your own, likewise use `@resp` (§10.6.1) to encode your authorship, and include in your paraphrase an attribution to the original author of the note

- if that original author is the person to whom the translation as a whole is credited, then this attribution need not include an encoded reference, e.g. "Fleet observes that..."

- if a published translation is **based on a reading**, restoration or emendation **other than what you adopt in your edition**, it is highly recommended that you point this out in a note of your own, attached to the spot where the translation is based on divergent text

- when a published translation you are encoding **omits a stretch of the text** (for example because it is unintelligible or because the original publisher considered a part of the text not worthy of attention), this shall be indicated in your encoding as per §9.2.12)

- handling **mistakes in a published translation**
- it is recommended that you silently correct any obvious typographic errors in a published translation you are reproducing

- unusual or incorrect interpretation and unexpected transliteration/normalisation found in published translations may be flagged with <sic> as per §9.2.11

### 9.2.5. Structural markup in translation

- the overall structure of a translation should, as far as practicable, imitate the structure of the original inscription, in the following manner

- if your edition includes boxlike partitions (§3.4), the textpart divisions of your edition must be mandatorily replicated in your translation (with the same attributes and, if applicable, <head> elements)

- pagelike partitions (§3.5), if present, may be replicated or omitted from the translation as you see fit

- for replication, use the same element with the same attributes as that used in your edition, and include the <head> elements if applicable

- gridlike partitions (§3.6) and quasi-partitions (§3.3) including forme work (§3.3.5) shall not be replicated in the translation

- line beginnings shall not be replicated, but line numbers may be indicated as per §9.2.6 below

- block-level containers in the original (i.e. <p>, <ab> and <lg>) shall be normally replicated as a corresponding paragraph (<p> element) in the translation, but feel free to use a smaller or larger number of <p> elements at your discretion

- for paragraphs translating verse, add the attribute @rend with the value "stanza" to the <p> element

- should your translation of a stanza consist of verselike lines that will need to be displayed as separate typographic lines, you may wrap each of these in an <l> element within the <p> element corresponding to a stanza

### 9.2.6. Indicating correspondence to the original

- to indicate how block-level translation elements correspond to parts of the original text, you should normally add the attribute @n to each <p> element in the translation as reference to either a line number or a stanza number in the original

- for short inscriptions best translated as a single paragraph of prose, such referencing may be omitted

- to indicate a line or stanza in the original, simply use the value of @n from the appropriate <lb/> or <lg> element of the original

- in <p> elements translating verse (and thus carrying the attribute @rend="stanza"), this @n will be interpreted as a stanza number, while in <p> elements translating prose (and thus without the @rend attribute) it will be interpreted as a line number

- to refer to a range of lines or stanzas, use a hyphen between two values, e.g.

- <p n="1-3"> a paragraph translating prose in lines 1 to 3

- <p rend="stanza" n="8-9"> a single paragraph translating stanzas 8 and 9 together

- to refer to non-contiguous lines or stanzas, use a comma and a space between two values, e.g.

- <p n="1, 3"> a paragraph translating prose from lines 1 and 3 (but not 2)

- <p rend="stanza" n="8, 10"> a paragraph translating (parts of) stanzas 8 and 10 together

- the above indicators are for human readers and are not meant to be machine-actionable, therefore

- feel free to refer to larger ranges of lines or to several stanzas for passages best translated in larger chunks

- feel free to refer to the same line or stanza number in several translation elements, each of which includes parts of a single line or stanza of the original

- should the intelligibility of the translation demand it, feel free to translate items in a different order than that in which they appear in the original
<caption>Example 9.2.6.A: numbering in translation to indicate correspondence to the original</caption>

<div type="translation" xml:lang="eng">
  <p n="1-9">Hail! From the victorious [...]</p>
  <p n="9-15">There is this village [...]</p>
  <p n="15-17">In the first year [...]</p>
  <p rend="stanza" n="1">By numerous kings, many times land has been given. Whoever holds land at a given moment, to him does the fruit then belong.</p>
</div>

9.2.7. Phrase-level markup in translations

- in addition to plain English (or other modern-language) text, the translation division may contain phrase-level markup of the following kinds

- globally permitted miscellaneous markup as per §10

- some additional encoding solutions available only in translations, as outlined in the subsections following this one (§9.2.12 to §9.2.11)

- no other markup should appear in translations,<fnref n="44" /> and this applies also to the use of non-XML markup such as brackets, asterisks and other signs

<caption>Example 9.2.7.A: phrase-level markup in translation</caption>

<div type="translation" xml:lang="eng">
  <p>Indeed <supplied reason="explanation"><foreign>asti</foreign></supplied>, with respect to vendible properties in this division, the sale of <supplied reason="explanation">a <foreign>kulyavāpa</foreign> of</supplied> waste land that is without revenue charges and yields no tax, to be enjoyed in perpetuity in accordance with the law on permanent endowments, is customary for one hundred <foreign>kārṣāpaṇa</foreign>s. And no conflict of interest <supplied reason="explanation"><foreign>virodha</foreign></supplied> whatsoever <supplied reason="subaudible">will result</supplied> through its sale: <supplied reason="subaudible">on the contrary,</supplied> for His Majesty <supplied reason="subaudible">there will be</supplied> increase of wealth and attainment of one sixth of the merit.</p>
</div>

9.2.8. Foreign words

- words in a language other than the language of the translation must be tagged as `<foreign>` as per §10.3.3

- there are no special rules or methods applicable to translations, and this subsection only exists to make it explicit that this encoding can and must be used in translations

- as per §10.3.3, words in the inscription's language or Sanskrit do not require the attribute @xml:lang, including

- such words appearing in the text without any other markup, e.g.

- technical terms (e.g. one `<foreign>kulyavāpa</foreign>` of land)

- unintelligible text that is not translated as per §9.2.12

- such words inserted into the translation as explanation, as per §9.2.9

- as per §10.3.3, when words in another modern language are encoded as `<foreign>`, the attribute @xml:lang must always be present

9.2.9. Additions to the translation

- words in the translation that do not correspond to anything in the extant original text shall be tagged as `<supplied>`, as outlined below

- in each of these cases, `@cert="low"` may be added to this element to indicate tentativeness; see §9.2.10 below

- words added to the translation for the sake of target language syntax shall be marked up as `<supplied reason="subaudible">`

<footnote n="44">⁴⁴ If you feel your translation needs any further markup, please consult the authors of the Guide and the project's XML-TEI Data Manager.</footnote>
- this markup method is to be used for words that, though not explicitly present in the original, need to be read to get a proper translated sentence; see the next point about additions that are not required for completing the syntax in the target language

- e.g. <p>He was generous to his subjects and <supplied reason="subaudible">therefore</supplied> loved <supplied reason="subaudible">by them</supplied> ... </p>

- we foresee that this markup will be displayed as square brackets, e.g. "He was generous to his subjects and [therefore] loved [by them]."

- do not clutter a translation with such tags unless you find that such accuracy is essential: depending on how free or literal your translation is, you may prefer to avoid the use of this element

- segments of translation corresponding to text **restored by the editor in the original** shall be indicated in the translation using the same elements as in the edition, namely

- lost text, e.g. The truest of <supplied reason="lost">kings</supplied>... corresponding to <supplied reason="lost">nṛpa</supplied>-sattamaḥ in the edition

- text omitted by the scribe, e.g. The truest of <supplied reason="omitted">kings</supplied>... corresponding to <supplied reason="omitted">nṛpa</supplied>-sattamaḥ in the edition

- use the same encoding for concepts presumed to have been present in a larger lacuna of the text, even if they have not been restored in the edition (because there is no way to know what synonym was used or where a word was located within a lacuna)

- e.g. The village named <supplied reason="lost">was granted</supplied>... for ...nāmo grāmaḥ <gap reason="lost" quantity="12" unit="character"/>

- note that in this case you will have to use @reason="lost" in the <supplied> element even if the corresponding <gap> element in the edition has @reason="illegible" (§5.1)

- such restorations will usually not cover the whole of a lacuna and will thus need to be used in conjunction with lacuna markup as per §9.2.12

- we foresee that this markup will be displayed as square brackets, without distinction from words added for the sake of target language syntax, e.g. "The truest of [kings]..."

- do not clutter a translation with such tags unless you find that such accuracy is essential: as a rule, lost or omitted text shorter than a full word and confidently restored by you in the edition should not be marked up as supplied in the translation

- words implied by the context and **added to the translation for the sake of clarification or disambiguation** shall be marked up as <supplied reason="explanation"/>

- this markup method is to be used for supplementary words that are not required for completing the syntax in the target language or may even interrupt the sentence; see the previous point about words that need to be read to get a proper translated sentence

- e.g. <p>... devotion to <supplied reason="explanation">Viṣṇu</supplied> the bearer of the discus and the mace ... </p>

- we foresee that this markup will be displayed as parentheses, e.g. "... devotion to (Viṣṇu) the bearer of the discus and the mace ..."

- to **add words of the original** (or equivalents in Sanskrit or another applicable major language) next to translated words, in order to make your translation more transparent, enclose these in <supplied reason="explanation"/> as above, and within that tag, use <foreign>

- e.g. <p>Homage to that thousand-headed Person <supplied reason="explanation"><foreign>puruṣa</foreign></supplied> ... </p>

- foreseeably displayed as "Homage to that thousand-headed Person (puruṣa)"

- as per §10.3.3, the attribute @xml:lang need not be used in this case

### 9.2.10. Indicating uncertainty

- to indicate the uncertainty or tentativeness of a translated word or phrase, wrap a segment of translation in <seg cert="low">
- e.g. `<p>Out of the hundred and <seg cert="low">twenty</seg> shares comprising this village ... </p>

- use this method regardless of whether the tentativeness of your translation stems from the condition of the original (e.g. partly or wholly unclear, illegible or restored) or from the obscurity of its language

- this will probably be displayed wrapped in a pair of question marks (inverted and regular), e.g. In the great and renowned city ¿named? two ¿times?> five ...

- to indicate the uncertainty or tentativeness of a word added to the translation, add @cert="low" to any <supplied> element used as per §9.2.9 above

- e.g. <p>On this day he <supplied reason="explanation" cert="low">Viṣṇuvardhana</supplied> donated ... </p>

- this will be displayed with a ? added inside the brackets corresponding to @reason as above, e.g. On this day he (Viṣṇuvardhana?) donated ...

### 9.2.11. Indicating incorrect or unexpected text

- the element <sic> may be used in translations in either of the following circumstances

- in your own translation, you may deploy <sic> to highlight words or stretches of translation corresponding to an original that seems inappropriate in context

- when reproducing a published translation, <sic> may be used to highlight points where the original translator's usage or transliteration practice is wrong or unexpected

### 9.2.12. Gaps in the translation

- **lacunae** in the original shall be indicated in the translation using the same elements as in the edition, namely, `<gap reason="lost"/>` or `<gap reason="illegible"/>`, distinguished as per §5.4.2

- normally, these elements may be used in a translation without any further attributes

- gaps encoded in this way will probably be displayed as [...] (regardless of the value of @reason) and will be sufficient for most lacunae in most translations

- however, when you deem it essential to present accurate details of a lacuna in the translated text, you may optionally use the attributes @unit, @quantity and @precision as set out in §5.4.3 and §5.4.6, with the following additional options:

- fractional numbers (decimal fractions) for @quantity are permitted in this case, even though they cannot be used in the edition

- @unit may be "line" even if a multiline lacuna is represented in the edition as a series of inline lacunae

- such gaps will probably be displayed as text, e.g.

- `<gap reason="lost" quantity="3.5" unit="line"/>` displayed as [3.5 lines lost]

- `<gap reason="illegible" quantity="10" unit="character" precision="low"/>` displayed as [ca. 10 characters illegible]

- no other methods of lacuna markup shall be used in translations, i.e. avoid the use of @extent and the encoding of sub-akṣara lacunae

- when a segment of extant text is not translated because it is not intelligible, this shall be indicated in the following way

- mandatorily create `<gap reason="ellipsis"/>` without any further attributes to indicate the place in the translation where text is skipped

- such a gap element in a translation will be displayed as ...

- after `<gap reason="ellipsis"/>`, as a rule replicate the unintelligible text wrapped in the element `<foreign>` which is in turn wrapped in `<supplied reason="explanation"/>`

- markup pertaining to the replicated text may be used as per §10.1

- if the unintelligible text is very long (e.g. an entire paragraph), you may optionally forego replicating it; in this case the `<note>` element mentioned in the next point is mandatory

- optionally, after the <supplied> element, add a <note> with any explanation you deem appropriate

- when a segment of extant text is not translated for any other reason (for instance because it is considered too trivial to translate), this shall be indicated in the following way
- mandatorily create `<gap reason="ellipsis"/>` without any further attributes to indicate the place in the translation where text is skipped

- such a gap element in a translation will be displayed as ... (in the same way as for unintelligible text, but not followed by the text in the original language)

- preferably, after the `<supplied>` element, add a `<note>` with an explanation of why the text has not been translated

### 9.2.13. Blank space in the translation

- in general, spaces encoded in the edition (§4.3) should not be preserved in the translation

- however, spaces left blank in the original with the intent of subsequent filling (*vacat*, §4.3.3) may be preserved in the translation if you feel that this serves a useful purpose

- in this case, use the `<space/>` element exactly as in the edition division, e.g. `<space type="vacat" quantity="3" unit="character"/>`

- this will probably be displayed as text in square brackets, e.g. [*space of ca. 3 characters left blank*]

### 9.2.14. Indicating bitextuality

- to **indicate bitextuality** (*śleśa*) in your translation, select one translation of the double entendre as the primary or more literal one (to leave without markup), and wrap the translation of the secondary or less literal meaning in `<seg rend="pun"/>`

- this will be displayed as {} curly braces around the segment thus tagged

- this encoding will not be machine-actionable and will in many cases leave some ambiguity that will have to be resolved by the reader, but we do not perceive a need for a more rigorous (and thus more complex) encoding scheme

**Example 9.2.14.A: translation with bitextual words dispersed across a stretch of text**

... who make the ocean heave `<seg rend="pun">`the treasured water burst forth</seg>` with the powerful wind `<seg rend="pun">`vital breath</seg>` arising from the lute `<seg rend="pun">`ritual procedure</seg>` ...

> display: ... who make the ocean heave {the treasured water burst forth} with the powerful wind {vital breath} arising from the lute {ritual procedure} ...

**Example 9.2.14.B: translation with bitextual interpretation integrated into one sentence**

May this reservoir of water, which is eternally festive because it is surrounded by the bodies of many riverlike women, never become exhausted just as the great ocean `<seg rend="pun">`which eternally revels in bodily union with many women who are rivers, yet never contracts the clap</seg>`.

> display: May this reservoir of water, which is eternally festive because it is surrounded by the bodies of many riverlike women, never become exhausted just as the great ocean {which eternally revels in bodily union with many women who are rivers, yet never contracts the clap}.

## 9.3. The Commentary

### 9.3.1. Overview

- the commentary to your text shall be wrapped in `<div type="commentary"/>`

- this division follows the edition division containing the translation(s)

- the contents of the commentary division shall be freeform discursive English text, wrapped in one or more `<p>` elements, which may include globally permitted miscellaneous markup (§10), but no other markup including non-XML markup such as brackets, asterisks and other signs

- possible topics of the commentary include:

- discussion of the readings chosen for your edition, along with any details that could not be encoded within the edition or the apparatus, including

- alternative readings too nebulous to encode in the edition

- uncertainty about the location of a line break with respect to restored text (§3.2.3)
- discussion of metrical phenomena and uncertainty about verse metres

- discussion of the interpretation as reflected in your translation and any alternatives

- literal translations of phrases more elegantly translated in your translation, but for this reason, possibly obscure

- pointing out parallel passages in other sources, especially if these are used as the basis of restoration in the present text

- note that palaeographic observations should not go into the commentary; rather,

- those pertaining to the inscription as a whole belong in the <handDesc> section of the TEI header, see §11.2.1

- those pertaining to specific loci should be recorded in the apparatus as notes (§9.1.7)

### 9.3.2. Structure of the commentary and correspondence to the text

- commentarial paragraphs will not be linked in a machine-actionable way to the text

- as in any written commentary, refer to lines, stanzas, *pādas* or particular words/phrases as and when necessary, spelling out such references in a clear human-readable manner

- however, should you wish to create a structured commentary with entries referred to particular sections of the text, you may employ the human-readable linking method described for translations in §9.2.6 above, i.e.

- add to any <p> element in the commentary the attribute @n, corresponding to a line number, a range of line numbers, or a set of non-contiguous line numbers in the text

- add to any <p> element in the commentary the attribute @rend with the value "stanza" and the attribute @n, corresponding to a stanza number, a range of stanza numbers, or a set of non-contiguous stanza numbers in the text

- see §9.2.6 for details and examples of this method

- **textpart divisions** (<div type="textpart">>) may be created to break up a long commentary into **sections** (chapters), but there is no obligation to reproduce the textparts of the edition in the commentary and no facility of linking such divisions to any divisions of the text

- use any arbitrary number of textpart divs

- keeping in mind the requirement of tessellation (§3.4.2), i.e. that if a textpart division is present within your commentary, then all your commentarial text must be contained within textpart divisions

- always add the attribute @n to number commentarial textparts, using plain Arabic numerals as values, which shall only be used for internal reference if at all

- always add a header to commentarial textparts, by creating the element <head> (containing free text to be displayed as a heading) as the first item within each textpart division

## 9.4. The Bibliography

### 9.4.1. Overview

- the project will maintain a master bibliography in Zotero

- consult the ZG about adding entries to this bibliography, and if you do not yet have access to the group Library DHARMA, ask for it

- in this system, each reference will be known by a unique internal identifier in the form of the Short Title assigned to any Zotero item

- the bibliography division of an XML document in our project serves a twofold purpose

- to present what specialists of Greek and Roman epigraphy call the “epigraphic lemma”, i.e. a paragraph which explains the history of research leading up to the edition encoded in your file

- to collect all bibliographic references pertaining to the inscription edited in your document and the artefact bearing it

- the XML shall be created within <div type="bibliography">>

- this division is the last element within the <body> of your document, appearing after the commentary
### 9.4.2. The structured bibliography

- the structured bibliography will be divided in our editions into two sections, a primary and a secondary bibliography

- the primary bibliography shall include only independent integral editions

- the secondary bibliography shall contain all other publications, such as

- re-publications of previous editions (without new insights)

- reports (ARIE, etc.)

- partial readings or translations

- descriptions/discussions of the inscription's content, the support, specific readings, etc.

- the encoding of these two bibliographies consists of the containers `<listBibl type="primary"/>` and `<listBibl type="secondary"/>`,

- and within each of these, one `<bibl>` element for each bibliographic entry, encoding a regular citation as per §10.4.5

- these lists will be populated automatically from your metadata spreadsheets, but will require your attention on the following points:

- check them and correct where necessary

- as far as possible, arrange them in an alphabetical order

### 9.4.3. Bibliographic sigla

- if your edition includes an apparatus that cites readings from previous editors, the citations of those editions in your bibliography must include a manually encoded siglum (an abbreviation by which they will be shown in the apparatus)

- this applies regardless of whether the citation is in your primary bibliography or the secondary one

- if the citation appears in more than one place within your file, it is sufficient to encode a siglum on one of these appearances

- encode the siglum as the attribute `@n` on the relevant `<bibl>` item

- as a rule, the siglum shall consist of all the initials of the author of the edition (in the order applicable to the language of the publication), but you may deviate from this in the following cases

- should there happen to be two cited editions by the same author or by two authors with identical initials, in order to eliminate ambiguity you may extend the siglum with a number (e.g., referring to the respective years of publication) or with a full name

- should the author have a multipartite name that would lead to a siglum of more than three letters, or should a cited edition be the product of several authors, you may reduce the siglum to the initials of the surnames

<caption>Example 9.4.3.A: bibliographic citation with a siglum, within the primary bibliography</caption>

```xml
<bibl n="EH">
  <ptr target="bib:Hultzsch1913-1914_01"/>
  <citedRange unit="page">225-226</citedRange>
  <citedRange unit="item">B</citedRange>
</bibl>
```

### 9.4.4. The epigraphic lemma

- in addition to the structured bibliographies, you will need to create an epigraphic lemma

- this shall take the form of a single `<p>` element located within the bibliography division and before the primary bibliographic list, containing freeform discursive English text

- your freeform text should contain bibliographic citations (encoded as per §10.4.5) for entries pertaining to the study of the text and its translation

- these can be copied and pasted from the structured bibliography, then edited as needed and expanded with explanatory text

- the epigraphical lemma should mostly consist of items of the primary bibliography, but early reports, facsimiles and translations without an accompanying edition may also be mentioned here
- it is recommended that you present the principal publications in ascending chronological order up to the one that most immediately precedes the present edition

- each item referred to should be accompanied by brief information on why each bibliographic item is relevant and on whether it includes an edition, a facsimile or a translation of the text

- these citations should include page ranges only if the publication is not entirely or mostly about the text being edited

- for instance, when citing a journal article primarily concerned with the text, refer to the article as a whole and not specifically to the page range containing the edited text

- if it is known from a publication, or if you are the author of the present edition, include a brief statement of the principal visual documentation that has been used

- note that you must identify the author of the present edition in the epigraphic lemma, even if no previous publication exists

- the same author must also be identified in <respStmt>, see §11.1.2

### 9.4.5. Full markup example for the bibliography

<caption>Example 9.4.5.A: the bibliography division</caption>

```html
<div type="bibliography">
  <p>First edited by Cohen Stuart <bibl rend="omitname"><ptr
    target="bib:CohenStuart1875_01"/><citedRange unit="page">23</citedRange><citedRange
    unit="item">XIII</citedRange></bibl> with a lithographic reproduction in the accompanying volume
    of plates <bibl><ptr target="bib:Huart+Hooiberg1875_01"/></bibl>; edited again by Boechari <bibl
    rend="omitname"><ptr target="bib:Boechari1985-1986_01"/><citedRange unit="page">53</citedRange>
    <citedRange unit="item">E.16</citedRange></bibl>; re-edited here by Arlo Griffiths from the
    Leiden estampage of the plate.
  </p>
  <listBibl type="primary">
    <bibl n="B">
      <ptr target="bib:Boechari1985-1986_01"/>
      <citedRange unit="page">53</citedRange>
      <citedRange unit="item">E.16</citedRange>
    </bibl>
    <bibl n="CS">
      <ptr target="bib:CohenStuart1875_01"/>
      <citedRange unit="page">23</citedRange>
      <citedRange unit="item">XIII</citedRange>
    </bibl>
    <bibl n="HH">
      <ptr target="bib:Huart+Hooiberg1875_01"/>
    </bibl>
  </listBibl>
  <listBibl type="secondary">
    <bibl><ptr target="bib:NBG"/><date>1870</date><citedRange
      unit="volume">8</citedRange><citedRange unit="page">72, 78</citedRange></bibl>
    <bibl><ptr target="bib:Verbeek1891_01"/><citedRange unit="page">149-150</citedRange>
      <citedRange unit="item">276</citedRange></bibl>
    <bibl><ptr target="bib:Damais1970_01"/><citedRange unit="page">48</citedRange><citedRange
      unit="item">86</citedRange><citedRange unit="note">13</citedRange></bibl>
  </listBibl>
</div>
```
# 10. Globally Available Markup Outside the Edition

## 10.1. Editorial Markup Outside the Edition

- as a rule, the XML elements pertaining to the text edition (§2 to §7) should be avoided outside the edition division of your XML file, except as explicitly endorsed in the following sections of §10 and, for specific divisions of the XML file (viz. the apparatus and the translation), in the relevant sections of §9

- when citing something from the text edited in your file or from another text, it is generally recommended that you omit editorial markup from that citation

- however, sometimes you may deem it essential to cite a diplomatic reading with all its intricacies, particularly

- in a note or commentary section discussing the editorial difficulties connected to a reading, or

- in a translation when replicating an unintelligible stretch of text (§9.2.12),

- in such cases, you may use the following elements of editorial markup outside the edition division, limited to features whose replication is deemed essential in the context (i.e. without an obligation to replicate all editorial markup)

- empty elements representing transition points (`<lb/>`, `<pb/>` and `<milestone/>` of any kind; §3.2, §3.5 and §3.6)

- to reduce code clutter, feel free to remove all attributes from these elements

- any markup pertaining to the originally inscribed text (§4)

- any markup pertaining to physical condition and reading difficulties (§5)

- any markup pertaining to modern editorial intervention (§5.5)

- any markup pertaining to visual features (§7.5)

- when citing primary text with editorial markup as above, keep in mind that

- tags for block-level containers (`<p>`, `<ab>`, `<lg>` and `<l>`) must not be included in citations

- foreign-language citations within a stretch of modern-language text must always be tagged as `<foreign>` (§10.3.3), so all markup pertaining to the citation must be within these tags

- XML elements must always have a start-tag and an end-tag, so when copying and pasting from your edition, make sure that these tags are present in your citation even if one end of the segment tagged in your edition is outside the copied string, i.e.

- add the start-tag for retained markup commencing before and ending inside your citation

- add the end-tag for retained markup commencing inside your citation and ending after it

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

## 10.2. Formatting

### 10.2.1. Character formatting

- given the principle of conceptual markup (§1.3.4), it will not normally be necessary for you to apply character formatting as such: all essential formatting will be handled globally through external stylesheets and governed by the XML tags you create,

- so for instance instead of italicising foreign words and titles, you tag them as `<foreign>`<fnref n="45" /> or `<title>` respectively

- that said, you may occasionally find it useful to encode simple formatting instructions without any specific semantic classification

- for this purpose, only outside the edition<fnref n="46" /> and mainly within the commentary division, you may use the element `<hi>` (signifying typographic highlighting) with the attribute `@rend` taking on one of the following values:

- "italic"

- "bold"

<footnote n="45">⁴⁵ Note that this tag is also applicable to short segments of text meaningless in and of themselves, see §10.3.3.</footnote>

<footnote n="46">⁴⁶ See §7.5.1 about the use of `<hi>` in the edition.</footnote>
- "subscript"

- "superscript"

- in addition to the above, the use of `<hi rend="grantha">` is permitted outside the edition in text cited from the inscription (or another primary text), for the purpose of highlighting characters originally written in Grantha

- note that this does not replace the `<foreign>` tag (§10.3.3) required for such text outside the edition

### 10.2.2. Lists

- should you need to format some text as a structured list, the following markup may be used in a commentary or in a translation (but not in any other section of your document)

- within the `<p>` element enclosing your text, create the container `<list>`

- without any attributes to produce a plain list (displayed with each item in a new line and indented)

- or with the attribute `rend` with the values `bulleted` or `numbered` for these list styles

- within `<list>`, create an `<item>` element as a container for each list item

- to create a multi-level list, `<list>` elements may be nested in one another, but this is not recommended (especially not for numbered lists); please contact the authors and the TEI manager if you feel this is essential for you

## 10.3. Encoding Language

### 10.3.1. Tagging language with `@xml:lang`

- whenever encoding a language with the attribute `@xml:lang`, we shall use the **language codes** defined by the ISO standard 639-3⁴⁷

- the codes relevant to our project are listed in Appendix D of this guide

- **script codes** defined by ISO 15924⁴⁸ are often conjoined to language codes (using a hyphen between the two), but in our practice, this shall be limited to the following

- the language code of text originally written in an Indic script and edited in Romanised transliteration shall mandatorily be suffixed with “-Latn”

- since the languages we work with are always transliterated throughout our editions, apparatuses and commentaries, you will thus in most cases have to suffix “-Latn” to your language codes

- language tags without a script code will by default be assumed to be in a native script associated with the language in a given region and time period

- this is applicable to modern languages as well as to the languages of our corpus

- specific details about the native script(s) used in an inscription shall be recorded in our TEI headers

- bilingual (or multilingual) inscriptions using different scripts for different languages require no explicit indication of the scripts in the edition, provided that the TEI headers clearly state what script is used for which language

- should an inscription use more than one script for one language, script changes (§7.5.4) shall be encoded as applicable

- the subsections below concern language encoding outside the edition division

- see §7.2 for specific instructions on language encoding within the edition

### 10.3.2. Tagging language in pre-existing containers

- the `<TEI>` container (§1.4) of the entire XML document specifies English as the language of the document, and this is understood to apply to all child elements unless otherwise specified

- when a **structural unit** of the document is in another language, the attribute `@xml:lang` must be added to the start-tag of the corresponding structural element to specify the language:

- the edition division must always be set to the language of the original text (§1.4)

- translation divisions must explicitly indicate their language (§9.2.1) even if it is English

<footnote n="47">⁴⁷ https://iso639-3.sil.org/</footnote>

<footnote n="48">⁴⁸ https://en.wikipedia.org/wiki/ISO_15924</footnote>
- similarly, smaller structural units (e.g. `<note>` or `<p>`) may be set to a particular language as and when applicable

### 10.3.3. Tagging foreign languages outside the edition

- this subsection concerns short stretches of a language different from that of the surrounding English (or other modern-language) text (for the sake of simplicity referred to here as a "foreign" language)

- see §7.2 about tagging language within the edition

- stretches of foreign language that coincide with an already existing XML container should be handled as per §10.3.2 above

- text in a foreign language shall be wrapped in the element `<foreign>`, and will be displayed in italics

- text tagged as `<foreign>` outside an edition need not always carry the attribute `@xml:lang`

- `@xml:lang` is not required (and, to reduce code clutter, counter-recommended) for text in the language of a monolingual inscription (i.e. that encoded for the edition division), including

- citations from the inscription in a translation, commentary or note (including apparatus notes), e.g. *Two <foreign>kulyavāpa</foreign>s of land*

- strings of text that are not meaningful in and of themselves, such as

- single (transliterated) characters mentioned in a palaeographic description, e.g. The scribe tends to use `<foreign>nh</foreign>` instead of `<foreign>nh</foreign>

- morphological components or unintelligible segments mentioned in a discussion, e.g. The suffix `<foreign>-vat</foreign>

- `@xml:lang` is optional (to be used or avoided on a case-by-case basis)

- for technical terms in Sanskrit or another major language applicable to the inscription's context, e.g. *a <foreign>bahuvrīhi</foreign> compound*

- for text in any language of a multilingual inscription (i.e. those encoded for certain textpart divisions or smaller sections of the edition)

- `@xml:lang` (with the appropriate language and script code) is mandatory

- for words or phrases in a modern language other than that of the surrounding text (e.g. a French quotation in an English commentary)

- however, do not overdo the tagging of modern foreign words: e.g. French or Latin terms commonly used in English should not be tagged at all

## 10.4. Notes, Quotations and References

### 10.4.1. Encoding notes

- notes may be used in the apparatus, the translation and the commentary

- it is strongly recommended that you add no notes to any other part of your document; if you feel an overwhelming need to do so, please first discuss this with the authors of this Guide and the XML-TEI data manager

- to create a note, add the element `<note>` at the point where the note should be anchored

- notes may be rendered as footnotes, endnotes or tooltips (attached to a note anchor on the spot), depending on display decisions which will be made later

- `<note>` elements must always be within the structural containers applicable to the division, i.e. within `<p>` in a translation or commentary, and within `<app>` in an apparatus

- in freeform text (i.e. in a translation or commentary), place the `<note>` element after any adjacent punctuation mark, not before it

- if the author of a note is not the same as the author encoded in the `@resp` or `@source` attribute of the note's ancestor element (e.g. the translation division), then authorship must be encoded for the note as follows:

- using `@resp` (§10.6.1) if the note is by you and/or another project member

- using `@source` (§10.6.2) if the note is adopted verbatim from a publication
- paraphrased notes are in this respect regarded as the product of the person doing the paraphrasing; the author of the original note shall be credited by including a regular citation (§10.4.5) in the paraphrase or, if the reference is obvious from the context, simply by referring to the original author by name

- the **content of notes** shall be freeform text, preferably consisting of complete sentences in English, starting with a capital letter and ending with punctuation

- notes may contain any phrase-level markup permitted in freeform text, including in particular bibliographic citations, which should be added wherever you refer to a published opinion

- it is recommended that you keep your notes short, but should you find it absolutely necessary, the contents of notes may be structured into paragraphs by creating `<p>` elements within `<note>`

- in this case, the entirety of your note text should be contained in `<p>` elements

### 10.4.2. Encoding titles

- outside the edition division (e.g. in notes, commentary, etc.), any titles you mention shall be tagged with the element `<title>`

- titles to be tagged in this way

- include non-epigraphic primary sources (literary texts), e.g. <title>Harivaṁśa</title>

- include secondary sources (technical literature, where you mention a title outside a citation encoded as per §10.4.5), regardless of whether the title is cited

- in full, e.g. <title>Early History of the Deccan</title>

- in abbreviated form, e.g. <title>Mahâbodhi</title> for the title Mahâbodhi, or the great Buddhist temple under the Bodhi tree at Buddha-Gaya, or

- as a widely known acronym, e.g. <title>OJED</title> for the title Old Javanese-English dictionary

- do not include the titles of inscriptions (in secondary literature or the DHARMABase), which are to be encoded as per §10.4.6

- by default, all titles tagged in this way will be displayed in italics; when this is not desired, do the following

- for titles of chapters (e.g. in a multi-author book) and articles (e.g. in a journal)

- add the attribute `@level` with the value `"a"` (for "analytic")

- e.g. <title level="a">Grants from Valabhî</title>

- titles tagged in this way will be displayed in regular type, but with quote marks added around them

- for any titles that you wish to display without italics and that are not chapters or articles

- add the attribute `@rend` with the value `"plain"`

- titles tagged in this way will be displayed without any typographic distinction from the surrounding text

### 10.4.3. Quotations without an encoded reference

- **quoted text not attributed to a published source** shall be wrapped in the element `<q>`

- do not add quotation marks to the text, as these will be automatically produced in display in the correct form

- however, to exercise more control over the type of quote marks displayed, you may choose to omit the tag and add marks manually

- in this case take care to use the desired characters ("...." "..." '...' «...») rather than generic typewriter quotes or apostrophes

- this encoding method applies primarily to quotations in the same language as the surrounding text, such as

- translations of phrases or sentences of the edited text or another text (appearing in a commentary or apparatus)

- your translation of text quoted as direct speech (e.g. with *iti*) in an inscription (within the translation)

- if you use `<q>` to quote text in a modern language other than that of the surrounding text, use `@xml:lang` on the `<q>` element, as per §10.3.2