Letter Openers and Closers

Description of Issue 1

17As already shown in the basic example, salutations placed above or below a letter paragraph can be encoded straightforwardly with <salute>. However, in practice, salutations could appear almost everywhere in a letter. In particular, some are embedded within paragraphs, as in example 3, where a salutation phrase (“O my dear Friend, […]”) occurs at the beginning of the first paragraph and its first sentence:

18Example 4 illustrates a salutation phrase (“[…] dear Friend […]”), which is integrated in the first paragraph and moreover enclosed by parts of the first sentence (“Oh, yes, […] that pure, sincere, godly, welldoing Soul […]”):

19Another letter is quoted in example 5, where John George I, Prince of Anhalt-Dessau salutes his sister Dorothea Maria of Anhalt, Dessau in a typical and formal manner. Here, the princely salutation appears even more clearly in the middle of the first paragraph:

<p>Was wir auß bruderlichen Trewen, Ehren, Liebeß<lb/>
	vnd gueteß vermugen zuuorn, Hochgeborne Fürſtin,<lb/>
	freundtliche gelibte Frau Schweſter vnd Gefatterin,<lb/>
	Auß E. L. an Vnnß den 3i Octobris Jungſthin ann<lb/>
	Vnnß betrubtenn gethanenn Clagſchreiben, haben wir [...]</p>

Discussion of Issue 1

20To encode salutatory phrases which are part of a paragraph bears difficulties. According to the TEI Guidelines, <salute> and <p> are both block-level and can not be placed inside each other. Because <salute> is not allowed in <p>, the following encoding would not be valid:[6]

<p><salute>O my dear Friend,</salute> I remember not having received any news more delightful and charming to me, than that, which Your Letter of April […]</p>

21The encoding of inline salutations has already been discussed by the TEI community.[7] As Lou Burnard pointed out, some correspondence-related elements such as <salute> were originally designed for documents where such phrases are set-off visually from other paragraphs.[8] As such, they cover the majority of use cases, but the restrictions do not comply with deviating document structures.

Solutions to Issue 1

22(1) An editor may decide to cut off the phrase “O my dear Friend” in example 3 and to encode it as a separate <salute> above the leading paragraph:

<salute>O my dear Friend,</salute>
<p>I remember not having received any news more delightful and charming to me, than that, which Your Letter of April […]</p>

23(2) A conceivable workaround is to use the attribute @rend with value "inline" (or a similar value) in <salute> and to apply a <div> element as a wrapper.[9] For example:

<div><salute rend="inline">O my dear Friend,</salute> <p>I remember not having received […]</p></div>

24(3) We suggest to allow <salute> in <p> to enable a more flexible encoding of inline salutations. Technically <salute> should become an inter-level element able to appear between block-level elements or within them. Accordingly, <salute> should move from model.divWrapper to model.inter or an appropriate subclass. Additionally, it could be reasonable to move <salute> from the TEI module textstructure to core. We assume this change will have no backwards-compatibility implications and will lead to promising possibilities.

Description of Issue 2

25In issue 1 we discussed how salutations within paragraphs could be encoded under the condition that the <salute> tag is allowed within <p>. There still exists, however, the problem of a salutation that starts within a paragraph and continues in the <closer>, or starts within the <opener> and continues in the following paragraph.

26In example 6 below, the letter writer closes with the greeting line „In herzlicher Verehrung“ (With heartfelt admiration), which most editors would probably identify as a standard letter closer and either encode as part of <salute> or possibly <signed>. The preceding paragraph, which contains the well wishes “Möge das hereinbrechende milde Frühjahr alle Leiden von Ihnen fern halten.” (May the upcoming mild spring keep all sorrows away from you.), seems to be a less clear-cut case. While its personal message and position at the end of the letter indicate that it belongs to the formal closing section, there are a number of ways in which it can be interpreted:

