Letter Openers and Closers

Christian Forney, Susanne Haaf, Linda Kirsten
with contributions by Henry Seidel


  1Letters and similar forms of written communication typically contain opening or closing passages which may include salutations and valedictions, signatures, date and place of origin, addresses, as well as further statements. As Nickisch (1991: 10) noted, the formal structure of a letter (usually comprising the basic components opening, letter content, and closing) is strongly related to oral communication. Opening and closing passages in letters mark the start and end of a communicative act and tend most likely to formalisation.

  2The TEI module textstructure provides several elements to encode such phenomena:

<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.


<salute> (salutation) contains a salutation or greeting prefixed to a foreword, dedicatory epistle, or other division of a text, or the salutation in the closing of a letter, preface, etc.


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


  3The descriptions of <dateline>, <salute> and <signed> imply semantic and structural meanings at the same time. The TEI Guidelines determine specific opportunities and restrict the use of those elements: Informally, all three function as block-level elements or so-called chunks.[1] Similar to paragraphs, they can appear directly within texts or divisions, but are usually not allowed within other chunks. In other words: They are siblings of paragraphs and children of text divisions.

  4Furthermore, because <dateline> and <salute> are currently members of the model class model.divWrapper, they can appear either at the top or bottom of a textual division. The element <signed> is member of model.divBottomPart and model.divTopPart, therefore it can appear either at the beginning or end of a division. A consequence of this slightly different allocation is that <signed> can be placed directly within <postscript>, while <dateline> and <salute> need an intermediate <opener> or <closer> parent to exist within <postscript>. In this respect, the use of <signed> is less restricted than the use of <dateline> and <salute>.

  5The elements <opener> and <closer> enable to group a sequence of opening or closing elements, either at the beginning (model.divTopPart) or at the end (model.divBottomPart) of a textual division. The elements <dateline>, <salute> and <signed> have been specifically added to its content models:

<opener> groups together dateline, byline, salutation, and similar phrases appearing as a preliminary group at the start of a division, especially of a letter.


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


  6Finally, another item worth mentioning here because it is crucial in the context of epistolary documents is the <address> element which is provided by the TEI module core:

<address> contains a postal address, for example of a publisher, an organization, or an individual.


  7Regarding the location in a document, the element <address> is less restricted than <dateline>, <salute> and <signed>. As a member of model.global it can appear at any point within a TEI text. As they do in many cases, the TEI Guidelines provide different ways to encode the parts of a postal address: For one thing, they can be encoded primarily based on structural or renditional actualities as a sequence of address lines using <addrLine>:

<addrLine> (address line) contains one line of a postal address.


  8Alternatively, the encoding of address parts can be more semantically oriented using component elements from model.addrPart, such as <postCode>, <street> or <state>.[2]

Encoding of Opener and Closer—State of the Art

  9This section illustrates possible applications of the elements introduced before and provides a simple example. The picture below shows a letter from the German physician Paul Gottlieb Werlhof (1699–1767) to his intimate, the polymath Albrecht von Haller (1708–1777). The letter is dated 22 July 1746 and is written on a folded sheet on two pages:

Example 1: Letter with typical correspondence-related text elements (source: Paul Gottlieb Werlhof to Albrecht von Haller, 22 July 1746, Burgerbibliothek Bern, Sign: N Albrecht von Haller 105.74, Werlhof, Paul Gottlieb: 901).
  • Werlhof's letter starts with an informal salutation (“Dear Friend”) clearly offset on the top-left side of the page. The saluting phrase is obviously distinct from the paragraphs making up the letter content. This layout of salutations is very common and can be found in many letters.
  • Below the salutation, Werlhof wrote the letter content in prose using two paragraphs (in this example, the division into two paragraphs may not be obvious at a first glance). The paragraphs are slightly indented compared to the opening passage of the letter.
  • The closing passage consists of different phrases of greeting, Werlhof's signature and the notification of date and place (the two latter make up a “dateline”). Again, this part is visually offset from the main paragraphs as a block. The closing elements are arranged as differently indented lines.
  • On the left page the postal address was entered: It is centered in the middle of the page and arranged in horizontal format. The name of the recipient, title and place of residence are written in a rather formal manner and laid out over a number of lines.

10The following reveals one of several possibilities to encode the basic structure and semantics of this letter. This provides an opportunity to discuss the application of the elements introduced above (example 2). The transcriptions are taken from Otto Sonntag (2014):

			<salute>Dear Friend,</salute>
		<p>Come, when You can and please. <persName>Mecenas</persName> shall be here again y<hi rend="superscript">e</hi> 28<hi rend="superscript">th</hi>. I hope for some Joy, hoping to see Your Face and to speak with You. But You will make some stay here, I think, and I will endeavour to steal some Moments for my Satisfaction. I am sorry for Your Polypes.</p>
		<p>Mons has surrender’d ye 11th, the Garrison Prisonners. The Defense has been realy as indifferent, as of ye other Places. No news worth ye while from Italy, nor from Scotland, nor any of ye french Fleet.</p>
			<salute>I am with all my Heart<lb/>Dear Friend<lb/>Yours most faithfully</salute>
			<dateline>H[annover] July 22<lb/>46.</dateline>
			<addrLine>à Monsieur</addrLine>
			<addrLine>Monsieur Haller</addrLine>
			<addrLine>conseiller aulique et<lb/>professeur roïal</addrLine>
