Readme patch: MNX-Common encodes CWMN

[notator]

I've closed the PR at ff6b3b0 in order to send PRs for the separate suggested changes. They should be easier to deal with individually. I'm also practising sending PRs! :-)
This is the first of the changes I suggested in ff6b3b0.

[cecilios]

@notator
I would suggest more meaningfull names for PRs, similar to those in issues. "Readme patch1" is quite obscure.

As to the proposal, I do not understand the need to narrow the definition of MNX-Common. In my oppinion, its objective should be to represent music notation as broadly as possible. But to be pragmatic, we agreed to narow MNX-Common applicability to specific 'music notations' by using profiles. Why to change current wording to include the acronim CWMN without defining what is included and not included? No gain with your proposal, as it doesn't define MNX-Common scope more than current wording, but it creates more doubts and limitations for future profiles, i.e. Is neumes or tablature included in your CWMN definition?

[notator]

Hi @cecilios!
Okay, I've changed the title to be more expressive. Sorry, I'm new to PRs...

According to the current draft spec, MNX-Common

encodes Conventional Western Music Notation (CWMN)

But the spec's CWMN definition is far too vague to be used as the basis for a software standard. Last year, we had an intense, but inconclusive discussion (in issue #79) trying to pin CWMN down...

I outlined a solution to this dilemma a couple of weeks ago here.
Basically, I think the problem can be resolved by defining CWMN as the notation implemented by MusicXML, Finale, Dorico, Capella etc. If in doubt, the manufacturers should tell us what their definition is. This seems to be the best practical way forward, In practise, MNX-Common is currently being defined as the successor to MusicXML, without reference to any of the world's other notations, and that's fine by me...

The spec is also rather vague about the difference between a "notational idiom", a "score type" and a "profile". This also needs clearing up, and is also covered by my last reply to issue #98. Lets continue the discussion there.

[cecilios]

Hi @notator,
One thing is the specification, in which all kind of details and explanations can be included, and a different thing is the Readme.md page, that will be, in many cases, the first page someone approaching MNX will see. The spec. is the best place for details about MNX scope.

We should not start the Readme.md page talking about CWMN in the first paragraph without having previously defined the precise scope of the group understanding of what is CWMN. It is true that a few paragraphs later, the Readme.md text introduces CWMN and explains more about this. But it doesn't limit MNX to CWMN, it says:

`Our goal with MNX-Common is to create a format that does all of the following: ...

• It supports all of Common Western Musical Notation (CWMN)
  ...`

That is, the goal is to at least allow for CWMN. It doesn't not say to limit MNX to CWMN.

In any case, even assuming that the objective could be to limit MNX to CWMN, I would not start MNX introduction with acronyms and scope limitations before the reader has got a better understanding of MNX purpose and objectives. The readme.md page So, IMO we should not enter into details in the Readme.md page; the right place for details about MNX scope profiles, etc. is the spec.

[notator]

I agree completely. The Readme could/should really be a much more general introduction.

It could be very like the text at the top of the W3C page. However, that page also needs updating, since it contains a link to this MNX repository but doesn't say what the repository contains. In particular, the text should make it very clear (especially for the W3C audience) that MNX is not limited to CWMN. It should definitely not say that

MNX-Common is a new, open standard for representing music notation...

We should really continue the discussion about the spec in Issues #98 and #138. These are currently volatile and under Active Review. But here's a bit of background that might help understand how the new Readme came to be the way it is:

At the face-to-face meeting in Frankfurt (see YouTube video) @mdgood proposed that MusicXML should continue to be supported with maintainance updates, but that MNX-Common should be a new standard that takes more modern practices into account, and encapsulates any new ideas coming from the MusicXML community. The hope is that MNX-Common will eventually be able to replace MusicXML altogether. There was general agreement to this proposal, as you can see in the video.

But MNX is also supposed to be about notations that are not covered by MusicXML. This is, after all, a W3C Community Group! I'm not sure if MusicXML covers Gregorian Chant or other forms of neumes, or Tablature, but I'm pretty sure it does not cover piano-roll notation, Braille or Asian notations that read vertically... All notations, not just CWMN, need to be handled in a detailed, semantic way, so MNX-Generic is not the answer there. (@adrianholovaty is currently separating MNX-Generic into a separate Draft Specification document.)

The co-chair has said that they want us to concentrate on making progress with MNX-Common, so that's what we are currently doing. While we are doing that, I'd like to ensure that the (MNX) context within which MNX-Common is defined will easily accommodate non-MNX-Common notations when the time comes. That means defining generally useful concepts such as MIDI.cent frequency notation (Issue #138), and clearing up the muddle surrounding score types, notation idioms and profiles.

Apropos profiles: In Issue #138, we are, for example, currently discussing the MNX-Common syntax for microtone symbols. This has to be done, whatever happens, but its quite possible that such symbols don't belong in all the MNX-Common profiles. What each MNX-Common profile actually contains (and how many profiles there are going to be) can be decided later.