Re: Pömmelchen

Hi Joe,

I wasn't actually trying to be confrontational, nor was there any implied criticism of MNX in my message. I'm also not trying to butt in on the conversation with any comparison of MNX to MEI. That was not my intention.

The "of course" was simply meant to say that it's not an MNX (or MusicXML)-or-nothing world. If your goal is interoperability then it's a very different goal from accurately representing 'boutique' or mutually-incompatible musical semantics. I believe there is room for both, but like all things it cannot be achieved without compromise. If you want to ensure Alex's example is readable (and writeable) by a wide range of applications with varying levels of musical sophistication, you will likely have to sacrifice something in the representation to achieve that.

MEI, as you rightly point out, sacrifices complexity in developing applications that will render it for increased flexibility in its representational capabilities. That's something that we're very open about as a community. But the representational power that we gain is probably why MEI appeals to a broad range of scholars, where the semantics of the notation are just as important (if not moreso) as its appearance in a rendering environment.

So to be clear, I am absolutely supportive of the MNX initiative and I would hope that alternate ideas (and voices from other communities) can have a place in this W3C community group. I think, though, that it is useful to acknowledge that "all is not lost" should you need to make compromises in the design of MNX to accommodate a broad interoperability mandate, and that there are alternate solutions available if that's what is needed.

-Andrew

> On 4 Apr 2017, at 22:16, Joe Berkovitz <joe@noteflight.com> wrote:
> 
> Hi Andrew,
> 
> On Tue, Apr 4, 2017 at 4:56 PM, Andrew Hankinson <andrew.hankinson@gmail.com> wrote:
> Of course, complex non-standard Western  music notations and semantic musical structures are probably better suited to the flexibility that MEI provides, so there is always that representational option as well. 
> 
> I think you are comparing MEI with an approach that hasn't been worked out here yet. So the "of course" feels a bit hasty to me.
> 
> I do in fact believe that MEI can represent these sorts of examples with some combination of its elements. The problem is, guaranteeing that applications will interpret those combinations in a way that reproduces the original. When flexibility applies to implementors as well as encoders, all bets are off.
> 
> Do you have an encoding of Alex's example and an application that will render that encoding? (I don't, but I'm not making any claim that we have a solution to the problem yet :-)
> 
> ...Joe

Received on Tuesday, 4 April 2017 23:38:14 UTC