DALF -- A Preliminary P5 Proposal

1 DALF This! A Preliminary DALF P5 Customization

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.

2 DALF P5: Brief Overview

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 .

2.1 Metadata

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:

  • letAuthor: an author of the letter
  • letAddressee: an addressee of the letter
  • <respStmt>: possible other parties responsible for the content of the letter
  • letPlace: the place where the letter was written
  • letDate: the date when the letter was written

Apart from this letHeading section, some other elements are allowed in letDesc:

  • type: a formal classification of the letter
  • envOcc: an indication of the presence of an envelope
  • figOcc: an indication of the presence of illustrations in the letter
  • <note>: possible additional notes

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

<sourceDesc>
 <dalf:letDesc>
  <dalf:letHeading>
   <dalf:letAuthor><!-- ... --></dalf:letAuthor>
   <dalf:letAddressee><!-- ... --></dalf:letAddressee>
   <dalf:letPlace><!-- ... --></dalf:letPlace>
   <dalf:letDate><!-- ... --></dalf:letDate></dalf:letHeading>
  <dalf:envOcc occ=""/>
  <dalf:figOcc quantity=""/>
  <dalf:type><!-- ... --></dalf:type></dalf:letDesc>
 <msDesc>
  <msIdentifier><!-- ... --></msIdentifier>
  <msContents><!-- ... --></msContents>
  <physDesc><!-- ... --></physDesc>
  <history><!-- ... --></history>
  <additional><!-- ... --></additional>
  <msPart><!-- ... --></msPart>
 </msDesc>
</sourceDesc>

2.2 Envelope

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.

<text>
 <dalf:envelope>
  <dalf:envPart side="front">
   <dalf:letAddress type="addressee">
    <addrLine><!-- ... --></addrLine></dalf:letAddress>
   <dalf:postmark>
    <date><!-- ... --></date>
    <placeName><!-- ... --></placeName></dalf:postmark></dalf:envPart></dalf:envelope>
 <body><!-- ... --></body>
</text>

2.3 Calculations

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:

  • arg: an argument in a calculation
  • oper: the operator of a calculation
  • result: the result of a calculation
<dalf:calc>
 <dalf:arg>1</dalf:arg>
 <dalf:oper>+</dalf:oper>
 <dalf:arg>1</dalf:arg>
 <dalf:result>2</dalf:result></dalf:calc>

2.4 Printed Text

In order to encode text that is printed on the page (letterheads, form fields, stamps,...), the global element print is provided.

<dalf:print type="letterhead">letterhead</dalf:print>

3 DALF P4 → P5: Summary of Changes

3.1 <letDesc>

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.

Instead of adding letHeading to <msDesc>, in the vein of the principles of minimality and cleanliness identified above, this letter specific metadata section is now isolated as much as possible from existing TEI elements. Therefore, a substantively reduced letDesc is retained in this DALF P5 customization proposal, containing mainly the letHeading element and some orphaned elements that DALF P4 added to the original MASTER structure it was modeled on. This means that a full description of a DALF P5 letter will now consist of both a letDesc and a <msDesc> section in <sourceDesc>:
<sourceDesc>
 <dalf:letDesc>
  <dalf:letHeading>
   <dalf:letAuthor><!-- ... --></dalf:letAuthor>
   <dalf:letAddressee><!-- ... --></dalf:letAddressee>
   <dalf:letPlace><!-- ... --></dalf:letPlace>
   <dalf:letDate><!-- ... --></dalf:letDate></dalf:letHeading>
  <dalf:envOcc occ=""/>
  <dalf:figOcc quantity=""/>
  <dalf:type><!-- ... --></dalf:type></dalf:letDesc>
 <msDesc>
  <msIdentifier><!-- ... --></msIdentifier>
  <msContents><!-- ... --></msContents>
  <physDesc><!-- ... --></physDesc>
  <history><!-- ... --></history>
  <additional><!-- ... --></additional>
  <msPart><!-- ... --></msPart>
 </msDesc>
