[MEI-L] Events inside events

[Johannes Kepper]

Hi Perry,

ah, that was the mail I had in mind originally. As there seem to be no strong opinions on this topic, I wonder if we should start a survey on the use of these features. For the [i|m|t][1-6] attributes, a similar approach could be helpful. My only concern is that after having checked the subscribers of MEI-L recently I noticed that I had a lot of questions about MEI from people not subscribed. There might be a user base that we cannot reach easily. Suggestions for this, anyone?

Does anyone know a good and free survey service? surveymonkey.com seems to be limited to 100 responses without additional fees. I don't expect that we cross that border, but who knows…

Best,
Johannes




Am 08.03.2012 um 16:00 schrieb Roland, Perry (pdr4h):

> Thanks, Johannes,
> 
> For bringing this up again.
> 
> I sent another message recently to MEI-L and MEI-developers, but perhaps it didn't get through -- see below.
> 
> --
> p.
> 
> ________________________________________
> From: Roland, Perry (pdr4h)
> Sent: Thursday, March 01, 2012 5:16 PM
> To: mei-l at lists.uni-paderborn.de; MEI Developers
> Subject: eventLike in bend, gliss, mordent, etc.
> 
> Hello all,
> 
> Please pardon the duplication if you get this message more than once.
> 
> Elements in the model.eventLike class --
> 
> barLine, beam, beatRpt, bend, bTrem, chord, clef, clefGrp, custos, fTrem, gliss, halfmRpt, ineume, keySig, ligature, mensur, mRest, mRpt, mRpt2, mSpace, multiRest, multiRpt, note, pad, proport, rest, space, tuplet, uneume
> 
> were allowed to occur in selected eventLike elements --
> 
> bend, gliss, mordent, trill, turn, note
> 
> in earlier versions of MEI that didn't yet have the ability to encode multiple readings.  Now that MEI does have <app> for dealing with multiple readings, having this "event within event" structure is redundant and confusing.  I think we need to kill off this dinosaur.
> 
> Since the next release of MEI has already been frozen with regard to the addition / deletion of features, I propose to add documentation that deprecates this feature even though it will technically be allowed.  Of course, in the next-next release this feature will be disabled.
> 
> Any objections?  Is anyone using this?  Going, going, ...
> 
> Best wishes,
> 
> --
> p.
> 
> __________________________
> Perry Roland
> Music Library
> University of Virginia
> P. O. Box 400175
> Charlottesville, VA 22904
> 434-982-2702 (w)
> pdr4h (at) virginia (dot) edu
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l