[MEI-L] feature request list (long)

[Roland, Perry (pdr4h)]

Comments interleaved below --

Joachim:
>> 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)

Johannes:
> 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…

Yes, this is dangerous territory indeed and one of the major reasons I'm not too
fond of even adding the "within" value.  The most important questions to answer
are Which staff is the text attached to?  and What is the position of the text relative
to that staff?  The first answer is encoded in the staff attribute, while the second is
in the place attribute.  'Above' and 'below' provide basic attachment info.  More
detailed placement info. can be recorded in @ho, @vo, etc.  The horizontal starting
point for these offsets is either 1) a timestamp, such as beat 1, beat 3.5, etc. or 2) the
timestamp of another notational feature, given in the startid attribute, e.g.,
startid="note1" means the same timestamp as the note designated "note1".  The
vertical starting point of directives can be set using @dynam.dist, @harm.dist, and
@text.dist on the scoredef element.

It must be remembered, however, that these settings are all relative.  That is, they are
subject to change depending on what must be rendered nearby.  If precise locational
information is needed, then one should use the facs attribute to point to regions in a
given image.  One might be tempted to @x and @y attributes.  However, these are
for output coordinates.  That is, they record where the feature is *going to be* in the
rendered output.

Joachim:
>> 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???

Johannes:
> 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. 

Actually, <div> is also permitted between sections. Other than this, Johannes'
description is accurate.  This is exactly how text that's not part of the music
per se should be treated.

Joachim:
>> - 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)

Johannes:
> 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…

Again, Johannes is right.  Such a thing is technically possible, but it makes no
sense.  The question is How far must we go in keeping users from making
nonsense?  Schematron might provide an answer.  It is also up to MEI-producing
software to head off potential problems.

--
p.

__________________________
Perry Roland
Digital Curation Services
University of Virginia Library
P. O. Box 400155
Charlottesville, VA 22904-4155
434-982-2702 (w)
pdr4h at virginia.edu