Re: Introducing MNX

Joe,
>
>     I'm worried that the Chair might be trying to limit the scope of
>     this project to CWMN (as defined by MusicXML). That would be
>     counter-productive and, as far as I'm concerned, defeat the whole
>     purpose of creating a new standard.
>
>
> Far from it. The entire point of the MNX container concept and 
> multiple "body types" is to avoid limiting this project to CWMN.
In reply to Jeremy, you said:
> - Our intent is to develop a single, standard MNX "body type" (or 
> module, if you like) for Common Western Music Notation documents, and 
> that this encoding would be part of the MNX standard -- in other 
> words, neither a recapitulation of MusicXML nor MEI's CMN module. We 
> expect that this encoding will incorporate ideas from multiple 
> standards (see the "Something Borrowed" piece of the post).
Maybe we are talking at cross-purposes here. As I understand it, a "body 
type" is a block of code that conforms to a particular schema. A 
"module" is a part-schema that can be combined with other modules to 
create such a schema. See the use of these terms at:
https://github.com/music-encoding/music-encoding/issues/285

I think that allowing MNX to contain a single, standard module for CWMN 
sounds like an MNX-oriented programmer's nightmare. If I want to use 
such a module, why do I have to include it in an MNX file? There will be 
software that converts MusicXML to MNX-CWMN, so MNX-oriented application 
programmers don't have to worry about implementing it.
On the other hand, the use of modules means the existence of software 
libraries, and code re-use.
I suspect, of course, that MEI-CWN (which already exists in modules, and 
is still actively being developed) is going to end up being MNX-CWN.

I'm still actively investigating the MEI modules, so its too early for 
me to make any sensible requests or suggestions in that direction, but 
I'm getting there... :-)

> I do think it's appropriate that the initial round of work on MNX 
> address CWMN, to yield the greatest and most immediate benefits given 
> the limited resources available to the group.
I think you are underestimating us. There are some *really* competent, 
experienced and *enthusiastic* programmers around here! :-))

In short:
CWMN is, of course, going to be part of the solution, but the solution 
should be planned from the beginning to be applicable to /any of the 
world's music notations past or present/.

Breaking the project up into appropriate modules seems to me to be the 
first priority, not just re-implementing CWMN. That's been done already.

Best,
James

-- 
http://james-ingram-act-two.de
https://github.com/notator