• as part of the letter closer,
• as a salutation in itself within the letter body, separate from the following salutation in the closing section,
• as a salutation within the letter body that is semantically related to the salutation in the letter closer,
• as no salutation at all, at least not in the strict formal sense that allows for a <salute>-element to be applied.

27The question of whether this paragraph belongs to the letter body or letter closer (or both) cannot be resolved on the basis of layout alone, as it is not visually set apart in a different manner than the preceding paragraphs or the following greeting line, which from the layout perspective appears to be rather the final line of the letter body than the first line of a separate closing section. The decision to categorize this part of the letter therefore ultimately lies with the editor. In the following section solutions for the second and third abovementioned interpretations, namely that there is a salutation within the letter body separate from the closer, will be examined.

Discussion of Issue 2

28How structures as in example 6 should be encoded depends on one’s interpretation of both salutations: do they form a semantic unit or should they be treated as two separate sections? Taking into consideration these interpretations, there already seems to exist a possible solution within the current TEI Guidelines:

29Both salutations could be encoded within <closer>, either each in their own <salute> element or both together in one single <salute> element. If the first, the attribute @rend with values "paragraph" and "closer" (or similar values) then could be added to the <salute> elements to distinguish their original position.

<closer>
	<salute rend="paragraph">Möge das hereinbrechende milde<lb/>
	Frühjahr alle Leiden von Ihnen<lb/>
	fern halten.</salute>
<salute rend="closer">In herzlicher Verehrung</salute>
<signed>Ihr <lb/>ganz ergebenster <lb/>Ehrenberg</signed>
</closer>

30Unfortunately, this way of encoding possibly misrepresents the actual layout of the letter, and works more as a compromise under the restrictions in place. Although not explicitly stated as such, the description of the <closer>-tag strongly indicates that it is intended to be used for the encoding of visually distinctive closing sections, separate from the letter body and its paragraphs.

“<closer> groups together salutations, datelines, and similar phrases appearing as a final group at the end of a division, especially of a letter.”

