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.
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:
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:
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:
or to indicate more significant differences, such as the insertion of extra measures:
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.
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: