[MEI-L] feature request list (long)

[Roland, Perry (pdr4h)]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eventlistDocumentation.odt
Type: application/octet-stream
Size: 18046 bytes
Desc: eventlistDocumentation.odt
Url : https://lists.uni-paderborn.de/mailman/private/mei-l/attachments/20100330/d2fd1ad6/attachment.obj