Example 2: Otto Sonntag (ed.), Paul Gottlieb Werlhof's letters to Albrecht von Haller, vol. 1, Basel 2014, p. 1470f.

11To get back to the opening part: The salutation is encoded with a <salute>, which in turn is placed in an <opener> grouping element. Apparently, it is not strictly necessary to group a single element and the TEI Guidelines would also allow the <salute> to appear directly in the letter <div>. However, in both cases the saluting phrase is encoded on block-level.

12The letter content consists of two paragraphs, the main unit of prose texts.[3] In this example, the <p> elements include text and some phrase-level elements. Some <hi> elements have been applied to encode super- and subscript parts and a <persName> element to mark the mentioning of a mutual friend of Werlhof and Haller (for brevity, not all names mentioned or characters emphasized have been encoded in this example).

13A <closer> groups the elements which form the closing part of the letter. <salute> and <signed> have been applied to encode saluting phrases and the signature of the author. <dateline> marks the letter date and the place of origin. One aspect worth pointing out here is the differentiation between <salute> and <signed>. The difference is not immediately obvious insofar as both can contain salutations (compare the definitions of the two elements in the introduction).[4] While <salute> is intended to encode a phrase containing a salutation, <signed> is applied to phrases containing a signature and possibly some kind of salutation.[5] For that reason, the following is also a valid encoding:

<salute>I am with all my Heart<lb/>Dear Friend</salute>
			<signed>Yours most faithfully<lb/>Werlhof</signed>

14The postal address is encoded with an <address> and a number of generic <addrLine>. In this example, Haller's address in Göttingen is distributed over 6 distinct lines of text. Therefore, the simplest approach would be to apply six <addrLine> elements. However, the encoding above includes only 5 <addrLine>, but one of them additionally contains a linebreak element (<lb>). This combination of <addrLine> and <lb> provides a possibility to group basic units (e.g. the title or the location) which are distributed over several lines within one element. In the case where <addrLine> serves as a wrapper for elements which cannot appear in <address> directly, this has clear advantages.

15Opening or closing parts of letters may contain phrases which do not really fit into the TEI elements allowed in <opener> and <closer>. Although renditionally oriented, all child elements of <opener> and <closer> have a semantic meaning (e.g. it is a salutation or a signature). Of course, it should be stressed here that <opener> and <closer> can also contain text nodes. Therefore, encoders have the possibility to place text nodes directly in <opener> and <closer> on the block-level:

		Text which does not fit into existing categories […].
		<salute>Best wishes,</salute>

16Nevertheless it is worth considering to allow paragraphs in <opener> or <closer>. This would provide a semantically more free element to encode opening or closing passages which do not fit into existing categories.

Encoding Problems around Opener and Closer

Issue 1: Salutations within Paragraphs

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:

Example 3: Inline salutation at the start of a paragraph (source: Paul Gottlieb Werlhof to Albrecht von Haller, 8 Mai 1739, Burgerbibliothek Bern, Sign: N Albrecht von Haller 105.71, Werlhof, Paul Gottlieb: 248).

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 […]”):

Example 4: Inline salutation embedded in a paragraph and enclosed by parts of the first sentence (source: Paul Gottlieb Werlhof to Albrecht von Haller, 11 Juni 1742, Burgerbibliothek Bern, Sign: N Albrecht von Haller 105.72, Werlhof, Paul Gottlieb: 539).

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>
Example 5: John George I, Prince of Anhalt-Dessau to his sister Dorothea Maria of Anhalt, Dessau, 6. November 1605 (LATh - HSt Weimar, Fürstenhaus A 552, fol. 216r)

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>
This approach could be an appropriate simplification in some cases. In others it will be unsatisfactory. For example, it would be inadequate in the context of a diplomatic transcription to render the embedded saluting phrase offset the paragraph.

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>
This may be a solution for saluting phrases embedded at the beginning or end of a paragraph. But would this also work in case of example 4 and 5, where a salutatory phrase is embedded within the first sentence?

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.

Issue 2: Salutations within a Paragraph and the Following Closer

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.

Example 6: Salutations in letter body and letter closer (source: Christian Gottfried Ehrenberg to Alexander von Humboldt, 25 March 1858, p 3v, Archiv der Berlin-Brandenburgischen Akademie der Wissenschaften; Shelfmark: NL C. G. Ehrenberg, 676, fol. 19-22)

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.

	<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>

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.”


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.

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

