[MEI-L] tupletspan, @tuplet, @beam

[TW]

Hi all,

it's me getting on your nerves again.  Working on a MEI-consuming
application, I encountered some difficulty especially with tupletspans
that I'd like to report.  Reading the specs I understand that the
starting point can be defined using @startid, @tstamp, @tstamp.ges and
@tstamp.real.  @startid is pretty clear, @tstamp is also fairly clear,
but requires more processing effort to find the first element.  For
@tstamp.ges it's probably similar to @tstamp.  To find the last
element, there needs to be an @endid, @dur or @dur.ges.  Again, @endid
is pretty clear, but @dur and @dur.ges are only reliable if both @num
and @numbase are set on the tupletspan, and the layer elements that
the tupletspan belongs to must be somehow identifiable.  I guess this
can be done by giving the layers the same @n attribute, pointing to
the next layer or note/rest/chord using @next on the previous layer or
it's last note/rest/chord.  Or if there is only one layer.  If @num
and @numbase weren't set, there is no way of telling at what
note/rest/chord the tupletspan is "full", because the durations are
given as if they weren't part of a tuplet and there is no
"time-modification" element or attribute on notes like in MusicXML.
@num and @numbase take the role of MusicXML's time-modification
element, but they are optional and can't be relied on.  I couldn't
find @tuplet attributes being mentioned in the tuplet and tupletspan
documentation, so I'm not sure what role they are meant to play.  They
can of course help to identify what elements belong to a tupletspan,
but if that's their purpose, I'm wondering why they aren't of type
IDREF, or IDREFS for the sake of nested tuplets.

On the other hand, if @endid is given, but no @num *and* @numbase,
then the actual duration of the notes/chords/rests can't be determined
with certainty.  If @endid and @dur are set however, this is possible.

Is it possible that stricter rules could be established to make sure
that a MEI consuming application will be able to make sense of what an
encoding application or a human have produced?  In the case of
tupletspans, even if all prerequisites are met, I find them
unnecessarily hard to process as there is a large number of sensible
combinations - and I'm not even sure whether I identified all of them.
 There is also a big chance of unintentionally encoding things
sloppily so that the data is fuzzy while it really needn't be.

Still being a "rookie" who doesn't have a sound overview concerning
MEI and all its fields of application, I might be approaching this a
bit too naive.  But what speaks against enforcing IDREF(S) @tuplet on
elements that are part of a tupletspan and make all the other
start/end attributes optional?  It would be easy as pie to identify
all elements that belong to the tupletspan.  The compression (in
seldom cases maybe expansion) ration would then be clear from either
@num and @basenum or @dur and the sum of "visual" durations of
elements associated with the tupletspans.  If the music is unclear,
then the encoding will of course be unclear, but if it's clear, I'd
expect the encoding to be clear as well.

Thomas Weber