Profiles and Customizations

Hi Andrew,

Thanks for the detailed response on MEI customizations. I'm retitling this
thread because it's such an important point that I don't want it buried
under a debate about floating clefs.

A few further thoughts below:

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

I talked with Zoltan in Frankfurt and I think we discussed at least one
area where "encoding profiles" may differ from MEI customizations. A
profile is more than a schema subset or a set of tree-structure rules: it
involves semantic constraints that reflect the conventions of some
notational idiom. I think these constraints (at least for CWMN) probably
require specification language to express, rather than a schema language or
even an extended framework like Schematron.

We're talking about rules that apply in a complex fashion to regions of a
document, aggregating their data in a musical sense. One good example of
this is "metrical consistency": the idea that the semantic metrical extent
of any voice or layer conform to the containing measure's semantic meter.
(Obviously this is not a profile that every document in the world will
conform to, but it is a useful profile!) This notion seems impossible to
express in any of the ordinary XML schema languages. Even in Schematron, I
don't think XSLT expressions would provide enough horsepower to capture
this idea (think about processing tuplets correctly).

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

Another opinion I ventured in the Frankfurt discussion: in order for
profiles (and, ergo, the standard to which they apply) to be useful in the
real world, they need to be present from the outset. I don't know that a
standard can afford to wait for a community of developers to collaborate
and let this crucial ingredient emerge from the fray :-)

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].
>

I think MEI and MusicXML at present each have areas where one is clearly
stronger than the other. MEI is definitely ahead in the area of profiles:
customizations are a crucial step in that direction. Having reviewed the
present CWMN customizations, I would call them a step but not a full
realization of the idea. But the idea itself is under construction, of
course!

I am interested in the kind of thinking that leads towards a synthesis of
the best results from all efforts to date. I hope that this is possible,
and look forward to exploring that idea with you and others in Montreal.

Best,
...Joe