</sourceDesc>

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 P4DALF P5Remarks
<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
  • In alignment with TEI P5 naming elements, added attributes from att.naming: att.canonical (key, ref) + role, nymRef.
  • Declared as member of att.typed
.

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

3.2 Paraphernalia / Decorations

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:

  1. Instead of imposing a distinct system for paraphernalia (mirroring the TEI P5 <decoDesc> element) for the DALF P5 customization, it makes more sense to make use of the <decoNote> element's type attribute if one wants to distinguish between decorations and paraphernalia.
  2. Instead of retaining the DALF P4 <dalf.p4:deco> and <dalf.p4:paraph> text elements for referring to the definitions of these graphical elements in the header, such reference can equally be expressed with e.g. the corresp attribute on a <figure> or <graphic> element in the running text.

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:

  1. Either: graphical elements are only recorded where they occur in the text with the <figure> or just a <graphic> element, possibly with an appropriate value for the type attribute for distinguishing between decorations and paraphernalia. The <figDesc> child of the former element allows for an in-line description of the graphical element.
  2. Or: graphical elements are both described in the <decoDesc> section of a <physDesc> element (inside <msDesc>) and recorded where they occur in the text with the <figure> or just a <graphic> element. Connection between the graphical text elements and their respective descriptions in the header can be made explicit with the corresp attribute on <figure> or <graphic>.

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

3.3 Changes to Other DALF P4 Modifications

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 P4DALF P5Remarks
<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 attributeletAddressThe 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>printSome attribute changes between TEI P4 and P5:
  • handscribe
  • stylescript
  • inkmedium
  • character → /
<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).

4 Changing Practices

4.1 Facsimiles

Besides this formal mapping of DALF P4 elements to the TEI P5 ecosystem, some encoding practices require attention.

One important issue is the linking of letters to scanned facsimiles. In DALF P4 encoding practice, we resorted to a hack, by encoding them in a <note> element concluding <dalfP4:letDesc>, e.g.:
<dalf.p4:letDesc>
 <dalf.p4:letIdentifier><!-- ... --></dalf.p4:letIdentifier>
 <dalf.p4:letHeading><!-- ... --></dalf.p4:letHeading>
 <dalf.p4:physDesc><!-- ... --></dalf.p4:physDesc>
 <dalf.p4:envOcc occ="no"/>
 <note type="facs">
  <figure id="VNS.KVDWEDB.VdwDb19040000r1b.img"/>
  <figure id="VNS.KVDWEDB.VdwDb19040000v1b.img"/>
 </note></dalf.p4:letDesc>

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

For example, using this simple mechanism, DALF P5 could recommend to:
  • always use a facs attribute (when applicable) on a single container element (be it letDesc or text), containing references to all available facsimiles
  • connect specific text structures (e.g. <pb>) to more fine-grained facsimile references when available and desired
While the first recommendation ensures consistency (when facsimiles are available, they are always found in 1 place), the second one might add more (display) flexibility/accuracy.
<text
  xml:id="VNS.KVDWEDB.058"
  facs="VNS.KVDWEDB.VdwDb19040000r1b.img VNS.KVDWEDB.VdwDb19040000v1b.img">

 <body>
  <pb facs="VNS.KVDWEDB.VdwDb19040000r1b.img"/>
   <!-- ... -->
 <pb facs="VNS.KVDWEDB.VdwDb19040000v1b.img"/>
 </body>
</text>
Yet, the latter approach doesn't differ much from the TEI P5 recommended practice (see http://www.tei-c.org/release/doc/tei-p5-doc/en/html/PH.html#PHFAX) of using the facs attribute in conjunction with a <facsimile> element, which allows for much greater granularity. Therefore, it probably makes most sense to propose a formal definition in a <facsimile> element, with pointers to enclosed <graphic> elements by means of the facs attribute on their corresponding text structures, where applicable. This allows for rather clean processing (fallback) options as well:
  • just list the facsimiles in a <facsimile> element when no finer-grained anchors are available in the encoding
  • link to those facsimiles with the facs attribute from their corresponding text elements
