- From: James Ingram <j.ingram@netcologne.de>
- Date: Sat, 29 Apr 2017 13:46:39 +0200
- To: Jeremy Sawruk <jeremy.sawruk@gmail.com>
- Cc: public-music-notation-contrib@w3.org
- Message-ID: <9680fa03-fa32-e457-66b4-ccfddb6bcfb8@netcologne.de>
Hi Jeremy, all, >> ji: MNX is a format that can contain related CWMNX and GMNX code. > I don't have the same interpretation of MNX. To me, MNX is a container > format that can contain CWMNX, GMNX, or other encodings that may come > about. Yes, you can have an MNX file that links CWMNX and GMNX, but > you can also have an MNX file that is solely CWMNX, and similarly an > MNX file that is solely GMNX. I also believe you can have two separate > MNX files, one CWMNX and other GMNX, that can be linked by reference, > but I may be mistaken on this point. Yes, I didn't mean to exclude the possibilities you mention. As I said, I think the chair currently has three proposals on the table: MNX, CWMNX and GMNX, and that the current Proposals Overview document needs to be updated to reflect the fact that MNX is a container. I think it would be even better, if the Proposals Overview document could now be split into three separate documents, so that we can discuss what MNX's use cases are, and whether it really needs to exist. (There may very well be good reasons, but I have yet to understand them.) >> ji: 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 strongly disagree. Having three names is very confusing, especially > since my opinion is that your SVGMN proposal is bringing additional > use cases, issues, and/or solutions to GMNX. I agree with Joe that the > best way to express your ideas is through Github issues in GMNX. I was referring to the names GMNX and SVGMN, that are two different approaches to the instantiation of scores that include temporal information. I think SVGMN is the better approach, and will be defending that view on GitHub when we've finished with this thread. We all agree, that GitHub is the best place to continue. This thread was matter of procedure: before beginning to post to GitHub, I first needed to clear up a couple of points, and find out how the chair wanted to organize its files and repositories. >> ji: Applications that want semantic data, can simply get it from the >> SVG file. > This scares me to death. As someone who has spent my entire career > working with MusicXML in a semantic fashion, the idea of needing to > parse an SVG file to retrieve musically semantic information is > something to which I am vehemently opposed. Good software engineering > practice is to separate semantics from presentation (see HTML and CSS). I don't think you need to be scared. If it succeeds in becoming widely adopted, CWMNX is going to be both imported and exported from CWMN music editors. The intention is that it is going to be an improvement on MusicXML, so you should expect it to be easier to deal with. On the other hand, if you want to write an application that deals with a score /implementation/, then you are going to have to parse SVG. That's true in both GMNX and SVGMN. Such applications need to have semantic information about the graphics they are processing. For example, the application needs to know which lines are "staffline"s, or which group (<g>) elements are "event"s. 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. Note that an enormous effort has been put into the development of tools for parsing the web DOM (of which SVG is a part). These tools are used everywhere on the web, not just by the music industry, so you can expect them to be well developed and quite easy to use (if you know Javascript). Such tools can easily be used to process SVG embedded in HTML, but can they be used to process SVG embedded in MNX? §6 of the current MNX Proposals Overview document proposes that CSS be used to style CWMNX. As far as I can see, CSS is not mentioned in connection with GMNX. CSS /can/ be used with SVG, but current browser implementations seem a bit patchy: The example at https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/SVG_and_CSS works in Firefox, but not in Chrome. CSS is a very interesting subject, but I've never used it seriously with SVG. We need an SVG/CSS expert from the W3C to help us there. All the best, James Am 28.04.2017 um 17:07 schrieb Jeremy Sawruk: > James, > > A few responses: > > - You said "MNX is a format that can contain related CWMNX and GMNX > code." I don't have the same interpretation of MNX. To me, MNX is a > container format that can contain CWMNX, GMNX, or other encodings that > may come about. Yes, you can have an MNX file that links CWMNX and > GMNX, but you can also have an MNX file that is solely CWMNX, and > similarly an MNX file that is solely GMNX. I also believe you can have > two separate MNX files, one CWMNX and other GMNX, that can be linked > by reference, but I may be mistaken on this point. > > - "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 strongly disagree. Having three names is very > confusing, especially since my opinion is that your SVGMN proposal is > bringing additional use cases, issues, and/or solutions to GMNX. I > agree with Joe that the best way to express your ideas is through > Github issues in GMNX. > > - "Applications that want semantic data, can simply get it from the > SVG file." - This scares me to death. As someone who has spent my > entire career working with MusicXML in a semantic fashion, the idea of > needing to parse an SVG file to retrieve musically semantic > information is something to which I am vehemently opposed. Good > software engineering practice is to separate semantics from > presentation (see HTML and CSS). > > These responses do not necessarily reflect the views of my employer. > > J. Sawruk > > 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:47:18 UTC