[MEI-L] feature request list (long)

[Byrd, Donald A.]

Perry et al, I have a request about terminology. I think confusion over 
terms like "feature list" and "requirements" have caused a lot of 
problems. We've agreed (I believe) that what Eleanor, Joachim, and I 
have been talking about is not a "requirements specification" but a 
"feature list" -- but here you're (understandably) using the term 
"feature list" for something rather different! So I suggest we call 
your list a "TECHNICAL feature list", and ours a "NOTATION feature 
list". How's that sound? (And Eleanor and Joachim, I promise to send 
you another proposal to resolve our issues within a few days :-) .)

--Don


On Tue, 30 Mar 2010 14:26:14 -0400, "Roland, Perry (pdr4h)" 
<pdr4h at eservices.virginia.edu> wrote:

> Hello, everyone,
>
> Since returning from Detmold I've been working on resolving issues on
> the feature request list.
>
> To refresh your memory, here's the list as it stood in Detmold:
>
> 1. add @type on graphic
> 2. add "within" in data.PLACE
> 3. create "non-sung text" element in order to accommodate spoken dialog
> 4. allow app in tuplet (beam too)
> 5. allow value "unknown" for @grace
> 6. allow controlevent-like attributes (@staff, @tstamp, etc.) on artic
> 7. 2mei should create tie elements in addition to/rather than @tie
> attributes; 2mup should convert tie elements to Mup curve statements
> 8. create history element containing a list of events
>
> I'm happy to report that nos. 1, 2, 4, and 5 have been resolved.
>
> The only item that caused any backward compatibility issues was no.
> 2.  Since the value "within" wasn't appropriate in all cases, I added
> 2 new datatypes, data.OTHERSTAFF and data.STAFFREL.
>
> data.PLACE provides for general placement of notational elements
> relative to other notational elements, for example, placement of
> tuplet brackets and numbers, octave displacement, and clefs with
> octave symbols.  The permitted values are 'above' and 'below'.  I
> suppose this list of values could be expanded at some point with
> 'beside', 'left', 'right', etc. although I can't see how these would
> be useful to a renderer.  (Writing this explanation, I realize that
> perhaps octave displacement belongs in its own category. But that's a
> fix for another time.)
>
> data.OTHERSTAFF is used for musical material designated to appear on
> another staff, the location of the staff relative to the current one;
> i.e., the staff above or the staff below.  For example, when a beam
> crosses staves or a chord lies on more than one staff.  The values
> here are also 'above' and 'below'.
>
> data.STAFFREL is for specifying the location of musical material
> relative to a staff.  The values allowed here are 'above', 'below',
> and 'within'.  The elements that permit these values of place are:
> artic, breath, dir, dynam, fermata, hairpin, harm, harppedal, lyrics,
> mordent, pedal, reh, tempo, trill, and turn.  It's up to a processing
> application to figure out what 'within' actually means.
>
> Items 3 and 6 require more extended discussion than I think we can
> accomplish by the deadline so I'd like to defer those until after the
> first release.
>
> Item 7 isn't really an MEI feature request.  It has to do with the
> XSLT transform from MusicXML to MEI.  I'll handle this one once the
> MEI schema is settled and I take up the issue of MEI import/export
> via XSLT.
>
> Finally, item 8.  Johannes and I propose adding eventlist, event, and
> eventdesc elements.  From the attached .odt file:
>
> "Eventlist contains historical information given as a sequence of
> significant past events. <eventlist> contains <event> elements that
> pair a date or date range with a brief description of the associated
> event and locations where the event took place. An <eventlist>
> describes events associated with a work when it appears in the
> <profiledesc> element or events associated with the custodial history
> of a given copy of a source for the encoding when it appears within
> the <source> element.
>
> Event groups a date, a description of the event related to the date,
> and optionally, any number of places where the event took place.
>
> Eventdesc describes or names something that happened."
>
> Usage examples:
>
> <profiledesc>
>  <eventlist type="composition">
>    <event>
>      <date reg="1812-03-25"/>
>      <geogname>My Little Town</geogname>
>      <eventdesc n="composition">
>        Completed sketch
>      </eventdesc>
>    </event>
>    <event>
>      <date reg="1812-06-26"/>
>      <eventdesc n="dedication">Dedicated to <persname>his
> wife</persname>.</eventdesc>
>    </event>
>    <event>
>      <date reg="1813"/>
>      <eventdesc>Published</eventdesc>
>    </event>
>  </eventlist>
>  <eventlist type="reception">
>    <event>
>      <date reg="1814-04-01"/>
>      <geogname>The State Theater</geogname>
>      <eventdesc>1st performance</eventdesc>
>    </event>
>    <event>
>      <date reg="1814-04-01"/>
>      <eventdesc>1st bad review</eventdesc>
>    </event>
>  </eventlist>
> </profiledesc>
>
> <provenance>
>  <eventlist>
>    <event>
>      <date notafter="1985">until 1986</date>
>      <eventdesc>Weber family </eventdesc>
>    </event>
>    <event>
>      <date notbefore="1986">1986-</date>
>        <eventdesc>owned by the <repository>Berlin State
> Library</repository></eventdesc>
>    </event>
>  </eventlist>
> </provenance>
>
> <profiledesc> allows multiple lists, hence the need for @type to
> distinguish them.  <provenance> on the other hand only allows a
> single list.
>
> Within profiledesc, creation permits a "text-y" description of the
> creation of the work, while eventlist offers a more structured, more
> easily machine-processed approach.  Either or both are permitted.  In
> provenance, however, one method must be selected.
>
> Notice that event permits only a single date element.  This can
> contain a single date or a date range.  However, an event cannot have
> multiple, discontinuous dates.  In our estimation, this situation
> implies multiple events.
>
> If you have comments, please respond to the list.  If there are no
> comments by April 9, I will assume these solutions are satisfactory.
> On the other hand, there's a lot of discussion but no agreement by
> April 9, we will have to delay these issues until a later release.
>
> Best wishes,
>
> --
> 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



--
Donald Byrd
Senior Scientist
Adjunct Associate Professor of Informatics & Music
Indiana University, Bloomington