<TEI xmlns="http://www.tei-c.org/ns/1.0">
 <teiHeader><!-- ... --></teiHeader>
 <facsimile>
  <graphic
    url="VNS.KVDWEDB.VdwDb19040000r1b.jpg"
    id="VNS.KVDWEDB.VdwDb19040000r1b"/>

  <graphic
    url="VNS.KVDWEDB.VdwDb19040000v1b.jpg"
    id="VNS.KVDWEDB.VdwDb19040000v1b"/>

 </facsimile>
 <text xml:id="VNS.KVDWEDB.058">
  <body>
   <pb facs="#VNS.KVDWEDB.VdwDb19040000r1b"/>
     <!-- ... -->
  <pb facs="#VNS.KVDWEDB.VdwDb19040000v1b"/>
  </body>
 </text>
</TEI>

4.2 Document Hands

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.

5 Summary of Issues for Further Discussion

5.1 Composite Letters

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:

  • such a unified description could be explicitly given in the /TEI/teiHeader/titleStmt/title element
  • a unified description could be composed from the contents of the different //letDesc/letHeading elements
DALF P4DALF P5Remarks
<dalf.p4:letPart>repeatable letHeadingCurrently 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

5.2 <letDesc>

  • Does the current proposal adequately cater for the encoding of composite letters with distinct letter parts in distinct letHeading elements (see previous section)?
  • Some elements of the letter description may require further evaluation:
    • envOcc and figOcc:
      • are these elements really needed, or can their semantics be as well inferred from the presence of envelope, resp. <figure> / <graphic> in the transcription of a letter?
      • if they are needed, the semantic relationship with envelope, resp. <figure> / <graphic> should be made more clear in the documentation (and perhaps formal agreement via Schematron rules)
    • figOcc: is a count of the number of illustrations in a letter in the quantity attribute a good approach?
    • type: maybe better means for expressing the "formal type" of the letter can be found

5.3 Physical Layers

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?

5.4 Global Additions

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:

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:

  • Are there good models for processing additions encoded with <addSpan>?
  • Are there other possible approaches to this problem (this is a 'standard' TEI problem ⇒ perhaps useful practice can be found in other projects)?

6 Formal Specification

Schema DALF: Elements

