A Proposal for Revisions to choice, app, and model.pPartEdit
This document proposes a series of related revisions affecting
- choice
- model.choicePart
- model.listLike
- model.pPartTranscriptional
<choice>
Description
Currently our description of <choice> in Appendix B claims that the element “groups a number of alternative encodings for the same point in a text”; later, it suggests that <app> is “a specialized version of <choice> for encoding multiple witnesses of a single work.”
In actual fact, however, neither claim is fully accurate.
First of all, <choice> is far more specialised than its description suggests. The content model for <choice> limits its content to itself and members of model.choicePart (<abbr> <corr> <expan> <orig> <reg> <seg> <sic> <unclear>). These elements, in turn are a subset of those found in model.pPartEditorial (<abbr> <choice> <expan>) and model.pPartTranscriptional (<add> <app> <corr> <damage> <del> <orig> <reg> <restore> <sic> <supplied> <unclear>).
What this means is that the use of <choice> in the following example is illegal, even though the text clearly represents “a number of alternative encodings for the same point in a text”[1]:
<choice>
<div>
<p>The Text Encoding Initiative is a consortium responsible for maintaining the TEI guidelines. The TEI is currently hosted by four universities and directed by a board. Technical work is carried out by an elected council, specially appointed workgroups, and two editors.</p>
</div>
<div>
<p>The Text Encoding Initiative is a consortium responsible for maintaining the TEI guidelines.</p>
<p>The TEI is currently hosted by four universities and directed by a board. Technical work is carried out by an elected council, specially appointed workgroups, and two editors.</p>
</div>
</choice>
In fact, as the narrative description and content model of the element in §3.4 makes clear, <choice> is actually intended “to represent simultaneously a text in its ‘original’ uncorrected and unaltered form, and also one or more ‘edited’ forms.” All the members of model.choicePart except <unclear> and the generic phrase element <seg> belong to the so-called Janus tags. Janus tags are elements like <abbr> and <expan> that represent “original” and “mediated” textual states and are logical and exclusive alternates to each other. In earlier versions of the Guidelines, these elements used attributes that indicated the “alternate” state for the text: <abbr> had an expan attribute that could be used to indicate the expanded form of the abbreviation, <expan> had an abbr attribute that could be used to indicate the abbreviated form. This content model suggests that the narrative description of the element is actually the correct form: <choice> is a highly specialised element used to group original and editorial states of the same span of text.
The claim that <app> is a specialised form of <choice> is also not true given this restrictive content model. <app> associates readings with each other (and optionally with lemmas, which are just a semantically differentiated kind of reading). While it is true that readings exist as alternates to each other at specific points in the text, the difference is neither primarily one of original vs. editorial states (since all readings are by definition “original” to the witness in which they appear), nor one of markup: the point of an apparatus is not that the encoding of the readings is different, but that their content is.
Given the above, it seems to me that we should rewrite our definition of choice in Appendix B to match that in §3.4:
<choice>groups alternative encodings representing ‘original’ (missing, uncorrected and/or unaltered) and one or more ‘edited’ (corrected, supplied and/or emended) forms for the same point in a text.
<gap>, <damage>, <unclear>, <supplied>, and <del>
As noted above, with the exception of <unclear> and <seg>, <choice> can contain itself or the old “Janus tags” now found in model.pPartEditorial and model.pPartTranscriptional.
<unclear>, however, belongs to a different set of elements, the “closely allied” (see §14.2.3) <gap>, <damage>, <unclear>, <supplied>, and <del>.
These elements are like the former Janus elements in that they can be used to reflect alternate original and editorial encodings of a span of text (For examples showing that these tags can be used in this way, see §14.2.3.). They are unlike them, however, in that earlier versions of the Guidelines did not provide them with an attribute to indicate the “other” state—i.e. <gap>, <damage>, <unclear>, and <del> have never had a supplied attribute; <supplied> has never had an attribute for representing the pre-supplied state.
If we are serious about including <unclear> in the content model for <choice>, then we should also have the other members of this group of elements: <supplied> is the element the Guidelines recommend for encoding editorial suggestions for unclear text, and <damage>, <gap>, <del>, and <unclear> are used in combination with <supplied> in §§ 14.2.3-4 to create some very fine distinctions—none of which can be encoded if the parent is <choice>, however.
Given the above, it makes little sense not to add <gap>, <damage>, <supplied>, and <del> model.choicePart.
<add>
If we follow Recommendation 2, then the content model for <choice> will contain the complete contents of model.pPartEditorial and all members of model.pPartTranscriptional except <app>, <restore>, and <add>.
Of these three, <add> is perhaps the most obvious candidate for inclusion in model.choicePart. Although its does not represent an editorial state to contrast with <del>, the element is, as we note in §14.3.4, “is often associated with addition” in manuscripts and typescripts. This means that a deletion correction sequence such as the following can also be thought of as representing alternating states in the history of the text:
<l> <del type="overstrike">Inviolable</del> <add place="infralinear">Inexplicable</add> splendour of Corinthian white and gold</l>
vs (currently illegal)
<l> <choice> <del type="overstrike">Inviolable</del> <add place="infralinear">Inexplicable</add> </choice> splendour of Corinthian white and gold</l>
The main difference between this use of <del> : <add> and <sic> : <corr> is semantic: if the error identified and corrected by a modern editor, we use <sic> : <corr> within <choice>; if the deletion and addition is done in the witness itself, however, it is tagged with <del> and <add> and, currently, not allowed inside <choice>.
For this reason I see little reason not to add <add> to model.choicePart.
<restore>
<restore> is used to indicate “restoration of text to an earlier state by cancellation of an editorial or authorial marking or instruction.”
For I hate this <restore hand="#dhl" means="marginalStetNote"> <del>my</del> </restore> body
The element is thus like all the other model.pPartTranscriptional elements discussed thus far in that it encodes alternate markup reflecting alternate document states (in this case pre- and post cancellation). But it is unique in that the alternation is expressed by a parent child rather than sibling relationship: here the pre-state is contained within rather than alongside the post-state. A purist might argue that <restore> is really a shorthand method for indicating a choice as in the following (illegal) example:
For I hate this <restore hand="#dhl" means="marginalStetNote"> <choice> <del>my</del> <restore>my</restore> <choice> body
But this approach seems counter-intuitive, is less easy to understand than the current model, and causes trouble with atomisation of data, since the textual content in the pre- and post-restoration states will always be, by definition, be identical.
The <restore> content model
Even if <restore> probably should not be added to model.choicePart, its own content could be improved: currently <restore> can contain macro.paraContent (<ab> <add> <camera> <caption> <case> <cell> <colloc> <corr> <damage> <def> <del> <docEdition> <emph> <gen> <gram> <head> <hi> <hyph> <iType> <imprimatur> <l> <lang> <lbl> <mood> <number> <orig> <orth> <p> <per> <pos> <pron> <ref> <reg> <restore> <rhyme> <seg> <sic> <sound> <stress> <subc> <supplied> <syll> <tech> <title> <titlePart> <tns> <unclear> <usg> <writing>).
In actual fact, very few of these elements are really open to cancellation: <add>, <corr>, <del>, <emph>, <hi>, <sic>, and perhaps <reg> are the only elements I can see where an author/editor could mark something one way and this wish to undo this mark. All the other states can only be restored if some other markup is applied to them (i.e. you can’t restore a <head> unless you delete it first; in which case what you are really cancelling is <del>).
Restore seems to me to be a unique enough type of element that it is worth while building a class of “restorable” elements for use in its content model. The members of this class (model.restorePart) should include <add>, <corr>, <del>, <emph>, <hi>, <sic>, and perhaps <reg>.
<app>
The last member of model.pPartTranscriptional not found in model.choicePart is <app>.
This element is an odd fit in the class anyway, however. model.pPartTranscriptional is supposed to group “only phrase-level elements for simple editorial correction and transcription” (Appendix B). <app>, however, is not used for either task: while you can argue that it contains transcriptions (i.e. the content of its child <rdg>), and that it can provide evidence to support corrections (by collecting alternate/erroneous forms and sometimes associating them with corrected lemma), the element is not itself used directly to transcribe texts or indicate editorial decisions and changes.
<app> also does not belong in the sibling of model.pPartTranscriptional (model.pPartEditorial). This very small class collects “phrase-level elements for simple editorial interventions that may be useful both in transcribing and in authoring” (n in fact, only <choice>, <abbr>, and <expan>), which is something <app> manifestly is not. Since <app> is used in editorial (rather than authoring) activity, however, we could move it up to the parent class model.pPartEdit although the current definition of that class as one that “groups phrase-level elements for simple editorial correction and transcription” makes it an uneasy fit since in print sources, the apparatus is rarely if ever a phrase level element: it tends to appear as a separate division at the bottom of the page, at the back of the book, or, occasionally in a separate volume.
The answer to this problem is to remove <app> from model.pPartEdit entirely and place it in the newly expanded inter-level class model.listLike. Since an apparatus is also often called a “list of variants”, this move would not be counter-intuitive.
Simplifying model.choicePart and the model.pPartEdit family
The above has made a number of recommendations for changes to the class system, particularly involving model.choicePart, and model.pPartEdit and its children. The changes are not simply theoretically attractive, however: if we can carry them out, we can also simplify this area of the class system by getting rid of the children of model.pPartEdit: model.pPartEditorial and model.pPartTranscriptional. With the exception of <restore> in model.pPartTranscriptional and <choice> in model.pPartEditorial, all elements these classes contain after the proposed revisions above are also part of model.choiceLike. If we give up on the distinction “transcriptional/editorial elements useful for authors and editors” and “transcriptional/editorial elements useful to editors only” (a weak distinction, since <restore>—in the sense of stet, might well be considered useful to authors, even though it is currently in model.pPartTranscriptional) we could define the membership of model.pPartEdit therefore as simply <choice>, <restore>, and model.choicePart.
Moving <app> into modelListLike and changing it to an inter-level element will allow us to improve its content model as well. But that is a separate proposal.
fn1. The legal encoding for the above is as follows:
<div id="version1" excludes="version2"> <p>The Text Encoding Initiative is a consortium responsible for maintaining the TEI guidelines. The TEI is currently hosted by four universities and directed by a board. Technical work is carried out by an elected council, specially appointed workgroups, and two editors.</p> </div> <div id="version2" excludes="version1"> <p>The Text Encoding Initiative is a consortium responsible for maintaining the TEI guidelines.</p> <p>The TEI is currently hosted by four universities and directed by a board. Technical work is carried out by an elected council, specially appointed workgroups, and two editors.</p> </div>
