[WIP] ornamentation

[pfefferniels]

This PR adds elements and attributes for ornamentation. It's still work in progress. Some questions for now:

• should frame.start and frame.end (and their physical equivalents) get their own general attribute classes?
• what about intensity? (It's used with a similiar meaning in rubatoDef)
• should note.order be available in both, ornamentDef (in header) and ornament (in dated)?
• should the operator definitions (temporalSpread and dynamicGradient) used inside ornamentDef be available in ornament as well? (we discussed it, but I can't remember anymore to which conclusion we came).

Still missing:

• schematron constraints e.g. for the start and end attributes (start < end)
• make physical and symbolic start/end definitions exclusive
• add attributes noteids and note.order (see above)
• description of everything for the guidelines

[pfefferniels]

Should it be possible to define only frame.end, assuming that frame.start will be 0, or must both attributes be present? @axelberndt

[axelberndt]

Both attributes (frame.start and frame.end and also their milliseconds counterparts) are optional with a default value of 0.0. Schematron should make sure that values don't clash if some are not defined explicitly.

[pfefferniels]

Sorry for the long silence here. We did decide to have note.order either being a list of note ids or "ascending pitch"|"descending pitch". However, I'm not sure how to implement multiple possible datatypes (anyURI or a closed list) in ODD.

At the moment it only takes a closed list:

<tei:classSpec ident="att.note.order" type="atts" module="mpm.core" mode="add" xmlns:tei="http://www.tei-c.org/ns/1.0">
    <tei:gloss>note order attribute class</tei:gloss>

    <tei:desc>This attribute class provides the attribute <tei:att>note.order</tei:att>.</tei:desc>

    <tei:attList>
        <tei:attDef ident="note.order" usage="opt">
            <tei:gloss>note.order attribute</tei:gloss>
            <tei:desc>This attribute defines the order of notes e.g. inside an arpeggiation. It can take the values "ascending pitch", "descending pitch" or a list of ids specifying the exact order of notes.</tei:desc>
            <tei:defaultVal>ascending pitch</tei:defaultVal>
            <tei:valList type="closed">
                <tei:valItem ident="ascending pitch"/>
                <tei:valItem ident="descending pitch"/>
            </tei:valList>
        </tei:attDef>
    </tei:attList>
</tei:classSpec>

[axelberndt]

Make the datatype just <tei:dataRef name="string"/>. Then use Schematron to check if it is one of the predefined strings or a sequence of IDs. Since the IDs refr to another file (MSM), you do not need to check their validity, only the "wellformedness" (each ID should start with a # and be space separated).

[pfefferniels]

@axelberndt frameLength in rubatoDef only allows values greater than 0.0 (exclusive). Should this apply to frameLength in temporalSpread as well?

[axelberndt]

In temporalSpread it should be inclusive 0.0.