Re: James Ingram's proposals

Hi James,

Thanks. I think that every point in your response can be handled through
filing a specific issue or adding notes to an existing one, so I expect we
will continue this dialogue on Github.

In my view, we don't need SVGMN as a separate thing with its own name in
order to have the discussion about whether a specialization of SVG is the
right way to go. That, too, can be handled an issue with GMNX, and I think
that's appropriate. Deciding to embed everything in an SVG document and
make SVG the "topmost" architectural unit does not invalidate the other
features of GMNX, which will still have their own debates. File the issue,
and try to show what problems this approach solves. That is the place we
can have this discussion.

It may be that your SVGMN concept includes other differences from GMNX,
besides proceeding from a specialization of SVG. These too can be filed as
issues.

If you want to publish a separate SVGMN proposal to show how these points
relate to each other, of course you're free to do so, but don't expect that
proposal to be the main locus of discussion. In the end, this will all
break down to a set of separable issues, and we're going to discuss those
issues rather than having a baking contest :-)

Best,

.            .       .    .  . ...Joe

Joe Berkovitz
Founder
Noteflight LLC

49R Day Street
Somerville MA 02144
USA

"Bring music to life"
www.noteflight.com

On Fri, Apr 28, 2017 at 10:37 AM, James Ingram <j.ingram@netcologne.de>
wrote:

> Hi Joe,
>
> Answers in-line:
>
> 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.
>
> Can we agree then, that you currently have *three* proposals on the
> table: CWMNX, GMNX and MNX.
> CWMNX is a replacement for MusicXML
> GMNX is a format that is a score instantiation
> MNX is a format that can contain related CWMNX and GMNX code.
>
> If that's the case, then the latest version of the MNX Proposal Overview
> (20 April 2017) needs updating. In particular, §1 needs to explain that MNX
> is a container format.
>
> 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*.
>>
> Here's the first misunderstanding (relates to the §1 problem): I should
> have said that CWMNX is a replacement for MusicXML...
>
> 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.
>
> Agreed. CWMNX can also be output by music notation editors.
>
>
> 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.
>
> The way I would approach GMNX differently is to use an SVG specialisation
> that I'm calling SVGMN. I think it would be useful to keep both names for
> the moment, so that we can talk about these alternative approaches without
> getting confused.
>
> 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.
>
> SVG allows semantic information to be stored in class attributes.
> An <event> in CWMNX can map to a <g class"event" ...> in the SVG.
> Applications that want semantic data, can simply get it from the SVG file.
> I think it would be simpler, and less error-prone, to get the semantic data
> from the SVG directly (using the javascript getElementsByClassName
> function), rather than using references to a different file. One of the
> reasons that I think CWMNX and SVGMN should be developed in parallel, is
> that it would be a good idea for both formats to agree on element
> names/classes.
>
> 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.
>
> I think that using SVGMN, rather than GMNX, would simplify things
> considerably: It would be less error-prone (no need to check if the
> embedded files really do correspond), use less complicated files, be
> displayable by existing software, and make the MNX container redundant. Are
> there any other reasons for MNX's existence?
>
> I'll be filing some issues at some point, but think it would be a good
> idea to try to resolve as many of the issues in this thread as possible
> first.
>
>
>> 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.
>
> Agreed. I have no objection to the CG continuing to use CWMN as the name
> of the standard notation in use around 1950.
> I think GitHub Issue #18 ( https://github.com/w3c/mnx/issues/18 ) should
> be used to pin down what the CG means by CWMN more precisely than in the
> current working definition (§1.3). We need a more formal definition, not
> just examples.
> The definition should:
> 1. include the definitions of a standard set of containers (page, system,
> measure, staff, voice, event)
> 2. list all the available symbols and symbol classes, with examples
> (MusicXML can probably help there...).
> 3. describe the containers' spatio-temporal order (e.g. that earlier
> systems are drawn above later ones on a page, and that event symbols that
> occur earlier in time in a system are aligned to the left of those that
> occur later.
> 4. describe how measures "add up" using tuplets, nested tuplets,
> augmentation dots and grace notes, according to rules derived from a
> mechanical (metronomic) performance.
>
> If that's okay with you, I'll post to GitHub issue #18 when we've finished
> with this thread, and you can regard this issue as closed.
>
> Please remember, however, that your use of the word "semantic" confuses me.
> I'm going to use the word "syntax" to mean the rules for combining symbols
> into a well-formed notation, and "semantic" (sparingly) when I'm talking
> about *meaning*.
>
> 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.
>>
> Again, I meant CWMNX, not MNX here.
>
> 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.
>
> In Issue 4 (below), you imply that the components will likely be broken
> out into their own documents later. So the questions raised by this issue
> are answered, and we can close it.
>
>
>
>> Issue 3: *The Fauré example revisited*
>>
> We'll wait for you to show whatever issues this example reveals, by filing
> specific Github issues.
>
> The example is explanatory, in that it explains why I need the word
> "syntax", but it also includes a rather controversial proposal about how to
> deal with tuplet brackets. Whether that proposal is successful or not
> remains to be seen! :-) I'll move this issue to GitHub when we've finished
> with this thread.
>
> Note that I have filed https://github.com/w3c/mnx/issues/18 to reflect
> our need for a corpus of examples.
>
> See the issue about defining CWMN above.
>
>
> 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.
>
> Understood. I think the contents of this issue will be outdated when GMNX
> (or SVGMN) has been broken out into its own specification, so lets just
> close it.
>
>
> 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.
>
> As outlined above, I think GMNX leads to overcomplicated files and
> algorithms, and needs completely new software to be written to deal with
> it. Whether to use GMNX or SVGMN seems to me to be an open issue. I'll post
> this SVGMN example to GitHub when we've finished with this thread.
>
> 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.
>
> As I said, my proposal as to how to improve GMNX *is* SVGMN, and I'd be
> very happy to discuss it with the community, both to see if they think its
> a better proposal than GMNX, and to see how it could be improved.
>
> All the best,
> James
>
> Am 27.04.2017 um 19:35 schrieb Joe Berkovitz:
>
> 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
>
>
>