Re: Splitting MNX-Common and MNX-Generic

One principal reason for keeping both frameworks and to keep them under a single name is for transition from MusicXML to MNX for researchers who would otherwise be considering MEI.  How will we indicate that MNX (or whatever the overarching name is called) is a format that can handle representation of the 2nd and 3rd scores in https://joeberkovitz.github.io/gmnx-viewer/  ?   I think that there are important marketing considerings for MNX for the research community to be considered with respect to “MEI can do X, can MNX do it?” which should be answered with “yes.” and not “no, MNX can’t, but Y can, and it’s by the same people”.  What will the other future expansions of MNX previously discussed (MNX-Neumes, etc.) be called?  I need to know a little more, but for now, I’m -1 on the idea.

Myke

---                                                     ---
Michael Scott Cuthbert
Faculty Director, Digital Humanities, MIT             4-215
Associate Professor of Music, MIT           +1.413.575.6024

Admin Assistant: Nicole Fountain (nicolelf@mit.edu<mailto:nicolelf@mit.edu>)

cuthbert@mit.edu<mailto:cuthbert@mit.edu>                    http://www.trecento.com




On Mar 11, 2019, at 04:59, Adrian Holovaty <adrian@holovaty.com<mailto:adrian@holovaty.com>> wrote:

Hi all,

In defining the MNX format, we've envisioned having a single format that contains at least two "types" of music notation data — MNX-Generic and MNX-Common. I've come to believe this isn't the right move.

(For background, see the current spec at https://w3c.github.io/mnx/specification/)

I believe MNX-Generic and MNX-Common are sufficiently different that they should just be two separate formats, rather than us trying to shoehorn them into a single format. Three reasons:

1. It's confusing for end users. Which one should users choose when importing/exporting? How would the user understand the differences in the level of semantics between the two similarly named formats? In my own experience, it's already confusing enough explaining the difference between a PDF and MusicXML, and those have different names!

2. It's confusing for developers. The type of development work required to parse something that is essentially an SVG wrapper versus a semantic document model is completely different. I would estimate 90% of developers would only want/need to parse one or the other — which strongly suggests they should be separate formats.

3. There's no obvious benefit in combining them, apart from some negligible things like having a common metadata format.

With this in mind, I'm proposing we formally split this into two formats, with distinct names and distinct specs. (To be clear, I think there's clear value in both formats existing.)

I brought this up with the other co-chairs in our latest meeting — you may have already seen the meeting minutes — and we're in broad agreement. Here are the meeting minutes with more details: https://www.w3.org/community/music-notation/2019/03/05/co-chair-meeting-minutes-march-5-2019/


Can anybody articulate a reason why we shouldn't make this change? I'd like to make sure we aren't overlooking a benefit that a single format would give us. If not, I can begin the work of splitting the spec in two. Please make any comments on the relevant GitHub issue (https://github.com/w3c/mnx/issues/98), so that we keep all the feedback in one place.

Cheers,
Adrian