Re: Using Github Issues for MNX

Hi all,

I had been studying the Frankfurt slides and the subsequent email 
exchanges closely, and preparing a response, when Joe uploaded the 
latest version of the MNX Proposal Overview (20 April 2017).
https://w3c.github.io/mnx/overview/

Basically, I think that the slides and the MNX proposal are trying to 
treat the two proposals we have been talking about as the same proposal. 
In fact they have two completely different use-cases: MNX is a 
replacement for MusicXML (is an /input/ format for music notation 
editors), and the specialised SVG that I have been proposing is for 
score /instantiations/ (is an /output/ from music notation editors). 
I'll now call the latter *SVGMN*.
I can't imagine a use case that would need to put both CWMNX and SVGMN 
in the same file. Possibly, there is a reason to have GMNX in the same 
file as CWMNX, but then GMNX would not be the same thing as SVGMN.

My complete reply to all the above material is too long for a single 
document, so I've split it into the five issues summarized below. I 
think the second ("Two formats...") issue could be resolved fairly soon, 
but it uses terminology explained in the previous one, so maybe it would 
be best to start there.

Issue 1: *Terminology: semantics, CWMN*
1. The word /*syntax */should be used for the rules for creating 
well-formed blocks of symbols in a particular notation. The word 
/*semantic*/ should only be used when we are talking specifically about 
_meaning_. /Syntax/ is defined using one particular meaning for the 
symbols. /Semantic/ means that we are talking about the space in which 
the meanings of the symbols can change. (see the /The Fauré example 
revisited/ issue below).
2. CWMN should be renamed /*CMN1950*/ in all this CG's documents. There 
are several notations, created after 1950, that use a subset of the 
CMN1950 symbols with a new syntax. As I said in Frankfurt, we need to be 
very clear that CMN1950 (in which a mechanical interpretation is used to 
make bars "add up" in a standard way), does not have a monopoly on the 
use of the common symbols.

Issue 2: *Two formats, use cases, Proposals Overviews, GitHub repositories?*
I think SVGMN is so different from MNX, that it should have its own 
Proposals Overview document (and possibly even GitHub repository). There 
would, however, be advantages to continuing to develop these two 
standards in parallel.

Issue 3: *The Fauré example revisited*
This issue revisits the example I spoke about at the Frankfurt meeting. 
It relates only to MNX (not to SVGMN), and shows how, when scores are 
related to external recordings, the meaning of symbols changes while 
their syntax remains the same.

Issue 4:*SVGMN issues*
SVGMN files are SVG files containing Music Notation. GMNX code is 
contained in an MNX file, which is a completely new format. Its 
important that SVGMN files are going to display in browsers even if 
their temporal information is ignored.  They are specializations of the 
SVG already exported by most CMN1950 music editors. Possibly there is a 
reason to have GMNX as part of the MNX proposal, but I don't really 
understand why, and think it could probably be deleted. I've saved some, 
hopefully useful, thoughts on it here since they may be useful in a new 
SVGMN Proposal Overview document.

Issue 5: *SVGMN sketch page*
This issue contains the code for a skeleton SVGMN file, showing a) how 
media file, MIDI and MNX temporal data could be synchronized with 
scores, and b) how synchronized cursors could be realized in any score 
type (CMN1950 variations, asian and general 2-d graphics).

To debate the above issues properly, I need to publish their full texts 
somewhere. Where/how should I do that?

Hope that helps,
all the best,
James


Am 26.04.2017 um 22:13 schrieb Joe Berkovitz:
> Hi all,
>
> We're now ready to start using Github issues for further discussion of 
> MNX, in its associated repository:
> https://github.com/w3c/mnx
>
> All one needs to use Github is an account, which can be obtained for free.
>
> In most W3C groups, issue-focused discussions actually form the 
> backbone of group communication, rather than email threads. So we'd 
> like to make that shift here, now. This will help us in a number of ways:
>
> - Github can naturally guide us to separate our concerns into 
> distinct, clearly identified issues
> - Members can quickly identify whether an issue has been raised already
> - Members can view the prior discussion of an issue before entering it
> - The tracking of issues allows us to determine their disposition and 
> survey the status of projects
> - The records of each issue's discussion serve as a valuable audit 
> trail as we decide how to progress the spec
>
> We will also start to use Github pull requests for all proposed 
> concrete changes to MNX documents. Pull requests are the way that one 
> packages changes that one would like to see applied to the repository; 
> see  Only the chairs are able to approve and merge pull requests, for now.
>
> There are a number of "labels" that are available for tagging issues. 
> Feel free to use these, but the chairs will generally follow up and 
> apply them as needed.
>
> There are also "milestones" that permit issues to be designated as 
> slated for completion in different timeframes. We're not using these 
> yet, in this early stage, so we'll explain that later when we make 
> more use of them.
>
> The chairs have a few requests that should make the use of issues as 
> productive as possible for all of us:
>
> - Please search the issues to see if your concern has already been 
> raised, before creating a new one.
> - Please isolate your concerns in separate issues. "Run-on" issues 
> that combine unrelated concerns will be immediately closed by the 
> chair and we will ask you to break them out into multiple issues.
> - Please try to provide relevant examples that illustrate the goal to 
> be achieved by your change, or that show the gap that you are pointing 
> out. If something is to be changed, support your reasoning in a way 
> that others can understand.
> - Please use group email threads only for general discussions of 
> process, or for topics that are resistant to packaging as an issue for 
> some reason.
>
> Thanks, and I look forward to the next phase of work on MNX!
>
> Best,
>
> .            .       .    .  . ...Joe
>
> Joe Berkovitz
> Founder
> Noteflight LLC
>
> 49R Day Street
> Somerville MA 02144
> USA
>
> "Bring music to life"
> www.noteflight.com <http://www.noteflight.com>

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