[MEI-L] typable events
Johannes Kepper
kepper at edirom.de
Wed Aug 7 11:58:11 CEST 2013
Dear List,
I have some issues I've found recently that I would like to discuss. Let's start with a question about typable events. In current MEI, it is not possible to use @type (att.tybable) on all events (model.eventLike), such as notes, rests, chords, spaces, tuplets, bTrems etc.
I wonder if this is intention, or if we just missed to add that class. Even if it was our intention (though I haven't found a former discussion on this), what were the arguments, and do we still think this is a necessary restriction?
The following sample may be skipped for brevity…
> My example for this is somewhat questionable in itself, so let me explain it a bit. For our Freischütz edition, we're heading off with Finale data converted to MEI via MusicXML. In the case of multiple layers on one staff, Finale clips shared events at the end of the second (and any subsequent) layer: If both layers share a rest at the end, only the first layer holds this rest, while the second is just incomplete.
>
> For several reasons, I think this is faulty behavior, and therefore add corresponding spaces by XSLT. However, I would like to keep track which spaces were contained in the original file, and which spaces were added by me. A simple @type on the latter would be perfect for me.
>
> I am fully aware that MEI offers a whole plethora of elements to indicate added, normalized, or otherwise changed content. But since this is just an intermediate step in the process of generating my data, I regard this additional markup as too complicated. I'm not sure if I will keep this information after the next step of proofreading. On the other hand, I don't want to operate on invalid data, even if it is only a temporary state.
I'm pretty sure there are simpler examples and better arguments at hand, but I hope my example makes the point. So, what do others say – should events like notes and rests be typable?
Best,
Johannes
More information about the mei-l
mailing list