Issue 3: Different Types of Salutations and Signatures

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>
Example 7: John George I, Prince of Anhalt-Dessau to his sister Dorothea Maria of Anhalt, Dessau, 6. November 1605 (LATh - HSt Weimar, Fürstenhaus A 552, fol. 216r)
  • 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/>
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/>
A:D. HZS*</p>
Example 8: Anna Dorothea of Saxe-Weimar, Abbess of Quedlinburg to her father, John Ernest II, Duke of Saxe-Weimar, 22. September 1679 (LATh – HStAW, FH A 358 fol. 24r-25r; transcription: Lühr et al. 2013: AD_JE2_1679_09_22.)
  • Date and place: “W[eimar]. d[en]. 22. Sebtemb[er] 1679.”
  • Formal salutation: “Durchlauchtiger Fürst”
  • Family salutation: “Gnädiger HochgeEhrter Herr Vatter”
  • 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

<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>

39(2) A multipart signature

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

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>

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>

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>

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>.

Issue 4: Epigraph within Closer

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.


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.

Issue 5: Signature within Paragraph

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.


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.

Example 9: Signature within paragraph (source: Alexander von Humboldt to Christian Gottfried Ehrenberg, August 1833, p. 2v, Archiv der Berlin-Brandenburgischen Akademie der Wissenschaften (Sign: NL C. G. Ehrenberg, 421, fol. 71r-72v)

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.
<signed rend="inline">Ht</signed>

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>

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.

Issue 6: Dateline within Paragraph

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.


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.

Example 10: Dateline within paragraphsource: Pro Memoria from Heinrich Eberhard Balck to Albrecht von Haller, 16 August 1753, Burgerbibliothek Bern, Sign: N Albrecht von Haller 105.2, Balck, Heinrich Eberhard: 14.

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:

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>	

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>
	<dateline rend="inline">Hannover d. 16t Aug. 1753.</dateline>
	<salute>an<lb/>H. Hoff-Rath<lb/>von Haller</salute>

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>
	<salute>an<lb/>H. Hoff-Rath<lb/>von Haller</salute>

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>
			<salute>an<lb/>H. Hoff-Rath<lb/>von Haller</salute>

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

Issue 7: Dateline Written by a Different Hand

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.


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.


72In this article, we discussed usage scenarios for opening and closing elements in TEI documents and problems with existing restrictions of the TEI Guidelines.

73The TEI elements provided to structure the opening and closing passages of letters, namely <opener> and <closer> as well as their possible child elements <salute>, <signed>, and <dateline>, are all defined not only by their semantic meaning but also by layout specifics in the text: they are all considered block text passages separated from the letter body. While the elements <opener> and <closer> may well fit such layout constraints, the elements representing salutations, signatures, or datelines should become less restricted regarding their location in the TEI document. In fact, there are many examples for letters where salutations, signatures or datelines are part of the first or last paragraphs or even appear in the middle of opening and closing sentences.

74Furthermore, we propose wider usage options for the element <epigraph>, as epigraphs may appear not only at the beginning but also at the end of letters.

75Finally, some changes to the attribute selection of the elements discussed here were considered in order to allow for the distinction between different types of signatures and salutations as well as different writer’s hands for datelines.



  • Paul Gottlieb Werlhof's letters to Albrecht von Haller. Volume 1. Edited by Otto Sonntag. Volume 1. Basel: Schwabe, 2014 (=Studia Halleriana 11/1).Zotero
  • Nickisch, Reinhard M. G.: Brief, Stuttgart 1991.Zotero
  • TEI Consortium, eds. TEI P5: Guidelines for Electronic Text Encoding and Interchange. Version 3.6.0. Last updated on 16th July 2019. TEI Consortium. https://www.tei-c.org/Vault/P5/3.6.0/doc/tei-p5-doc/en/html (last accessed: 10th January 2020).Zotero
  • Lühr Rosemarie, Faßhauer Vera, Prutscher Daniela, Seidel Henry (eds.): Fuerstinnenkorrespondenz 1.1 (Version 1.1). Universität Jena 2013. https://doi.org/10.34644/laudatio-repository-H2hDmGoB6bp_h9Na8c2R_1557384256.Zotero


Christian Forney, Susanne Haaf, Linda Kirsten: Letter Openers and Closers. In: Encoding Correspondence. A Manual for Encoding Letters and Postcards in TEI-XML and DTABf. Edited by Stefan Dumont, Susanne Haaf and Sabine Seifert. Berlin 2019. URL: https://encoding-correspondence.bbaw.de/v1/openers-closers.html URN: urn:nbn:de:kobv:b4-20200110163801810-3945310-7