- From: James Ingram <j.ingram@netcologne.de>
- Date: Sun, 30 Apr 2017 10:46:42 +0200
- To: Jeremy Sawruk <jeremy.sawruk@gmail.com>
- Cc: public-music-notation-contrib@w3.org
- Message-ID: <423a03a6-614e-72d7-0757-a9e82af646ef@netcologne.de>
Hi Jeremy, I still think it would be simpler just to drop the reference to the CWMNX document. The first thing we need to do is clarify what the chair means by MNX, CWMNX and GMNX, so I'm going to post an issue on GitHub for that purpose. > I will comment on your Github issues moving forward. See you there! :-) All the best, James (GitHub alias: notator) Am 29.04.2017 um 22:46 schrieb Jeremy Sawruk: > Hi James, > > You said: "For example, the application needs to know which lines are > "staffline"s". Then you said "Such information will be directly > accessible in SVGMN as the value of the element's class attribute, but > (as I currently understand things) in GMNX the element's id is read > instead, and then used to reference an element in a CWMNX file, > packaged in the same MNX file, to find out what its name is." > > It is my current understanding that IDs and classes can both be > references back to the CWMNX/GMNX file. I am not sure if the current > draft explicitly says this, but I believe that is the intent. One > possible solution might be to namespace these attributes when they are > embedded in an SVG document (ex: mnx:id, mnx:class, mnx:element) that > can be used as cross references. > > Example: <g id="<svg id>" class="<svg class>" mnx:id="<xref to MNX > doc>" ... > > > This approach keeps the musical semantics entirely in the MNX file(s), > while removing any ambiguity regarding cross-references. > > I will comment on your Github issues moving forward. > > J. Sawruk > > > On Sat, Apr 29, 2017 at 7:53 AM, James Ingram <j.ingram@netcologne.de > <mailto:j.ingram@netcologne.de>> wrote: > > Hi Joe, > > I just replied to Jeremy, maintaining the distinction between > SVGMN and GMNX. I still think its useful to keep the two names > until we've sorted the issues out. I'll be doing that in a GMNX > issue on GitHub, of course. > > Best wishes, > James > > > Am 28.04.2017 um 17:58 schrieb Joe Berkovitz: >> 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 <http://www.noteflight.com> >> >> On Fri, Apr 28, 2017 at 10:37 AM, James Ingram >> <j.ingram@netcologne.de <mailto: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 >> <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 >>> <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 >>> <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 >> >> > > -- > https://github.com/notator > http://james-ingram-act-two.de >
Received on Sunday, 30 April 2017 08:47:20 UTC