10.1. General Usage 10.2. Variants in Musical Content 10.3. Variants in Score Definitions 10.4. Nesting Apparati
This chapter describes how to encode differences between multiple exemplars of the same musical work (often referred to in MEI as ‘sources’). The mechanisms and elements described in this chapter are closely related to their counterparts in the TEI guidelines. It is also important to refer to chapter Editorial Markup of these guidelines, especially concerning the choice element described therein.
The following elements are defined in the critApp Module:
An app element always encapsulates the differences between varying sources. Therefore, it must contain at least two child elements. Possible child elements are lem and rdg, which use the same model, but have a different meaning: Whereas lem is used for prioritizing one alternative, a rdg has no such additional meaning and simply indicates a reading as found in one or more sources. Accordingly, lem is allowed only once in app, whereas rdg may appear as often as necessary.
<app>
<lem>
<!-- preferred reading -->
</lem>
<rdg>
<!-- alternative reading -->
</rdg>
<rdg>
<!-- alternative reading -->
</rdg>
</app>The rdg (and lem) elements use the @source attribute to point to one or more descriptions of the bibliographic sources containing the material they mark:
<!-- In the document content: --><app>
<rdg source="#critApp.source1">
<!-- reading of source 1 -->
</rdg>
<rdg source="#critApp.source2 #critApp.source3">
<!-- reading of sources 2 *and* 3 -->
</rdg>
</app>
<!-- Earlier in the document header: -->
<sourceDesc>
<source xml:id="critApp.source1">
<!-- bibliographic description of source 1 -->
</source>
<source xml:id="critApp.source2">
<!-- bibliographic description of source 2 -->
</source>
<source xml:id="critApp.source3">
<!-- bibliographic description of source 3 -->
</source>
</sourceDesc>The @seq attribute may be used on lem or rdg to record the sequence of a series of readings. In the following example, the material in source B is marked as sequential to (and perhaps derived from) the reading in source A:
<app>
<rdg seq="1" source="#critApp.sourceA">
<!-- material in source 1 -->
</rdg>
<rdg seq="2" source="#critApp.sourceB">
<!-- material in source 2 -->
</rdg>
</app>If a source has additional content that is not found in other sources, an empty rdg element may be used to indicate the lack of material in the other sources. In the following example, source 1 includes material that is not found in sources 2 and 3:
<app>
<rdg source="#critApp.source1">
<!-- additional content of source 1 -->
</rdg>
<rdg source="#critApp.source2 #critApp.source3"></rdg>
</app>When working with a large number of sources, it might seem tedious to provide references for all sources. However, use of the rdg element without @source is not recommended because such an encoding is not explicit and is therefore difficult to process.
The app element may be used to accommodate textual variation at nearly any point in a musical text. For example, it may be used to indicate minor differences such as stem directions:
<layer>
<!-- preceding notes -->
<app>
<rdg source="#critApp.source1">
<note dur="2" oct="4" pname="b" stem.dir="down"></note>
</rdg>
<rdg source="#critApp.source2">
<note dur="2" oct="4" pname="b" stem.dir="up"></note>
</rdg>
</app>
<!-- following notes -->
</layer>or to indicate more significant differences, such as the insertion of extra measures:
<section>
<measure></measure>
<measure></measure>
<app>
<rdg source="#critApp.source1"></rdg>
<rdg source="#critApp.source2">
<!-- source 2 has 2 measures not found in source 1 -->
<measure></measure>
<measure></measure>
</rdg>
</app>
<measure></measure>
</section>However, the flexibility in the location of app places a burden on the encoder to ensure that the app, rdg, and lem elements are used correctly; that is, the content of every rdg and lem has to be a valid replacement for its parent app.
In addition to its use for differentiation of the musical content of multiple sources, app may also be utilized to describe the layout of different scores, even when the musical content itself remains the same. An example of this is two sources that have the same content, but a different ordering of staves on which the content is written. By definition, the order of staves is derived from the order of staffDef elements in scoreDef, not from the order of staff elements within a measure. The staff element in a measure points to its corresponding staffDef using either 1) the same value for @n on both elements, or 2) a value in @def which is an explicit reference to a particular staffDef using its @xml:id value.
When using the first of these two approaches, it is possible to point dynamically to the correct staff definition for a given source. The following example demonstrates how this can be accomplished for two sources, both presenting a two-staff score, but with differing staff order. No further app element is necessary within the measure to describe the alternative score order of the sources.
<score>
<app>
<rdg source="#critApp.source1">
<scoreDef>
<staffGrp>
<staffDef n="1"></staffDef>
<staffDef n="2"></staffDef>
</staffGrp>
</scoreDef>
</rdg>
<rdg source="#critApp.source2">
<scoreDef>
<staffGrp>
<!-- The order of <staffDef> elements defines score order, not its @n attribute! -->
<staffDef n="2"></staffDef>
<staffDef n="1"></staffDef>
</staffGrp>
</scoreDef>
</rdg>
</app>
<section>
<measure>
<staff n="1"></staff>
<staff n="2"></staff>
</measure>
</section>
</score>When unique values for @n on layerDef and layer are provided, it is possible to reallocate layers in the same fashion as staves.
This mechanism may also be used to describe not only differing page orientations, formats and margins, but also clefs and keys.
In some situations, musical sources will agree at one level while differing at a lower level. For these cases, app elements may be nested to any level necessary. In the following example, there are three sources, two of which agree on the addition of a measure, but differ in the content of the added measure:
<measure></measure>
<app>
<rdg source="#critApp.source1"></rdg>
<rdg source="#critApp.source2 critApp.#source3">
<!-- whereas source1 omits it, source2 and source3 have an additional measure -->
<measure>
<staff>
<layer>
<app>
<!-- while source2 provides a measure rest, source3 has a whole note -->
<rdg source="#critApp.source2">
<mRest></mRest>
</rdg>
<rdg source="#critApp.source3">
<note dur="1" oct="3" pname="g"></note>
</rdg>
</app>
</layer>
</staff>
</measure>
</rdg>
</app>
<measure></measure>When nesting app elements, it is important that the value(s) in the child rdg element’s @source attribute must be a strict subset of the ancestor rdg element’s @source value.