[MEI-L] trills within beams

[TW]

2012/3/6 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>:
> Slow down, take it easy, remain calm.  I said I could imagine a future without them, but I didn't mean in the next 5 minutes.  :)
>
> These features are very convenient for hand-encoders.  They have been frequently requested in the past and, in fact, this thread started with a request for just such a feature.
>
> These features also make it somewhat easier to more-directly capture data from other systems that allow/encourage this kind of thing.
>
> So, I would urge caution at this point.  Anyone who doesn't want to use these "conveniences" shouldn't feel compelled to do so.

The problem for people like me and Julian is that we don't have a
choice because we have to eat what people are throwing at us.  If we
want to handle MEI as completely as possible, we currently would have
to take into account four different ways for specifying beams
(@beam.group/@beam.rest, <beam>, <beamspan> and @beam).  <beamspan>
again has two ways of being used, @startid+ at endid and @tstamp+ at dur,
(In theory and mathematicaly, the specs allow for twelve different
combinations, but I believe that the @*.ges and @*.real attributes
don't make a lot of sense and mixing IDs and time based start/end
attributes can be neglected).

> But I don't think that I want to rush to remove them.  I think we should be thinking about canonicalization instead.

I agree.  An "inputting environment" might want to offer the
convenience notation and extend them "automatically".  I don't know
whether this is a sensible suggestion, but what about moving
convenience features to a module of their own so they can easily be
enabled/disabled?  (Am I opening another can of worms?)

Thomas