[MEI-L] feature request list (long)

[Johannes Kepper]

Hi all,

Am 01.04.2010 um 06:45 schrieb Joachim Veit:

> Hi all,
> my God, I can't hardly keep pace with all these discussions...
> Perry, many thanks for the "spoken"-text clearification!! If it is
> possible to encode that thing which you call a "directive" that's very
> fine. I am a bit puzzled by the word "directive" which reminds me only
> to "stage directions", "tempo directions" etc. - that's another thing
> and perhaps we may have a differentiation later?

see comments below, perhaps this helps a bit…

> 
> Only a few things at the moment:
> 
> 
> No. 2 from the list:
> data:PLACE: if you take 'above' and 'below' why not "left' and 'right"?
> ('beside' is neutral and you don't know which side...). It my relatively
> often occur within historic notation that some notational elements are
> not placed in their "normal" order and that we want to fix this
> abnormality. And for special details a renderer may use 'left" with a
> default value, depending from - perhaps - dynamics, strokes etc. - So
> keep the case open by adding 'left' and 'right'??? (even if some of the
> cases might be solved by data.STAFFREL)

I think it's dangerous to go down that route. What about "bottom left", "top right"? When we decide to have values like these, we need at least eight of them. I'm not sure if that is already to specific. You could encode these things by using @ho and @vo (horizontal / vertical offset), although this definitely looks less comprehensive then "left". The problem is also that the starting point for those offsets needs to be well-defined…

> 
> No. 3 from the list (see above)
> If there is something to fix a "non-sung"/"spoken" text in the sense
> which you described with Mo und Larry and you do this momentarily in the
> <dir>-element, this would be is fine. Perhaps that possibility should be
> added to the description of this element  because nobody might reckon
> with this possibilty at the moment???
> 

To clear this situation at least a little bit, I would like to provide a closer look at Raffaele's example, as it is not covered by anything discussed on the list yet. In fact, <anchoredtext> is probably the better solution for this. In Raffaele's case, we have text which is neither placed between staves nor between systems. It's a handwriting, written on pre-lined paper. On the left half of the page there are a couple of measures with a full stop at the end. Then comes a longer text that describes what's happening on stage. This text is written on the (empty) staves. After the text passage, the music starts again. Of course this text is not synchronized with the music itself, but it is sorted into the music: There is a specific order on how these parts line up in a performance. For the music "parts", it makes perfect sense to put them into a <section>. At this level, <anchoredtext> is the only text-element allowed as a sibling. If you encode

<section>some music</section>
<anchoredtext>stage text</anchoredtext>
<section>some music again</section>

you have a perfect order similar to the things in your source. The <dir> element is definitely better suited for those "in between"-texts that are closer related to the music. 


> No. 8
> HISTORY:
> - It seems to be not easy to find the line between "too easy" and "to
> complicated" - I can't decide what seems the best way without thinking
> about further examples ...
> - Concerning the "@when" or <date> discussions I plea for using <date>
> (i.e. Perry's problem with a double usage of "when" would be solved in
> this way?)
> - Johannes @function: Is it really probably that in an event from the
> type "dedication" one has to differentiate between several persons?? And
> I just see in Perry's answer that  "role" is already usable for this
> (rare) purpose
> - Besides: I fully consent with Perry's "it would be very annoying to
> encode names in TEI one way and MEI names another" (that should be valid
> for other central elements too...)

ok, let's stay with @role

> - Concerning the restriction with provenance would such a strange
> description be possible (even if I think that creation is not part of
> the provenance):
>    <provenance>
>        <eventlist><event type="creation">....</event></eventlist>
>    <provenance>
> (I am only asking this as a question of understanding the restriction)

Technically, it would be possible, but semantically it would be wrong. <provenance> allows only one <eventlist> which covers the source's provenance by definition. Perhaps we could/should use Schematron to prevent a @type on provenance/eventlist…



Johannes


> 
> Yours,
> Joachim
> 
> 
> <veit.vcf>_______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l