[MEI-L] Events inside events

[Johannes Kepper]

As I mentioned earlier, here is an eMail that Perry wrote last year. We've never discussed his proposal so far, and his initial intention was to bring this to MEI-L. I modified only the beginning and end, there's no comment from me yet (I will "respond" to this in another mail).

------- 


Currently, a few elements (bend, gliss, mordent, trill, turn, note, ineume, uneume are the most pertinent ones here) permit other events in their content, e.g.,

<turn>
 <note/>
 <note/>
 <note/>
</turn>

The original purpose of this was to allow for interpretative data to be record "in-line".  This preceded the introduction of the editorial elements, such as app and choice.  Now that we have these elements (app and choice), I believe allowing event content in these situations is not only redundant, but confusing.  It immediately raises a question of whether to encode the interpretative info directly inside, say, the turn element (as above) or use 

<choice>
 <orig>
   <turn></turn><!-- capture of the turn symbol -->
 </orig>
 <reg>
   <note/><!-- interpretation of how to perform the turn -->
   <note/>
   <note/>
   <note/>
 </reg>
</choice>

when marking up a single source, or if the turn and its "resolution" exist in different sources

<app>
 <rdg source="A">
   <turn/>
 </rdg>
 <rdg souce="B">
   <note/>
   <note/>
   <note/>
   <note/>
 </rdg>
</app>

In some cases; that is, in diastemmatic neume notation, such as Solesmes, this feature is still necessary in order to record the actual, uninterpreted pitch values of the neumes. It has also already been used to capture interpreted pitch values in non-diastemmatic neume notation, such as for Hildegard's works. Although this last use might be worth to reconsider, we can't disallow it for earlier, unheighted notation if we allow it for diastemmatic neumes.

In spite of the fact that removing the feature doesn't completely remove any possibility of its mis-use, I think it should be removed for elements in the CMN repertoire (bend, gliss, mordent, trill, turn, note).  This will steer users toward a "proper" encoding using <app> and <choice>.

This is a significant enough change (much like the camelCasing of element names) to warrant making it now rather than later.  I don't want to make any change to the source file now, but I think it should be done for the next release.

Comments?

--
p.


--------------

Johannes again. What I wanted to add is that this discussion may not aim at changing the upcoming 2012 release, as the schema for this has already been fixed by a Council decision. What we can do now is to announce future changes in the 2012 Guidelines we're currently writing. I think a discussion of this thread is desperately needed, but we need to be clear about the schedule for any changes we might come up with.

Johannes