Hi evbdy!<br>Discussing the lacking possibility to aggregate multiple app elements by means of an attribute, which could be very handy indeed, I'd like to put into consideration that @prev and @next imply an order. This might exactly be what One is looking for, especially when thinking of genetic editions, but something like @corresp might be more applicable in other situations.<br><br>Cheers,<br>Benjamin<br><br><br><br><br>----- Reply message -----<br>Von: "TW" <zupftom@googlemail.com><br>An: "Music Encoding Initiative" <mei-l@lists.uni-paderborn.de><br>Betreff: [MEI-L] More "precise" <app>s<br>Datum: So., Jul. 15, 2012 21:27<br><br><br>Hi Raphaele,<br><br>2012/7/15 Raffaele Viglianti <raffaeleviglianti@gmail.com>:<br>> Though if I understand Thomas' issue correctly, he's also interested in<br>> encoding the fact that the two apps can form one apparatus entry.<br>><br><br>Exactly.<br><br>><br>> A use case for using @prev and @next would be to be able to generate the<br>> apparatus entry above from the encoding (I have seen this done in TEI).<br>><br><br>Thanks for the hint.  I see that TEI's <app> (and also <choice>)<br>indeed have @next and @prev.  I think I'll create a feature request<br>issue.<br><br>And yes, I'm thinking about the automatic generation of apparatus<br>entries.  It would be messy to have things chopped up in multiple<br>entries that actually are logically one entry (like one entry for<br>measure 1 and a second one for measure two of the flute, although they<br>form one melodic phrase together).  It would be equally messy to get<br>one huge entry that contains a lot of "noise" (like a two measure<br><app> that presents the whole orchestra, although only the flute<br>varies).<br><br>Wish you a good start into the week ahead<br>Thomas<br><br>_______________________________________________<br>mei-l mailing list<br>mei-l@lists.uni-paderborn.de<br>https://lists.uni-paderborn.de/mailman/listinfo/mei-l<br>