Replies: 4 comments
-
Just a quick note: Duplicate attributes on the same element is not valid XML. |
Beta Was this translation helpful? Give feedback.
-
The slur "looks" the same, but the start notes are not the same notes, so I'd say they are actually different slurs (so using |
Beta Was this translation helpful? Give feedback.
-
To me, options 2 and 3 are the best. Option 1 is problematic for the reasons you outline. Option 4 is problematic because multiple attribute values are not understood as a choice, but as a requirement. That is, any processor must try to resolve both. It will also cause problems with renderers since the slur will point to an ID that will not exist in the DOM. Option 5 is not valid XML as I said. |
Beta Was this translation helpful? Give feedback.
-
I am suggesting to make this a discussion. Anybody would prefer not to? |
Beta Was this translation helpful? Give feedback.
-
While working on the encoding of Critical Apparatus and Editorial Markup for the Digital Mozart Edition, I encountered a structural problem arising from the "dual" separation of elements in Events and ControlEvents: When ControlEvents refer to Events encapsulated in child elements of an
<app>
(Critical Apparatus) or a<choice>
(Editorial Markup) element, redundant duplication of the ControlEvent is necessary even if the ControlEvent is not involved in the<choice>
or<app>
of the Event.Example: Mozart, KV 165/1, m. 35, Oboe I-II, rhythm correction (Events) without changing the slur (ControlEvent) in Oboe II:
Editor’s correction (
<corr>
):Mozart’s autograph (
<orig>
):Since the first note in Oboe II (a') requires two different xml:ids for the two child elements
<corr>
and<orig>
(here in our DME example "note_9714-A" for<corr>
and "note_9714a-A" with the letter "a" added to the number for<orig>
), the corresponding<slur>
must also be duplicated to point to both xml:ids (@startid="#note_9714-A"
for<corr>
and@startid="#note_9714a-A"
for<orig>
):Click to see the complete MEI file.
The duplication of the slur for
@layer="2"
is obviously redundant, since we have only one slur here for Oboe II. However, the slur would disappear in the rendering of one of the two child elements of<choice>
if the ControlEvent were not duplicated (here for example in Verovio):So we are forced to duplicate the slur.
The same problem affects
<app>
.This is a relevant issue for the encoding of critical editions in MEI, since many variants (
<app>
) or editorial interventions (<choice>
) only affect events (e.g. notes) without involving ControlEvents (e.g. slurs, trills etc.). So I hope that someone will have the patience to read through this long issue and help find a solution.Here some possible solutions that are not yet fully satisfactory.
1. Duplication of the
<choice>
elementThe solution we actually use in the DME is to also encapsulate the ControlEvent in a
<choice>
or<app>
element:Click to see a partial code of the MEI file.
However, this solution is problematic for two reasons:
<slur>
that doesn’t exist: nothing has been corrected here, there is no difference between "original" and "correction" for the slur. The correction only affects the notes, not the slur.<choice>
element of the ControlEvent must be ignored when processing the<choice>
element of the Event. If this doesn’t happen, the ControlEvent will be rendered incorrectly along with the Event (see the unnecessary colour highlighting of the slur in the rendering by MoVi: there is no difference between the two slurs here, it is the same slur, so the slur should not be highlighted):(To help the processing one could add e.g.
@type="noshow|hide|secondary"
in the<choice>
of the ControlEvent<slur>
, but it would be better to avoid this addition.)2. Marking the duplicated ControlEvent as
@sameas
or@copyof
Another possible solution is to mark the duplicated
<slur>
with@sameas
or@copyof
:Click to see a partial code of the MEI file.
@sameas
seems to me to be better than@copyof
for its definition ("Points to an element that is the same as the current element but is not a literal copy of the current element."), as the slur with@sameas
points through the@startid
to another@xml:id
, so that the second slur "is not a literary copy of the current element". However, I am not sure if this is an appropriate use of@sameas
(see the issue #1056). And if we consider that the<slur>
is the same in the same part (layer="2"
) regardless of the different pointers due to the doubling of the notes in the<choice>
element, it might be better to use@copyof
here. Moreover, you need to encode@startid="#note_9714a-A"
in the "sameas-slur" to make sure that it points to the corresponding note, so that this solution doesn't seem like a real win.3.
@tstamp/@tstamp2
instead of@startid/@endid
Using
@tstamp/@tstamp2
instead of@startid/@endid
seems to be a simple solution to avoid the doubling of the slur:This solution seems to me to be too "messy" (regardeless of the inconsistency with the other slurs encoded in the file with
@startid/@endid
) as the slur could hang around somewhere (even if you add@curvdir
), especially if you change the rendering between two musical readings and if you have different layers in the same staff as in our DME example.Two other solutions would require changes to the MEI Guidelines:
4. Duplication of the value in
@startid
and@endid
A small change in MEI would be to allow multiple values in the
@startid
and@endid
pointers, so that the same slur can point to different notes, in our example two values in the@startid
for the two notes in<corr>
and<orig>
:This solution is however very problematic because it doesn’t fix the order of the two (or more) values in the pointers. This problem becomes clear when we consider the (quite common) case where both notes pointed by the slur have been encoded with different
xml:id
s in<choice>
:Click to see the complete MEI file.
The double values in
@startid
and@endid
of<slur>
can only be processed if the order of the values is clear: #note_9714-A to #note_9729-A for the slur in<corr>
or #note_9714a-A to #note_9729a-A for the slur in<orig>
, BUT NOT #note_9714-A to #note_9729a-A or #note_9714a-A to #note_9729-A.5. Duplilcation of the
@startid
and@endid
attributeAnother more radical solution which I think would fit good, would be to fix the order of the pointers in
<slur>
through multiple@startid
and@endid
attributes, similary to@tstamp
and@tstamp2
:@startid2
,@startid3
,@startid4
etc. and@endid2
,@endid3
,@endid4
etc., in our last example:This solution seems to be the more consistent one, but I see a very radical modification of MEI here, as we would allow multiple
@startid
and@endid
attributes. In the case of an<app>
with many variants (<rdg1><rdg2><rdg3>
etc.) we would need multiple@startid
and/or@endid
for multiple variants:@startid
,@startid2
,@ startid3
and/or@endid
,@endid2
,@endid3
etc. in a single<slur>
).I look forward to any comments, criticisms and suggestions!
Beta Was this translation helpful? Give feedback.
All reactions