[MEI-L] Events inside events

[Laurent Pugin]

Hi Perry,

I am confused. In the following example:

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

Where is given for the original the note to which the turn applies. Am I
overlooking something? Sorry about it.

Laurent

On Wed, Mar 7, 2012 at 2:25 PM, Johannes Kepper <kepper at edirom.de> wrote:

> 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
>
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
>
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120312/d163afd5/attachment.html>