Re: MusicXML representation of "additional" staff

> MusicXML to date (and MEI too) have so far sidestepped this problem by making it pretty much impossible to determine what "compliance" even means, because so many elements and concepts are optional. Both encoders and developers are free to choose what they will or will not support. We can all see the results of that freedom.

I just want to clarify this point: The MEI Community has not *implemented* any strict compliance schemas (yet), but it is definitely not 'impossible' to do this, even today. In fact, the ability to do this is baked into MEI in the core of its implementation. We call them 'customizations,' which have been mentioned earlier on this list by Raffaele and Zoltan (among others), but since they seem to be exactly what Joe is describing as 'profiles' I will use that term.

For example, a developer may create an MEI profile that defines exactly what musical features are supported by her software. She can define that her software will not support floating clefs, or that it will only support it using one particular encoding structure. This profile is then used to create an XML schema (DTD, XSD, or, preferably, RelaxNG) that will validate exactly that markup. More importantly, it will fail validation if it receives anything that uses another way of encoding a particular features [1].

So while MEI "core" supports floating clefs because they exist and MEI tries to model all things you might find in music, an individual developer's MEI profile can disable support for this. An encoder can use the developer's schema to validate their encodings to ensure compliance with software. A community of developers can also collaboratively develop a profile to provide an 'ecosystem' of interoperable tools.

Supporting and disabling extended features of music notation are both valid approaches for individual use cases, and through our profiles we have a mechanism to support both within the larger MEI community. It certainly makes MEI more complex than MusicXML, but also considerably more powerful, expressive, and capable [2].

So we *can* generate restricted subsets to ensure 'compliant' MEI [3]; just because we haven't doesn't mean that it's impossible. :)

-Andrew


[1] As a point of interest, our main C++ library for reading/writing MEI files, libmei, can be auto-generated against an MEI customization. We use this as a method of strict type checking: A "<note />" element is translated to a Note C++ class. If we try loading a file with a foreign tag for that encoding (e.g., one containing the '<neume />' element), it will raise an exception since it cannot instantiate a corresponding Neume object. It's one more mechanism for us to ensure that software loads only encoded files that the software can support.

So our fictional developer can, in essence, compile their software against their profile's schema, so that the software itself can raise an exception if a user tries to load an unsupported encoding.

[2] A further tool that we are increasingly making use of is 'Schematron,' which is a second type of XML validation. Regular XML validation will validate the presence or absence of an element or attribute, as well as its value. Schematron, however, can be used to write logical structure rules; for example, a Schematron rule we have is that you cannot have a <staff> element that has not previously been declared in a '<staffDef>' section. Or you cannot declare that a slur ends on a note that does not exist, even if these two elements are not related hierarchically in the XML output.

[3] To see how this might look, check out our 'customizations' directory:

https://github.com/music-encoding/music-encoding/tree/develop/customizations <https://github.com/music-encoding/music-encoding/tree/develop/customizations>

You will notice there are profiles for the three main families of notation we support: CWMN, Mensural, and Neume notation. (The 'MEI All' profile is really just having everything turned on, which is the most lax schema option available, and may be why it appears as though MEI supports everything). So a schema generated against the 'Mensural' profile will fail validation on an encoded 'slur' element because this element is not available in the mensural profile. 

If you look in the profile files themselves you will see that they are pretty simple at the moment. Because MEI is implemented in a modular manner, generating a mensural profile is accomplished by disabling the modules that contain definitions for invalid elements and attributes (like 'slur.') However, a customization can also add/remove/change individual attributes and elements, so we can modify the definition of '<note />' to disallow child '<dot />' elements. We then generate the schema by running this through a customization tool (the TEI "Stylesheets").

> 
> I'd like to propose a different way of thinking about this. I'm not trying to argue that, say these floating clefs either are, or are not, "authentic Western music notation". But we can probably agree on several uncontroversial facts:
> 
> - Floating clefs are not standard. They are pretty unusual and he number of such cases in the literature is small.
> 
> - The cost to software developers of supporting arbitrary clef/note associations is substantial (and is the reason why notation software generally doesn't this case, not because of MusicXML). This expense is **not the expense of merely encoding floating clefs**. It is the expense of authoring features that would allow engravers to specify these associations, and engraving features that would allow such clefs and notes to be shown and positioned properly under many varying circumstances.
> 
> - There are alternative ways to notate such cases (e.g. adding extra staves to a part as needed, bearing the additional clef)
> 
> Now, I talked in Frankfurt about Encoding Profiles (see https://www.w3.org/community/music-notation/wiki/MusicXML_Use_Cases#Document_Profiles <https://www.w3.org/community/music-notation/wiki/MusicXML_Use_Cases#Document_Profiles>).  These are essentially "checkboxes" in a document that provide a way to say that a score lives up to a certain set of practical expectations.
> 
> Let's say, for sake of argument, that we decided that floating clefs were outside the Encoding Profile for "Standard CMN". This would not rule out creating documents with floating clefs, or finding some way to encode them semantically. What it would mean is that the documents including floating clefs would not be allowed to include the "Standard CMN" profile checkbox. And the consequences would be that we wouldn't expect software built for the "Standard CMN" Profile to handle floating clefs.  And some developers would be free to go the extra mile and produce or consume this encoding anyway, if they felt the feature was important.
> 
> I will take up the actual merits and problems with floating clefs as music notation some other time; I feel they ask a great deal of the reader. But that doesn't matter. The main point is that they are an infrequent compositional choice. I think we need to ground these debates in an understanding of costs and benefits, and to be clear that profiles give us a way to designate a core of notation within the standard to which developers must conform. That is really valuable and it's one of the big things missing from our ecosystem today. Putting things outside this core doesn't make them illegitimate, and doesn't make them impossible to encode. It just means that we understand that it is not realistic to oblige every conforming developer to embrace those things, and that we want to make a hard-edged declaration of what developers *must* support for a given profile.
> 
> Best,
> ...Joe
> 
> .            .       .    .  . ...Joe
> 
> Joe Berkovitz
> President
> Noteflight LLC
> 
> +1 978 314 6271
> 
> 49R Day Street
> Somerville MA 02144
> USA
> 
> "Bring music to life"
> www.noteflight.com <http://www.noteflight.com/>
> 
> On Fri, Apr 22, 2016 at 4:55 PM, Mark Johnson <mjears@gmail.com <mailto:mjears@gmail.com>> wrote:
> Neither of these unusual examples is intended to shift the meaning of the clefs from their normal positions on the staff. The treble clef centered on the top staff line in Dennis’s example is quite misleading in my opinion. Debussy’s bass clef at least sits in mid-air, so it avoids the implication of being a different kind of bass clef.
> 
> As for the cross staff notation, in piano music the staves indicate right hand and left hand, more than treble and bass clefs. It’s the only clear and compact way to indicate that this figure is played by both hands, and that aspect of the notation is quite standard.
>  MJ
> 
>