<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
>I agree. An "inputting environment" might want to offer the<br>
>convenience notation and extend them "automatically". I don't know<br>
>whether this is a sensible suggestion, but what about moving<br>
>convenience features to a module of their own so they can easily be<br>
>enabled/disabled? (Am I opening another can of worms?)<br></div></blockquote><div><br></div><div><div>This seems to be over the top for me. I think we should take a decision and I would vote for deprecating them. It does not have to be within 5 minutes, but the earlier the better (10 minutes?). Once we will have tools relying on them, we will have votes against deprecation, which does not seem to be the case now - actually, I already use them but would not mind shutting up if it can allow some simplification.</div>
<div> </div><div>Now for the trill, I my understanding correct that we would expect this encoding</div><div><br></div><div><trill></div><div> <note /></div><div> <note /> </div><div> <note /></div>
<div></trill></div><div><br></div><div>to be used for encoding the realization of the trill, and that</div><div><br></div><div><note id="123" /></div><div><trill startid="123" /></div>
<div><br></div><div>to be used for encoding the note (as written) with its ornament?</div><div><br></div><div>I guess one would rather (or also) use .ges attributes for encoding its realization, but using the first one with only the written note seems awkward to me because logically, I see a note with a trill and really not a trill with a note. It is significantly different from a chord and from a beam. Do we care about this?</div>
<div><br></div><div>Laurent</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"></div><div class="im">
<br>
__________________________<br>
Perry Roland<br>
Music Library<br>
University of Virginia<br>
P. O. Box 400175<br>
Charlottesville, VA 22904<br>
<a href="tel:434-982-2702" value="+14349822702">434-982-2702</a> (w)<br>
pdr4h (at) virginia (dot) edu<br>
</div>________________________________________<br>
From: mei-l-bounces+pdr4h=<a href="mailto:virginia.edu@lists.uni-paderborn.de">virginia.edu@lists.uni-paderborn.de</a> [mei-l-bounces+pdr4h=<a href="mailto:virginia.edu@lists.uni-paderborn.de">virginia.edu@lists.uni-paderborn.de</a>] on behalf of TW [<a href="mailto:zupftom@googlemail.com">zupftom@googlemail.com</a>]<br>
Sent: Tuesday, March 06, 2012 12:46 PM<br>
<div class="im HOEnZb">To: Music Encoding Initiative<br>
Subject: Re: [MEI-L] trills within beams<br>
<br>
</div><div class="HOEnZb"><div class="h5">2012/3/6 Roland, Perry (pdr4h) <<a href="mailto:pdr4h@eservices.virginia.edu">pdr4h@eservices.virginia.edu</a>>:<br>
> 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. :)<br>
><br>
> 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.<br>
><br>
> These features also make it somewhat easier to more-directly capture data from other systems that allow/encourage this kind of thing.<br>
><br>
> So, I would urge caution at this point. Anyone who doesn't want to use these "conveniences" shouldn't feel compelled to do so.<br>
<br>
The problem for people like me and Julian is that we don't have a<br>
choice because we have to eat what people are throwing at us. If we<br>
want to handle MEI as completely as possible, we currently would have<br>
to take into account four different ways for specifying beams<br>
(@beam.group/@beam.rest, <beam>, <beamspan> and @beam). <beamspan><br>
again has two ways of being used, @startid+@endid and @tstamp+@dur,<br>
(In theory and mathematicaly, the specs allow for twelve different<br>
combinations, but I believe that the @*.ges and @*.real attributes<br>
don't make a lot of sense and mixing IDs and time based start/end<br>
attributes can be neglected).<br>
<br>
> But I don't think that I want to rush to remove them. I think we should be thinking about canonicalization instead.<br>
<br>
I agree. An "inputting environment" might want to offer the<br>
convenience notation and extend them "automatically". I don't know<br>
whether this is a sensible suggestion, but what about moving<br>
convenience features to a module of their own so they can easily be<br>
enabled/disabled? (Am I opening another can of worms?)<br>
<br>
Thomas<br>
<br>
</div></div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
<a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
_______________________________________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
<a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
<br>
</div></div></blockquote></div><br>