RE: MNX Proposal now Available [via Music Notation Community Group]

James, 

Some reactions to your position:

> Remember that MusicXML is primarily a graphics standard, designed for sheet music.

Well, not exactly. But it has indeed a lot of elements that focus on the graphical aspect that describe a specific engraving, and neglects correct semantic representation in quite some areas. From quickly looking at the first MNX proposal, it really improves in that area. 

> The first pass defining MNX should define it purely as a graphics standard, ignoring any (temporal) meanings.

No. Make that "Hell No". The lack of some key semantic elements in MusicXML, and from there its utter lack of enforcing programs to dump semantically correct CWMN, is its main deficiency. I think it's fair to state that the majority of people interested in MNX are interested in the ability to create applications around MNX file. Degrading MNX to a pure "spatial" standard completely defeats that purpose. 

I mean, really, if you want a spatial standard that describes how things look on a page of paper, try to define a page description specification. Oh wait, a very popular one already exists. It's called PDF. 

> But not all notation systems have <tuplet> brackets

Correct. But the scope of MNX is clearly defined as CWMN, which does have tuplets. You insist on making MNX a completely universal thing, whereas the scope as defined is to limit it to the main area of the current market. Or to say it bluntly: that part of the market where the money is. Having a narrow scope is a prerequisite for MNX to receive a wide adaptation and to reach its goals. Making it something vague that could cover all notation systems is going to be a guarantee for failure.


Regards, 

JanR


From: James Ingram [mailto:j.ingram@netcologne.de] 
Sent: vrijdag 31 maart 2017 10:35
To: Rafael López García <phy.development@gmail.com>; Joe Berkovitz <joe@noteflight.com>; Dr Dominik Hörnel <d.hoernel@capella-software.com>
Cc: Music Notation Community Group <public-music-notation@w3.org>; public-music-notation-contrib@w3.org
Subject: Re: MNX Proposal now Available [via Music Notation Community Group]

Hi Rafa, Joe, Dominik,
Remember that MusicXML is primarily a graphics standard, designed for sheet music.
The first pass defining MNX should define it purely as a graphics standard, ignoring any (temporal) meanings. What the elements mean is a completely separate question that can be dealt with later.
In this first pass, MNX can borrow as much or as little as it likes from MusicXML. Its just not allowed to deal with anything temporal. A <tempo> is just a legible (graphical) string. A <tuplet> is a graphical object that brackets <event> symbols on the page.
<tuplet> graphics are important for legibility in CMN. They tell the reader how the bracketed <event> symbols align with other <event> symbols on the page. But not all notation systems have <tuplet> brackets, so they should be optional. So should <tempo> markings.
There should probably be an enumeration describing the graphical form of the <event> symbols. They could be CMN <event> symbols, Asian tablatures, neumes of some particular type etc. If they are CMN symbols, for example, they have noteheads, augmentation dots, stems and flags, ornament decorations, beams etc.
My advice would be not to get bogged down in tangential arguments, but to get on with the job of defining the graphical structure of MNX. I have, myself, too little experience with MusicXML to help much there, but its very nice that Dr. Dominik Hörnel from capella-software has joined us! :-)
All the best,
James

Am 31.03.2017 um 03:10 schrieb Rafael López García:
I bet that MNX stands for Music Notation XML, and then what you want to save is the notation, not the music itself (otherwise you would use an approach more similar to MIDI).
Not bad, and you didn't even have to read the spec!  :-)
But I read the one of MusicXML. And I wrote a MusicXML parser and a Java-2-MusicXML converter in Android. And I may write another for MNX in the future.


Yes, this is about saving a score, which is instructions on how to perform music, as distinct from music itself.
And in my experience as a programmer I also think that XML is not a very good format to support "operations" (move a note to another measure, etc.), only serialize and de-serialize. I think the XML should be transformed to a object structure in memory and the operations should be performed to those objects, then saved again. And here you can choose to save all the XML again or replace only the one referred by the objects that have changed, but that is a matter to decide by every software developer (for example, my Kunkunshi Editor saves everything again as the XML parser I use is very simple).
>From an informational point of view they are they are not completely the same. A human-readable music score is more than the instructions really needed to perform music. There are elements that are purely organizational (e.g.: the measures) and others that are merely aesthetic. You don't really need them to perform music, and they are actually introducing a certain complexity that could be avoided, that is why Dr. Hörnel argued the possibility of not having them. 

And actually... that is my case. When I wrote the aforementioned MusicXML parser, I did it for Kunkunshi Editor, an editor of Okinawan music. Okinawan music is NOT represented in the western fashion with staves and measures, but with a different system called Kunkunshi (工工四). So I also found all those organizational and aesthetic elements completely unnecessary for my use case. And when I write the parser for MNX in the future, it will happen again. But I understand that this tiny and infrequent use case, as medieval music notation, will be out of the scope of your standard.

As you say, one shouldn't use XML itself to perform these operations (and I hope no one does).

Standard modern practice is to parse XML into memory using a Document Object Model (DOM) parser and manipulate the in-memory structure via the DOM API -- a web standard, see https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model. It can then be serialized back out.

This practice is so ubiquitous that web programmers like me will talk in terms of manipulating the document, when what we really mean is manipulating the DOM in memory!

...Joe
Yes I know what a DOM parser is, I am tired of programming them. But when I read Dr. Hörnel's email it looked like somebody was opening the door to directly perform operations there. I am glad you clarified that is not the case.

Best regards,

Rafa

Received on Friday, 31 March 2017 09:15:54 UTC