[MEI-L] typable events

Roland, Perry (pdr4h) pdr4h at eservices.virginia.edu
Wed Aug 7 23:29:42 CEST 2013

Hi everyone,

Sorry for joining the conversation late.  I'm at the Balisage conference in Montreal where MEI appears to be already known and appreciated by several participants.  Hooray!

The lack of the att.typed class on members of model.event was a deliberate choice.  The intention was to head off abuse of @type and @subtype.  My statements about using these attributes only to classify the element and not its contents, while not strictly enforceable, were also intended to get users to think about the problems that casual use of these attributes has the potential to cause.

Where appropriate elements and attributes are already available, such as <supplied> for Johannes' example, they should be used, of course.  If, after careful analysis, it's determined that extension is necessary, I'd recommend, in descending order of desirability,  1) additional elements and/or attributes in a private namespace, then 2) @type and @subtype.  Formal customization should be considered first since it is fairly easy to accomplish with ODD & Roma and it gives you the opportunity to make your intention absolutely clear -- with beautiful, well-written documentation.  :-)

Addressing Thomas' suggestion, it's not technically difficult to globally allow the use of attributes and elements from an unknown namespace in RNG, but I can't say with confidence whether/how that can be accomplished in ODD.  I agree with Thomas' final comment, however, that allowing such additions subverts the use of formal customization for extension.  I'm reluctant to open that particular door.


Perry Roland
Music Library
University of Virginia
P. O. Box 400175
Charlottesville, VA 22904
434-982-2702 (w)
pdr4h (at) virginia (dot) edu
From: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of TW [zupftom at googlemail.com]
Sent: Wednesday, August 07, 2013 12:46 PM
To: Music Encoding Initiative
Subject: Re: [MEI-L] typable events

2013/8/7 Johannes Kepper <kepper at edirom.de>:
> [...] I see your point about inviting abuse when making @type more general available, and I guess I'm willing to follow that argument. However, I'm less convinced that @label is actually a better solution for my needs. Since I'm saying something _about_ my MEI, I wonder if an attribute in a private namespace might be an option? This would break validity (unless I change my MEI accordingly), but it would be clearly something said from "outside", without pretending to be my final MEI…

As adding temporary data to MEI files that is intended for further
processing steps seems not too uncommon (at least we do it and you do
it), maybe one could introduce something like HTML5's data-*
attributes[1] that give more flexibility, circumventing the need to
abuse existing structures for inappropriate purposes?  Probably
elements will work better than attributes, though.

One suggestion for your application could be

    <space xml:id="d6d3e1117" corresp="#d1e2682" dur="4">
        <tempData type="finalefix">
            <tempData type="sharedLayer">1</tempData>
            <tempData type="sharedElement">rest</tempData>

or, given we allow the fictional tempData element to be given
arbitrary attributes (possibly making @type mandatory):

    <space xml:id="d6d3e1117" corresp="#d1e2682" dur="4">
        <tempData type="finalefix" sharedLayer="1 "sharedElement="rest"/>

That's probably cleaner than something more along the lines of HTML5
@data-* like

    <space xml:id="d6d3e1117" corresp="#d1e2682" dur="4"
        tempData-sharedLayer="1" tempData-sharedElement="rest"/>

although avoiding additional elements might might make things easier
for some applications.  In any case I fear that wilcard attribute
names like @tempData-* would not even be specifiable with ODD.

Speaking of ODD: Of course one would have to find good arguments for
introducing elements or attributes like this rather than creating an
ODD modification.

[1] http://www.w3.org/html/wg/drafts/html/master/dom.html#embedding-custom-non-visible-data-with-the-data-*-attributes

mei-l mailing list
mei-l at lists.uni-paderborn.de

More information about the mei-l mailing list