[MEI-L] trills within beams

[Roland, Perry (pdr4h)]

>> 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, ...

Given the extensibility of MEI, I don't know if any software can ever handle MEI "completely".  Instead, it should declare that it uses a certain subset of MEI features and reject anything that doesn't validate against the schema that defines the chosen profile.  One of the advantages of ODD is that it facilitates the creation of these profiles.

>> 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?)

I'm not opposed to exploring this, but again we run into music's contradictions -- what is a "convenience" for some, is "essential" for others.  If we're serious about pursuing this approach, though, I think we would have to put alternatives (beam attributes and beam elements in your example) into separate modules and allow users to select between them (or turn them both on, as they effectively are now).  Of course, this will complicate the already-complex class hierarchy of MEI, making the schema more difficult to work with and harder to explain to the uninitiated.

--
p.

__________________________
Perry Roland
Music Library
University of Virginia
P. O. Box 400175
Charlottesville, VA 22904
434-982-2702 (w)
pdr4h (at) virginia (dot) edu
________________________________________
From: mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] on behalf of TW [zupftom at googlemail.com]
Sent: Tuesday, March 06, 2012 12:46 PM
To: Music Encoding Initiative
Subject: Re: [MEI-L] trills within beams

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

_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l