(https://tei-c.org/Vault/P5/3.6.0/doc/tei-p5-doc/en/html/ref-closer.html)

31It is not necessarily wrong to apply this workaround, but can be unsatisfactory for diplomatic transcriptions. To provide the editor with the option to correctly encode the visual layout of the letter, we suggest the following solution.

Solution to Issue 2

32Given the option of placing <salute> within <p> as proposed in issue 1, the salutation in the letter body in example 6 can be encoded as such, while the salutation in the formal closing part is placed within <closer> as usual. In the rare case that the two salutations form a semantic unit and therefore should be mapped to each other, the <salute> elements can be linked by usage of the attributes @xml:id, @prev and @next.

<p>[...]
<salute>Möge das hereinbrechende milde <lb/>Frühjahr alle Leiden von Ihnen <lb/>fern halten.</salute>
</p>
<closer>
<salute>In herzlicher Verehrung</salute>
<signed>Ihr <lb/>ganz ergebenster <lb/>Ehrenberg</signed>
</closer>

Description of Issue 3

33Historical letters from the medieval and early modern period regularly contain complex salutations and signatures whose form and mode of usage have been handed down over centuries. They are similar to elements that can be found in modern letters but follow rules which are stricter with regard to their order, content, and the position in which they may appear. The range of elements typically included can be categorized in the following way:

• Intitulatio,
• an often multipart salutation, consisting of a formal salutation and possibly a family salutation,
• a provision of services,
• a blessing,
• the titles of nobility or profession.

34In a letter, these different kinds of salutations, reverences, and signatures can be formally distinguished, for example by paragraphs or indentations. However, they may also be merged into other textual parts (e.g. sentences) which themselves contain information beyond those components.

35As an illustration of the types listed above, two extracts from letters are included below, in which these elements can be determined as follows:

<p>Was wir auß bruderlichen Trewen, Ehren, Liebeß<lb/>
vnd gueteß vermugen zuuorn, Hochgeborne Fürſtin,<lb/>
freundtliche gelibte Frau Schweſter vnd Gefatterin,<lb/>
Auß E. L. an Vnnß den 3i Octobris Jungſthin ann<lb/>
Vnnß betrubtenn gethanenn Clagſchreiben, haben wir [...]</p>

• Provision of services: “Was wir auß bruderlichen Trewen, Ehren, Liebeß vnd gueteß vermugen zuuorn,”
• Formal salutation: “Hochgeborne Fürſtin,”
• Family salutation: “freundtliche gelibte Frau Schweſter vnd Gefatterin,”

<p>W. d. 22. <hi rendition="#u">Sebtemb</hi><lb/>
1679.<lb/>
Durchlauchtiger Fürst<lb/>
Gnädiger HochgeEhrter Herr Vatter<lb/>
Ew gnd gehorsamste Tochter Erkühne mich<lb/>
Aber mahl Ew gnd gnädiger Herr Vatter<lb/>
mid dießen meinen ӱbelen Stihliesierten<lb/>
Prifflein gehorsamst Auffzu warden, [...]<lb/>
und deß vegen der guden hoffung leben<lb/>
gnädigst ferlob zu bekomen, welches vier<lb/>
den mid ferlangen Ervarden verde<lb/>
und mich hier mid gehorsamst und bestens recom=<lb/>
andiere Alß,<lb/>
Ew. Gnad*.<lb/>
gehorsame und<lb/>
demütige<lb/>
Tochter<lb/>
A:D. HZS*</p>

Opener:

• Date and place: “W[eimar]. d[en]. 22. Sebtemb[er] 1679.”
• Formal salutation: “Durchlauchtiger Fürst”
• Family salutation: “Gnädiger HochgeEhrter Herr Vatter”

Closer:

• Provision of services: “und mich hier mid gehorsamst und bestens recomandiere Alß,”
• Provision of services: “Ew. Gnad*. gehorsame und demütige”
• Intitulatio
  • with family status: “Tochter”
  • Handwritten signature: “A[nna] D[orothea]”
  • Titles of nobility: “H[erzogin] Z[u] S[achsen]”

Discussion of Issue 3

36While being distinct in form and function, the different types of salutations and signatures could all be easily encoded with the help of the <salute> and <signed> tag. Problems arise when it comes to the specification of those broad categories. Identifying a special type of salutation or signature might not be central in the case of modern letters; in the investigation of earlier periods on the other hand, researchers know of and work with an established terminology that was used at the time of creation of the documents. The latin denominations of the elements listed above are historically accurate descriptions and including them in the encoding might make the transcriptions more useful for experts in the field.

37If the editor wishes to typify the salutations or signatures in the encoding, the only feasible option under the current TEI Guidelines is the application of the element <seg>, which allows for the attributes @type and @subtype. <seg> can then be utilized as child element of <salute> or <signed>, specifying them further with the help of @type:

38(1) A multipart salutation

<salute>
<seg type="provision">Was wir auß bruderlichen Trewen, Ehren, Liebeß vnd gueteß vermugen zuuorn,</seg>
<seg type="formal">Hochgeborne Fürſtin,</seg>
<seg type="family">freundtliche gelibte Frau Schweſter vnd Gefatterin,</seg>
</salute>

39(2) A multipart signature

<signed>
<seg type="family_status">Tochter</seg>
<seg type="name">A:D.</seg>
<seg type="title_of_nobility">HZS*</seg>
</signed>

40Combining <salute> and <seg> can be practical for more complex salutatory structures, and we certainly don’t discourage using both when this specific application of <seg> is consistent with editorial guidelines and the tag is not generally overused. Utilizing <signed> and <seg> in the same way in (2), however, demonstrates the possible difficulties with the approach: The structure as a whole, a so-called intitulatio, is not encoded, or just broadly encoded as a signature. To indicate its category, yet another <seg> in place of the <signed> tag would be necessary:

<seg type="intitulatio">
<seg type="family_status">Tochter</seg>
<seg type="name">A:D.</seg>
<seg type="title_of_nobility">HZS*</seg>
</seg>

41Working in this manner, an editor would end up using a great variety of typified <seg> elements for textual structures that are recognized and accounted for in the TEI tagset. Heavily using <seg> also might bear the risk of making the resulting XML code less accessible and transparent to other researchers. Instead we suggest a solution that facilitates a wider range of options to editors who wish to use <salute> and <signed> for the kinds of text material it was intended for.

Solution to Issue 3

42So far, the attribute @type is not permitted in <salute> and <signed>. As shown above, a variety of salutation and signature types exist and there may well be many ways to categorize them. The possibility to freely categorize or type salutations and signatures would allow the investigation of new and interesting research questions. From this perspective, we propose to include the attribute @type in <salute> and <signed>. To do so, <salute> should become a member of the attribute class att.typed. We assume this change would be unproblematic and valuable as well. Following this proposed change, an editor would be able to encode a salutation’s type as follows:

<salute type="formal">Durchlauchtiger Fürst</salute>
<salute type="family">Gnädiger HochgeEhrter Herr Vatter</salute>
<salute type="provision">Ew. Gnad*. gehorsame und demütige</salute>

43In cases such as the Intitulatio from Example 8, which in itself requires specification, a typified <seg> and <signed> can then be combined in a very useful way:

<seg type="intitulatio">
<signed type="family_status">Tochter</signed>
<signed type="name">A:D.</signed>
<signed type="title_of_nobility">HZS*</signed>
</seg>

44Ideally, the <seg>-element in the example at hand should be replaced by a semantically more fitting <signed>-tag:

<signed type="intitulatio">
<signed type="family_status">Tochter</signed>
<signed type="name">A:D.</signed>
<signed type="title_of_nobility">HZS*</signed>
</signed>

45Using <signed> in this manner, however, is not allowed under the current TEI Guidelines. Although this is not the main problem in the discussion at hand, it might be worth to consider lifting the restrictions on <signed> to facilitate embedded structures. Having a more specific tag available for encoding is often preferable to overusing <seg>.

Description of Issue 4

46Another element and member of the textstructure module which could be useful for letter encoding is <epigraph>. Although epigraphs in the sense of quotations typically appear on printed title pages, they can be found in opening or closing passages of letters as well.

47The TEI Guidelines define <epigraph> as follows:

<epigraph> contains a quotation, anonymous or attributed, appearing at the start or end of a section or on a title page.

(https://www.tei-c.org/Vault/P5/3.6.0/doc/tei-p5-doc/en/html/ref-dateline.html)

48As the description states, an epigraph appears at the start or end of a section or on a title page. The element <epigraph> is a member of model.divWrapper and two further model classes (model.pLike.front and model.titlepagePart). Moreover, it is specifically added to the content model of <opener>, but not to the content model of <closer>. As a consequence, <epigraph> can be grouped with <opener>, but not with <closer>.

Solution to Issue 4

49We suggest to add <epigraph> specifically to the content model of <closer>. This would enable the encoding of epigraphs as a part of the closing passage of a letter and would generally be more consistent.

Description of Issue 5

50Signatures in letters are usually encoded in the <signed> element. The <signed> element is described in the TEI Guidelines as follows:

<signed> (signature) contains the closing salutation, etc., appended to a foreword, dedicatory epistle, or other division of a text.

(https://tei-c.org/Vault/P5/3.6.0/doc/tei-p5-doc/en/html/ref-signed.html)

51It is currently part of the model.divTopPart and model.divBottomPart classes and therefore cannot be used to encode signatures found in the letter body. While it is correct that they are commonly placed in separate sections at the end of a letter, editors might be confronted with signatures of ambiguous placement. In the example below, the signature „Ht“ in the bottom right corner of the page is placed close enough to the preceding paragraph to be interpreted as formally a part of the letter body.

52It is known from convention that signatures are usually meant as isolated sections, but editors might prefer a diplomatic approach to transcription and rather encode the evident material than the supposed, underlying one.

Discussion of Issue 5

53As already suggested in issue 1 for salutations within a paragraph, the attribute @rend with value "inline" can be added to <signed> in order to encode its original position in the letter body.

<p>[...] Leben Zeit u Muth für höhere u edlere<lb/>Zwekke aufsparen muss.
</p>
<closer>
<signed rend="inline">Ht</signed>
</closer>

54This of course is unsatisfying for diplomatic transcriptions, since the <signed> element is separated from the paragraph which it is a part of according to the visible layout. While arguably such layout has not been intended by the writer, the editor still might want the actual appearance to be reflected in the encoding.

Solution to Issue 5

55We suggest to allow <signed> within <p>, just as proposed for <salute> in the solution to issue 1. The element <signed> is a member of both the classes model.divTopPart and model.divBottomPart and consequently limited to usage within <opener>, <closer>, and <postscript>. Moving it to model.inter or a similar model class would lift the restrictions and facilitate a more accurate encoding of structures such as the example above:

<p>[...] Leben Zeit u Muth für höhere u edlere<lb/>Zwekke aufsparen muss. <signed>Ht</signed>
</p>

56On top of that, <signed> could be assigned to the module core instead of textstructure, as suggested for <salute> in the solution to issue 1.

Description of Issue 6

57Datelines in letters usually contain the place and date of writing. In most cases they are placed at the top or bottom and the right or left corner of the letter paper. The corresponding TEI tag <dateline> is described as follows:

<dateline> contains a brief description of the place, date, time, etc. of production of a letter, newspaper story, or other work, prefixed or suffixed to it as a kind of heading or trailer.

(https://tei-c.org/Vault/P5/3.6.0/doc/tei-p5-doc/en/html/ref-dateline.html)

58<dateline> is part of the model.divWrapper class and, like <salute>, can be placed either within <opener> and <closer> , or as a single element at the top or bottom of a <div> element. The underlying assumption of this restriction is most likely that per convention, datelines in letters form a semantic section of their own and therefore are visibly set apart from other surrounding text, which is probably true for most cases. But, as has been observed in the preceding issues for <salute> and <signed>, not for all of them. In example 10 below, the dateline was written within the last line of the letter body. Unlike the signature in example 9, which most likely appears at the end of the letter body due to limited space for writing, in the letter at hand the dateline could have been comfortably added below it. Accordingly, the choice of placement might have been deliberate and even more so has to be taken into consideration when it comes to encoding.

Discussion of Issue 6

59Two arguments can be made against the interpretation of example 10 as a dateline within the paragraph which has to be encoded as such. Firstly, the paragraph that presumably contains the dateline might be read as part of the <closer>, in the sense that visually it seems to belong to the letter body but at the same time thematically it concludes the letter with a last key information. According to this analysis, the above letter’s closing section can be encoded in the following way:

<closer>
Wegen der Cultur-Gelder wird H. Professor Michaelis mit Ew. Hochwollgeb. communiciren. 	
<dateline>Hannover d. 16t Aug. 1753.</dateline>
<salute>an<lb/>H. Hoff-Rath<lb/>von Haller</salute>	
<signed>Balck.</signed>
</closer>

60Of course, in this encoding the text before the dateline is unspecified, which is fine with the TEI Guidelines, but might create inconsistencies in editions that generally apply the <opener> and <closer> encoding with the corresponding tags <dateline>, <salute> and <signed>. In addition to the editorial concerns, the unspecified text elements could conceivably complicate the automatic analysis of the XML code for research. On top of that, there is the problem of <dateline> being a separate line, and not part of the paragraph anymore. Alternatively, the last paragraph remains encoded as <p>, while the dateline is placed in <closer> as <dateline> with the attribute @rend and value "inline".

<p>Wegen der Cultur-Gelder wird H. Professor Michaelis mit Ew. Hochwollgeb. communiciren.</p>
<closer>
	<dateline rend="inline">Hannover d. 16t Aug. 1753.</dateline>
	<salute>an<lb/>H. Hoff-Rath<lb/>von Haller</salute>
	<signed>Balck.</signed>
</closer>

61This solution still bears the problem that the text material in question is removed from the paragraph where it had been placed in the original layout; it is therefore not feasible for diplomatic transcriptions.

62A second argument against an interpretation as a dateline within the letter body would be that the text “Hannover d. 16t Aug. 1753” is not a dateline at all, but instead a simple instance of a place and date mentioned, like in the encoding example below:

<p>Wegen der Cultur-Gelder wird H. Professor Michaelis mit Ew. Hochwollgeb. Communiciren. <name>Hannover</name> d. <date>16t Aug. 1753.</date></p>
<closer>
	<salute>an<lb/>H. Hoff-Rath<lb/>von Haller</salute>
	<signed>Balck.</signed>
</closer>

63Yet, this categorization is a decision that should be left to the editor. For that reason, an additional solution is proposed in the following section that provides the editor the option to include <dateline> in the paragraph.

Solution to Issue 6

64We suggest to allow <dateline> within <p> in order to facilitate diplomatic transcriptions of letters such as for example 10 above. On a formal level, <dateline> should be able to behave like <date> then.

<p>Wegen der Cultur-Gelder wird H. Professor Michaelis mit Ew. Hochwollgeb. Communiciren.<dateline>Hannover d. 16t Aug. 1753.</dateline></p>
		<closer>
			<salute>an<lb/>H. Hoff-Rath<lb/>von Haller</salute>
			<signed>Balck.</signed>
		</closer>

65To this end, <dateline> should be moved from the module textStructure to the module core, and from the class model.divWrapper to model.inter.

Description of Issue 7

66There are several scenarios in which other persons than a letter’s author might contribute written text to it, a frequent one being when the author dictates the letter, and someone else, for instance a secretary, does the actual writing. In those cases, the author in his or her capacity as the official sender adds the signature and possibly a salutation and dateline.

Discussion of Issue 7

67Currently the only possibility to encode the case that a dateline was written in a different hand than the rest of the letter (or most of the letter) is using the milestone element <handShift>. All of the other opening and closing elements of letters (<signed>, <salute>, <closer>, <opener> and <postscript>) can receive the attribute @hand; <dateline> is uniquely excluded. The TEI Guidelines do not clarify in which cases the attribute @hand, and in which cases the element <handShift> is preferred. The description of <handShift> states:

The handShift element may be used either to denote a shift in the document hand (as from one scribe to another, on one writing style to another). Or, it may indicate a shift within a document hand, as a change of writing style, character or ink. Like other milestone elements, it should appear at the point of transition from some other state to the state which it describes.

(https://tei-c.org/Vault/P5/3.6.0/doc/tei-p5-doc/en/html/ref-handShift.html)

68<handShift> is probably most appropriately employed when several shifts within a document happen, and the shifts are distributed in such a way that they cross the limits of elements and, therefore, require a milestone element to be encoded in XML at all, or the shifts take place in the middle of a text-containing element.

69If, on the other hand, a text-containing element is entirely written by a different scribe, although <handShift> being a formally correct option, using the attribute @hand is a more practical approach. <dateline> could be indirectly encoded as written by a different hand by adding @hand to the surrounding <opener> or <closer> element. Yet this solution might turn out to be unreliable for the editorial practice in cases where the <opener> or <closer> includes text which has been written by the same scribe as the majority of the letter (e.g. a salutation).

Solution to Issue 7

70<dateline> should be able to receive the attribute @hand. This change could help to ensure consistency in both individual editions’ transcription practice and the TEI Guidelines.

71It is worth mentioning that the issue at hand has been discussed in Issue #481 of the TEI GitHub repository, where it even has been suggested to allow the attribute @hand in all text-containing elements.