<arg> [http://ctb.kantl.be/DALF/2.0]

<arg> Contains the argument of a calculation.
ModuleDALF — Formal Specification
Member of
Contained by
DALF: calc
May contain
DALF: calc
Declaration
element arg { ( calc | macro.phraseSeq )* }

<calc> [http://ctb.kantl.be/DALF/2.0]

<calc> Contains a calculation.
ModuleDALF — Formal Specification
Member of
Contained by
May contain
Declaration
element calc { ( model.calcPart | macro.phraseSeq )* }

<envelope> [http://ctb.kantl.be/DALF/2.0]

<envelope> Contains the information on the envelope.
ModuleDALF — Formal Specification
Member of
Contained by
DALF: envelope
textstructure: text
May contain
Declaration
element envelope { ( model.envParts | model.noteLike )+ }

<envOcc> [http://ctb.kantl.be/DALF/2.0]

<envOcc> Contains an indication of the presence or absence of an envelope.
ModuleDALF — Formal Specification
Attributes
occIndicates the occurrence of an envelope.
Status Required
Datatype data.truthValue
Member of
Contained by
DALF: letDesc
May containEmpty element
Declaration
element envOcc { attribute occ { data.truthValue }, empty }

<envPart> [http://ctb.kantl.be/DALF/2.0]

<envPart> Contains the information on one side of the envelope.
ModuleDALF — Formal Specification
Attributes
side (side) Describes which side of the envelope features the data described.
Status Optional
Legal values are:
front
the data appears at the front side of the envelope
back
the data appears at the back side of the envelope
postcard
the data appears on a one-sided postcard envelope
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> [http://ctb.kantl.be/DALF/2.0]

<figOcc> Contains an indication of the presence or absence of graphical elements in a letter.
ModuleDALF — Formal Specification
Attributes
quantityIndicates the occurrence of graphical elements in a letter.
Status Required
Datatype data.numeric
Member of
Contained by
DALF: letDesc
May containEmpty element
Declaration
element figOcc { attribute quantity { data.numeric }, empty }

<layer> [http://ctb.kantl.be/>DALF]

<layer> Identifies each different physical layer the encoder wants to discern.
ModuleDALF — Formal Specification
Member of
Contained by
DALF: layerList
May containEmpty element
Declaration
element layer { p* }

<layerEnd> [http://ctb.kantl.be/DALF/2.0]

<layerEnd> Marks the end of a different physical layer in a letter.
ModuleDALF — Formal Specification
Attributes
layerProvides a pointer to the definition of the physical layer in the header.
Status Required
Datatype data.pointer
Member of
Contained by
Empty element
May containEmpty element
Declaration
element layerEnd { attribute layer { data.pointer }, empty }

<layerList> [http://ctb.kantl.be/>DALF]

<layerList> Contains a definition of the different physical layers in the source document.
ModuleDALF — Formal Specification
Member of
Contained by
Empty element
May contain
DALF: layer
Declaration
element layerList { layer+ }

<layerStart> [http://ctb.kantl.be/DALF/2.0]

<layerStart> Marks the start of a different physical layer in a letter.
ModuleDALF — Formal Specification
Attributes
layerProvides a pointer to the definition of the physical layer in the header.
Status Required
Datatype data.pointer
Member of
Contained by
Empty element
May containEmpty element
Declaration
element layerStart { attribute layer { data.pointer }, empty }

<letAddress> [http://ctb.kantl.be/DALF/2.0]

<letAddress> Contains an address for one of the participants in a correspondence.
ModuleDALF — Formal Specification
Member of
Contained by
Empty element
May containEmpty element
Declaration
element letAddress { model.global*, ( ( model.addrPart ), model.global* )+ }

<letAddressee> [http://ctb.kantl.be/DALF/2.0]

<letAddressee> Identifies a/the person to whom the letter was addressed.
ModuleDALF — Formal Specification
Attributesatt.attested (@attested, @accepted)
Member of
Contained by
May containEmpty element
Declaration
element letAddressee { att.attested.attributes, macro.phraseSeq }

<letAuthor> [http://ctb.kantl.be/DALF/2.0]

<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.
ModuleDALF — Formal Specification
Attributesatt.attested (@attested, @accepted)
Member of
Contained by
May containEmpty element
Declaration
element letAuthor { att.attested.attributes, macro.phraseSeq }

<letDate> [http://ctb.kantl.be/DALF/2.0]

<letDate> Identifies the place where the letter was written.
ModuleDALF — Formal Specification
Attributesatt.attested (@attested, @accepted)
Member of
Contained by
May containEmpty element
Declaration
element letDate { att.attested.attributes, macro.phraseSeq }

<letDesc> [http://ctb.kantl.be/DALF/2.0]

<letDesc> Groups together all letter-specific metadata for a DALF document.
ModuleDALF — Formal Specification
Member of
Contained by
Empty element
May contain
Declaration
element letDesc
{
   letHeading+, envOcc, figOcc, ( type? & class? ), model.noteLike*
}

<letHeading> [http://ctb.kantl.be/DALF/2.0]

<letHeading> Contains a structured description of bibliographical information of a letter.
ModuleDALF — Formal Specification
Member of
Contained by
DALF: letDesc
May contain
Declaration
element letHeading
{
   letAuthor+, letAddressee+, respStmt*, letPlace+, letDate+, note*
}

<letPlace> [http://ctb.kantl.be/DALF/2.0]

<letPlace> Identifies the place where the letter was written.
ModuleDALF — Formal Specification
Attributesatt.attested (@attested, @accepted)
Member of
Contained by
May containEmpty element
Declaration
element letPlace { att.attested.attributes, macro.phraseSeq }

<oper> [http://ctb.kantl.be/DALF/2.0]

<oper> Contains the operator of a calculation.
ModuleDALF — Formal Specification
Member of
Contained by
DALF: calc
May containEmpty element
Declaration
element oper { macro.phraseSeq }

<postmark> [http://ctb.kantl.be/DALF/2.0]

<postmark> Contains the postmark on an envelope.
ModuleDALF — Formal Specification
Member of
Contained by
DALF: envPart
May containEmpty element
Declaration
element postmark
{
   ( figure | model.placeNamePart | model.dateLike | model.noteLike )+
}

<print> [http://ctb.kantl.be/DALF/2.0]

<print> Contains printed material that was present on the carrier of the letter, or added afterwards.
ModuleDALF — Formal Specification
Member of
Contained by
Empty element
May containEmpty element
Declaration
element print { macro.specialPara }

<result> [http://ctb.kantl.be/DALF/2.0]

<result> Contains the result of a calculation.
ModuleDALF — Formal Specification
Member of
Contained by
DALF: calc
May contain
DALF: calc
Declaration
element result { ( calc | macro.phraseSeq )* }

<text>

<text>
Moduletextstructure
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> [http://ctb.kantl.be/DALF/2.0]

<type> Gives a formal characterisation of the letter.
ModuleDALF — Formal Specification
Member of
Contained by
DALF: letDesc
May containCharacter data only
Declaration
element type { text }

Schema DALF: Model classes

model.calcPart

model.calcPart groups elements that can occur inside calculations
ModuleDALF — Formal Specification
Used by
Membersarg calc oper result

model.DALFmilestones

model.DALFmilestones groups DALF elements that mark points in the text
ModuleDALF — Formal Specification
Used by
MemberslayerEnd layerStart

model.envParts

model.envParts groups elements that can occur inside envelopes
ModuleDALF — Formal Specification
Used by
MembersenvPart envelope

Schema DALF: Attribute classes

att.attested

att.attested Groups attributes for statements about the authority of information.
ModuleDALF — Formal Specification
MembersletAddressee letAuthor letDate letPlace
Attributes
attested (attested) Indicates the status of the contents of the element on which it appears with regard to the evidence from which it is derived.
Status Optional
Datatype 1–∞ occurrences of  data.enumeratedseparated by whitespace
Legal values are:
yes
the attribution in the element is made on the basis of evidence inside the letter
added
the attribution in the element is made on the basis of additional material accompanying the letter (eg. the envelope)
no
the attribution in the element is made on the basis of external evidence
unk
it is unknown on what basis the attribution in the element is made
accepted (accepted) Indicates whether the attribution made in the element is generally accepted. This is an optional attribute with one of following three values. Generally accepted attributions are encoded with value "yes"; attributions that are not generally accepted with "no"; when no claim can be made regarding this status, the value "unk" is used.
Status Optional
Datatype 1–∞ occurrences of  data.enumeratedseparated by whitespace
Legal values are:
yes
the attribution in the element is generally accepted
no
the attribution in the element is not generally accepted
unk
it is unknown whether the attribution in the element is generally accepted
Notes
1

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:

master:
indicates elements from the former MASTER specification
dalf.p4:
indicates elements from the TEI P4 DALF customization

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

2
So far, only <dalf.p4:decoration> / <dalf.p4:deco> is used in the CTB DALF collections, in a way that allows fairly seemless translation to inline <figure> / <figDesc> descriptions.
3
<dalf.p4:letPart> isn't used in the current CTB DALF collections.
4
Strictly speaking, its definition as member of 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.
5
The <dalf.p4:layerList> / <dalf.p4:layerStart> / <dalf.p4:layerEnd> system isn't used in the current CTB DALF collections.
Ron Van den Branden. Date: 2013-08-21