This customization draft provides a starting point for determining the most sensible way to express DALF as a TEI P5 customization. Since the transition from version P4 to P5, the TEI ecosystem has changed substantially, which provided a good opportunity to re-evaluate DALF as a clean, lean TEI P5 customization, following two principles:
Thus, this customization proposal presents both a reduced DALF customization, and strategies to make as much use of standard TEI P5 elements as possible.
The next section, 2 DALF P5: Brief Overview provides a brief overview of the key features of DALF P5. In 3 DALF P4 → P5: Summary of Changes, the differences between DALF P4 and DALF P5 are summarized. Some recommendations for an updated encoding practice are given in 4 Changing Practices, while outstanding issues for further discussion are identified in 5 Summary of Issues for Further Discussion. Finally, the technical specification of all elements is given in 6 Formal Specification.
A DALF encoded letter is a regular TEI element, with some extensions for expressing letter-specific metadata and text phenomena. These extension elements belong to the http://ctb.kantl.be/DALF/2.0
namespace, and are summarized below 1 .
The TEI header provides ample means for the expression of rich metadata descriptions of the encoded text. The introduction of <msDesc> into TEI P5 has even expanded these metadata features with specific provisions for describing manuscripts. Still, we felt that the current TEI guidelines lack features for adequate description of specific metadata of letters. Therefore, the letDesc (Letter Description) element is introduced in <sourceDesc>. In this proposal, it consists of one big section letHeading, containing a description of the communicative primitives that characterize a letter:
Apart from this letHeading section, some other elements are allowed in letDesc:
In order to document details about the letter's providence, physical characteristics, custodial history, etc., encoders are expected to make use of the TEI <msDesc> element (making slight abstraction of the ‘ms’ part of this element's name when encoding typoscript letters).
In order to encode envelopes, an envelope element is provided as a child of text. Each side of an envelope is encoded in an envPart element, optionally identified with a suitable value for the side attribute (front / back / postcard). Apart from global elements, div- and address-like elements, envPart may contain a specific postmark element for transcribing the information in the postmark, which may be useful for dating or localization purposes.
Although not strictly letter-specific, especially business-related correspondences may contain lots of calculations, for which we considered standard TEI does not provide an adequate encoding means. Therefore, a global calc element is introduced, within which following constituents of a calculation can be identified:
In order to encode text that is printed on the page (letterheads, form fields, stamps,...), the global element print is provided.
The original DALF <dalf.p4:letDesc> element was modeled after the <master:msDescription> from the MASTER TEI P4 customization for encoding manuscripts. With the transition from TEI P4 to P5, the original <master:msDescription> has been incorporated into the TEI module for manuscript description, as the <msDesc> element. Most of its original constituents were taken over (with some modifications), with one notable exception: the original <master:msHeading> element has been removed from <msDesc> in TEI P5, and replaced with a much shallower set of elements of the model.headLike
model class. This provided a good opportunity to isolate the corresponding <dalf.p4:letHeading> element from the DALF P4 customization as the core of the DALF specific metadata for a DALF P5 customization, containing a description of the communicative primitives that characterize a letter.
In order to cater for the encoding of composite letters, letHeading has been made repeatable, and member of att.declarable (see 5.1 Composite Letters).
In order to increase consistency, some DALF metadata elements of letHeading have been renamed:
DALF P4 | DALF P5 | Remarks |
<dalf.p4:author> <dalf.p4:addressee> | letAuthor letAddressee | In alignment with TEI P5 naming elements, added attributes from att.naming : att.canonical (key, ref) + role, nymRef. |
<dalf.p4:dateLet> <dalf.p4:placeLet> | letDate letPlace |
|
Additionally, to cater for more fine-grained descriptions, the content model of letHeading has been relaxed: now all child elements can occur once or more.
The idea is that letDesc be used to document all and only letter-specific metadata, while the standard TEI P5 element <msDesc> should be used to describe the manuscript qualities of the letter. Therefore, most of the original DALF P4 letDesc elements (that were mostly based on MASTER) have been incorporated and/or redefined in TEI P5, so they haven't been redefined in DALF P5: <dalf.p4:accMat>, <dalf.p4:acquisition>, <dalf.p4:additional>, <dalf.p4:adminInfo>, <dalf.p4:altName>, <dalf.p4:collection>, <dalf.p4:condition>, <dalf.p4:custEvent>, <dalf.p4:custodialHist>, <dalf.p4:depth>, <dalf.p4:dimensions>, <dalf.p4:height>, <dalf.p4:history>, <dalf.p4:institution>, <dalf.p4:layout>, <dalf.p4:letContents>, <dalf.p4:letIdentifier>, <dalf.p4:musicNotation>, <dalf.p4:origin>, <dalf.p4:physDesc>, <dalf.p4:provenance>, <dalf.p4:remarks>, <dalf.p4:repository>, <dalf.p4:support>, <dalf.p4:surrogates>, <dalf.p4:width>.
DALF P4 defined a distinction between <dalf.p4:decorations> and <dalf.p4:paraphernalia>, 2 header elements where aspects of decorations, resp. paraphernalia present in a letter could be described. In order to accomodate for a full description of such graphical elements in the header, accompanying phrase-level elements (<dalf.p4:deco> and <dalf.p4:paraph>) had been defined for indicating their presence in the running text and pointing to the appropriate ‘definitions’ in the header. This complex system is abandoned in DALF P5, in favour of the use of standard TEI P5 elements.
Originally, <dalf.p4:decoration> and <dalf.p4:paraphernalia> were modeled after the <master:decoration> section in <master:physDesc>. In TEI P5, <master:decoration> has been renamed to <decoDesc>, with a revised internal structure. This motivated a reorganization of the approach for describing decorations / paraphernalia in DALF P5. Following changes are suggested:
In short, the decorations / paraphernalia system of DALF P4 was deemed too heavy for common encoding practice2. Moreover, an analysis of the TEI P5 provisions for detailed image description suggests that they suffice for expressing these semantics without modifications, in a quite flexible way:
On the other hand, this raises the question if a dedicated header element should be created to merely signal the occurrence of illustrations in a letter. After all, for some correspondences this could be a relevant search criterium, while encoding practice could prescribe to omit graphical elements from the transcription (and rely e.g. on scanned facsimiles for conveying this information). Therefore, a new figOcc element has been proposed in the DALF P5 letDesc header section, analogous to envOcc, with a quantity attribute. (see 2.1 Metadata)
DALF P4 | DALF P5 | Remarks |
<dalf.p4:deco> <dalf.p4:paraph> | / | Use TEI P5 <figure> and/or <graphic>. |
<dalf.p4:decoList>, <dalf.p4:paraphList> <dalf.p4:decoration>, <dalf.p4:paraphernalia> | / | Use TEI P5 <decoDesc>. |
<dalf.p4:decoDesc>, <dalf.p4:paraphDesc> <dalf.p4:decoItem>, <dalf.p4:paraphItem> <dalf.p4:decoText>, <dalf.p4:paraphText> | / | Use TEI P5 <decoNote>. |
Apart from these ‘structural’ revisions of groups of DALF P4 elements, some loose DALF P4 modifications have been reconsidered as well. The table below provides a summary.
DALF P4 | DALF P5 | Remarks |
<dalf.p4:add> as global element | / | The standard TEI P5 element <add> is left unmodified. Instead of redefining it as a global element, or adding a specific DALF element for additions (with a wider distribution than <add>), use of the <addSpan> element is advised for cases where <add> can't occur. |
<dalf.p4:address> with type attribute | letAddress | The standard TEI P5 element <address> is left unmodified. Additionally, a letAddress element is added, with a type attribute, which can be used to encode addresses occurring inside envelope. |
<dalf.p4:class> | / | Defined in DALF P4 as child of <dalf.p4:letDesc>, to indicate ‘a functional-communicative "genre"-indication of letters (still to be developed)’. Removed from DALF P5: use standard TEI P5 <taxonomy> element. |
<dalf.p4:letPart> | / | Currently not defined in this DALF P5 proposal; instead, letDesc has been made repeatable, and member of att.declarable (see 5.1 Composite Letters). |
<dalf.p4:print> | Some attribute changes between TEI P4 and P5:
| |
<dalf.p4:ps> | <postscript> | The DALF P4 <dalf.p4:ps> element is not reformulated in this DALF P5 proposal, since the standard TEI P5 <postscript> element is defined quasi identically. Moreover, the content model of <postscript> has been substantially revised since release 2.0.0 of TEI P5, making it more like a div-like element (see http://sourceforge.net/tracker/?func=detail&aid=3232942&group_id=106328&atid=644065). |
Besides this formal mapping of DALF P4 elements to the TEI P5 ecosystem, some encoding practices require attention.
Nowadays, TEI P5 has the facs attribute, wich is added to the global attributes when the ‘transcr’ module is selected. This attribute allows an encoder to provide a whitespace-separated list of (in)direct pointers to scanned facsimiles, and can (as a global attribute) be attached to any element, which seems to be both a flexible and elegant solution. It would be good to examine whether it is also a sufficient solution for different encoding realities (depending on the document structures available in the transcriptions to attach the facsimile references to).
Another obvious candidate for such an encoding recommendation, is the documentation of document hands. By default, TEI P5 offers the possibility to document each hand in a separate <handNote> element inside <handNotes> in the <profileDesc> section of the TEI header. Additionally, the ‘msdescription’ module adds a slightly more elaborate <handDesc> element to <physDesc>, which can also contain <handNote> elements.
DALF P4 defined a <dalf.p4:letPart> element to encode specific metadata for distinct composing parts of a letter. This could be the second least used DALF P4 feature 3. One possible reason could lie with a suboptimal definition in DALF P4.
Considering the proposed pruning in DALF P5 of letDesc to retain only letHeading, the manuscript-level description sections of the DALF P4 <dalf.p4:letPart> element will be available in DALF P5 in its TEI P5 <msPart> counterpart. Adding letHeading to <msDesc> / <msPart> wouldn't be compatible with the desire to keep the DALF P5 modification as 'clean' as possible. On the other hand, a possible 'clean' solution could be to allow for more than one letHeading element inside letDesc, and make it a member of the TEI P5 class att.declarable
, for exact reference from within the transcription by means of the decls attribute (see http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CC.html#CCAS).
This makes it possible to distinguish and identify communicatively distinct parts of a letter with different letHeading elements, appearing at the same level within letDesc. This means that for such letters there is no overarching (communicative) description. Still, two possible approaches can be taken to describe them as a single letter:
/TEI/teiHeader/titleStmt/title
element//letDesc/letHeading
elementsDALF P4 | DALF P5 | Remarks |
<dalf.p4:letPart> | repeatable letHeading | Currently not defined in this DALF P5 proposal; instead, letHeading has been made repeatable, and member of att.declarable . |
⇒ Is letHeading the right level for describing multiple parts of a letter, or is it too narrow? Could it be more adequate to allow for the descriptions of different letter parts in distinct, repeatable letDesc elements under <sourceDesc>?4
This could be the single most theoretical / least used DALF P4 feature 5. While not even letter-specific, its relevance for a P5 version of DALF could be questioned, especially when taking into account the improved facilities for encoding physical layers in the updated TEI P5 module for editing of primary sources. Even on its own merits, one could ask oneself whether it contributes anything substantive to the overlapping hierarchies problem that could not be addressed with standard TEI P5 <span> and <milestone> elements.
Nonetheless, the DALF P4 system (with layer definitions inside the layerList header element and references to those layers in the layerStart / layerEnd text elements) has been incorporated in this DALF P5 proposal, for the time being.
⇒ Should this be in DALF P5 at all?
Due to the manuscript nature of letters, text can be added virtually anywhere on a letter. In a desire to cater for the encoding of such ‘global additions’, DALF P4 defined the <dalf.p4:add> element as a global variant of its standard TEI P4 counterpart. While 'solving' one issue (the encoding of small additions that can occur virtually anywhere in a letter), it remains problematic for bigger chunks of added text (multiple paragraphs, or even bigger fragments). The standard original <add> element only can sub-paragraph level elements. Hence, for the sake of conformance, a DALF P5 version of the <add> element could be defined as a global element, that can contain both chunk- and phrase-level elements. Yet, the question remains whether this is desirable (and if it doesn't interfere too much with the TEI text model and hence would compromise future TEI-compatibility of DALF-encoded letters).
In view of these issues, it was decided that in first instance, the global <dalf.p4:add> element would be dropped from DALF P5 (see 3.3 Changes to Other DALF P4 Modifications), and rely on standard TEI mechanisms for encoding:
<ab type="add">...</ab>
Do the standard TEI solutions suffice, or is there a real need for a global content element that can encode additions above and below paragraph level?
On a related note, following issues could be worth investigating:
<arg> Contains the argument of a calculation. | |
Module | DALF — Formal Specification |
Member of | |
Contained by | DALF: calc |
May contain | DALF: calc |
Declaration | element arg { ( calc | macro.phraseSeq )* } |
<calc> Contains a calculation. | |
Module | DALF — Formal Specification |
Member of | |
Contained by | |
May contain | |
Declaration | element calc { ( model.calcPart | macro.phraseSeq )* } |
<envelope> Contains the information on the envelope. | |
Module | DALF — Formal Specification |
Member of | |
Contained by | |
May contain | |
Declaration | element envelope { ( model.envParts | model.noteLike )+ } |
<envOcc> Contains an indication of the presence or absence of an envelope. | |||||||
Module | DALF — Formal Specification | ||||||
Attributes |
| ||||||
Member of | |||||||
Contained by | DALF: letDesc | ||||||
May contain | Empty element | ||||||
Declaration | element envOcc { attribute occ { data.truthValue }, empty } |
<envPart> Contains the information on one side of the envelope. | |||||||
Module | DALF — Formal Specification | ||||||
Attributes |
| ||||||
Member of | |||||||
Contained by | DALF: envelope | ||||||
May contain | DALF: postmark | ||||||
Declaration | element envPart { attribute side { "front" | "back" | "postcard" }?, ( model.addressLike | postmark | model.divLike | model.global )+ } |
<figOcc> Contains an indication of the presence or absence of graphical elements in a letter. | |||||||
Module | DALF — Formal Specification | ||||||
Attributes |
| ||||||
Member of | |||||||
Contained by | DALF: letDesc | ||||||
May contain | Empty element | ||||||
Declaration | element figOcc { attribute quantity { data.numeric }, empty } |
<layer> Identifies each different physical layer the encoder wants to discern. | |
Module | DALF — Formal Specification |
Member of | |
Contained by | DALF: layerList |
May contain | Empty element |
Declaration | element layer { p* } |
<layerEnd> Marks the end of a different physical layer in a letter. | |||||||
Module | DALF — Formal Specification | ||||||
Attributes |
| ||||||
Member of | |||||||
Contained by | Empty element | ||||||
May contain | Empty element | ||||||
Declaration | element layerEnd { attribute layer { data.pointer }, empty } |
<layerList> Contains a definition of the different physical layers in the source document. | |
Module | DALF — Formal Specification |
Member of | |
Contained by | Empty element |
May contain | DALF: layer |
Declaration | element layerList { layer+ } |
<layerStart> Marks the start of a different physical layer in a letter. | |||||||
Module | DALF — Formal Specification | ||||||
Attributes |
| ||||||
Member of | |||||||
Contained by | Empty element | ||||||
May contain | Empty element | ||||||
Declaration | element layerStart { attribute layer { data.pointer }, empty } |
<letAddress> Contains an address for one of the participants in a correspondence. | |
Module | DALF — Formal Specification |
Member of | |
Contained by | Empty element |
May contain | Empty element |
Declaration | element letAddress { model.global*, ( ( model.addrPart ), model.global* )+ } |
<letAddressee> Identifies a/the person to whom the letter was addressed. | |
Module | DALF — Formal Specification |
Attributes | att.attested (@attested, @accepted) |
Member of | |
Contained by | DALF: letHeading |
May contain | Empty element |
Declaration | element letAddressee { att.attested.attributes, macro.phraseSeq } |
<letAuthor> In a bibliographic reference, contains the name of the author(s), personal or corporate, of a work; the primary statement of responsibility for any bibliographic item. | |
Module | DALF — Formal Specification |
Attributes | att.attested (@attested, @accepted) |
Member of | |
Contained by | DALF: letHeading |
May contain | Empty element |
Declaration | element letAuthor { att.attested.attributes, macro.phraseSeq } |
<letDate> Identifies the place where the letter was written. | |
Module | DALF — Formal Specification |
Attributes | att.attested (@attested, @accepted) |
Member of | |
Contained by | DALF: letHeading |
May contain | Empty element |
Declaration | element letDate { att.attested.attributes, macro.phraseSeq } |
<letDesc> Groups together all letter-specific metadata for a DALF document. | |
Module | DALF — Formal Specification |
Member of | |
Contained by | Empty element |
May contain | DALF: envOcc figOcc letHeading type |
Declaration | element letDesc { letHeading+, envOcc, figOcc, ( type? & class? ), model.noteLike* } |
<letHeading> Contains a structured description of bibliographical information of a letter. | |
Module | DALF — Formal Specification |
Member of | |
Contained by | DALF: letDesc |
May contain | DALF: letAddressee letAuthor letDate letPlace |
Declaration | element letHeading { letAuthor+, letAddressee+, respStmt*, letPlace+, letDate+, note* } |
<letPlace> Identifies the place where the letter was written. | |
Module | DALF — Formal Specification |
Attributes | att.attested (@attested, @accepted) |
Member of | |
Contained by | DALF: letHeading |
May contain | Empty element |
Declaration | element letPlace { att.attested.attributes, macro.phraseSeq } |
<oper> Contains the operator of a calculation. | |
Module | DALF — Formal Specification |
Member of | |
Contained by | DALF: calc |
May contain | Empty element |
Declaration | element oper { macro.phraseSeq } |
<postmark> Contains the postmark on an envelope. | |
Module | DALF — Formal Specification |
Member of | |
Contained by | DALF: envPart |
May contain | Empty element |
Declaration | element postmark { ( figure | model.placeNamePart | model.dateLike | model.noteLike )+ } |
<print> Contains printed material that was present on the carrier of the letter, or added afterwards. | |
Module | DALF — Formal Specification |
Member of | |
Contained by | Empty element |
May contain | Empty element |
Declaration | element print { macro.specialPara } |
<result> Contains the result of a calculation. | |
Module | DALF — Formal Specification |
Member of | |
Contained by | DALF: calc |
May contain | DALF: calc |
Declaration | element result { ( calc | macro.phraseSeq )* } |
<text> | |
Module | textstructure |
Member of | |
Contained by | Empty element |
May contain | DALF: envelope |
Declaration | element text { ( model.global | envelope )*, ( front, ( model.global | envelope )* )?, ( body | group ), ( model.global | envelope )*, ( back, ( model.global | envelope )* )?+ } |
<type> Gives a formal characterisation of the letter. | |
Module | DALF — Formal Specification |
Member of | |
Contained by | DALF: letDesc |
May contain | Character data only |
Declaration | element type { text } |
model.calcPart groups elements that can occur inside calculations | |
Module | DALF — Formal Specification |
Used by | |
Members | arg calc oper result |
model.DALFmilestones groups DALF elements that mark points in the text | |
Module | DALF — Formal Specification |
Used by | |
Members | layerEnd layerStart |
model.envParts groups elements that can occur inside envelopes | |
Module | DALF — Formal Specification |
Used by | |
Members | envPart envelope |
att.attested Groups attributes for statements about the authority of information. | |||||||||||||||||
Module | DALF — Formal Specification | ||||||||||||||||
Members | letAddressee letAuthor letDate letPlace | ||||||||||||||||
Attributes |
|
For clarity's sake, this documentation makes use of (dummy) namespace prefixes to distinguish between elements that don't occur in this DALF P5 specification:
Note how, technically, neither of both schemas was expressed in any namespace.
For both TEI (http://www.tei-c.org/ns/1.0
) and DALF (http://ctb.kantl.be/DALF/2.0
) elements named in this documentation, no namespace prefix is used (in order to facilitate linking in the documentation when generated with the default TEI XSLT stylesheets).
model.sourceDescPart
already allows for more than 1 letDesc element. Still, it may seem counterintuitive to recommend having multiple ‘Letter Descriptions’ for different parts inside a single letter.