- From: James Ingram <j.ingram@netcologne.de>
- Date: Sat, 29 Apr 2017 13:53:51 +0200
- To: Joe Berkovitz <joe@noteflight.com>
- Cc: public-music-notation-contrib@w3.org
- Message-ID: <967c4ef1-d018-4ccc-7274-4c9ace6d5313@netcologne.de>
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 Saturday, 29 April 2017 11:54:27 UTC