James Ingram's proposals

Hi James,

(I'm retitling this email thread since it is not really about using github
issues, and more about a set of proposals that you are making.)

Let me try to respond to what you've said. I think that we seem to be
starting off once again with some misunderstandings which I would like to
clear up. I'll then try to answer your question about how you can best
pursue your ideas within the framework of this group.

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.
>
Not at all. We are proposing CWMNX and GMNX as two distinct markup
languages with different use cases, that can potentially coexist within a
container document. They may share a very few simple features like pitch
encodings, etc., but that's about all.

I expect there will be a very small MNX "common" spec, plus some completely
separate specs: one for CWMNX, one for GMNX, ad probably later ones for
other dialects.

> 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 agree that the use cases are different, but...

CWMNX is not just an input format for notation editors. It is an exchange
medium (both input and output) between any applications that wish to handle
notation in semantic form, rather than as literal graphics or timed events.

GMNX, on the other hand, is indeed a way to capture score instantiations --
I quite like that term -- and it uses SVG for the graphical aspect of that
instantiation.  So I would ask that rather than inventing another name
(SVGMN), you try to propose the specific ways (via specific issues) in
which you would approach GMNX differently. We appear after all to be
talking about the same thing, which serves the same purpose.

> 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.
>
I will offer at least two rationales for including both GMNX and CWMNX in
single container file:

- This allows a single work to be packaged in a single document with dual
encodings, when they are available. One encoding satisfies applications
that want semantic data, the other applications that want a score
instantiation.

- A GMNX instantiation of a CWMNX score will contain references back to the
semantic elements that gave rise to it, so it's nice to have these
references able to be intra-document rather than inter-document.

Having said this, it's not at all an absolute that they must to be packaged
together. It's a legitimate issue to raise, that it would be better to
require them always to be broken out into separate files. Perhaps you will
file that issue. But that doesn't require GMNX to become something
substantially different, either in name or in substance.

>
> Issue 1: *Terminology: semantics, CWMN*
>
I don't fully understand your problems with these terms, but please feel
free to substitute other words in your own writing as you see fit. Lacking
broad objections from the group, we'll go on talking about "semantics" and
"CWMN" and you can use your own alternatives.

Saying "CWMN" is in no way an attempt to assert any sort of monopoly on
using Western notational symbols in a pre-1950 manner. It simply describes
a certain conventional manner of using them, and obviously we need to
define the boundaries of this usage. Where those boundaries become
problematic, there are a few choices: 1) use GMNX, 2) expand the boundaries
of CWMNX, or 3) develop a brand-new semantic content type that suits the
music being encoded. The chairs are taking a strong position that #2 is
usually the option of last resort, because it imposes additional effort on
every single implementor that wants to comply with the spec. Thus we have
options #1 and #3 available.

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.
>
Agreed. As I said above, I expect that these will be developed in parallel,
and with some strong separation. I think that keeping them in the same repo
for now is a good idea though as there are some issues that transcend both.

>
> Issue 3: *The Fauré example revisited*
>
We'll wait for you to show whatever issues this example reveals, by filing
specific Github issues.

Note that I have filed https://github.com/w3c/mnx/issues/18 to reflect our
need for a corpus of examples.


> 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.
>
The proposal is not a specification. As I've said, GMNX will likely be
broken out into its own specification. But the chairs agreed that putting
both GMNX and CWMNX into  a single proposal document was probably the
clearest way to go in the short term, to get all the thinking out on the
table in one place.

>
> 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).
>
GMNX already attempts to address synchronization and cursors in a
generalized way that is intended to apply to CWMN, post-1950 MN, Asian
music, and pretty much anything that can be described in 2D graphics. It
may fail to do so, in which case the work falls on you (as on all of us) to
identify those failures, and show how they can be remedied.

I strongly suggest you file Github issues which (individually) explain how
the synchronization and cursor approaches in GMNX can be made better,
rather than creating an entire parallel SVGMN proposal. Then allow the
community to comment on your issues.

Best,
...Joe