- From: Matthew James Briggs <matthew.james.briggs@gmail.com>
- Date: Tue, 21 Mar 2017 08:18:24 -0700
- To: Joe Berkovitz <joe@noteflight.com>
- Cc: Jeremy Sawruk <jeremy.sawruk@gmail.com>, public-music-notation@w3.org
- Message-ID: <CANf+YHzgj=RAUe=P0sYbiD3YWC-OujBjLaVePaQQZ04+FQo9yw@mail.gmail.com>
Joe, thank you for all the hard work you are doing. I am new to the MusicXML community so sorry that this hasn't been brought up earlier. I do not see the advantage of intermingling CSS within a music notation data exchange format. Many of the consumers of MusicXML are C++ applications (MuseScore, Finale, Sibelius, Lilypond, Dorico, Logic Pro, etc). We should not cause C++ music programs to parse CSS and respond like a web browser would. I believe the files should be self contained and stick to a single language (xml). Although I'm sure it would be convenient for web developers to put CSS into the documents, I believe it would *only* benefit web applications. We shouldn't, for example, put C code into the specification because that would *only* benefit C/C++ applications. Can it can be demonstrated that applications like Finale, Sibelius, Dorico, MuseScore and Lilypond benefit from CSS in a way that the xml data alone cannot provide? Unless I'm missing something, there's nothing that you can do with CSS that couldn't be done instead by encoding the desired results into the xml spec. My vision for what needs to happen to improve music notation interchange would be more along the lines of taking what we have with MusicXML, and re-organizing it into a more deterministic and hierarchical structure (more nesting, less reliance on previously-encountered-context when parsing, possibly sacrificing some freedom to make it easier to use). See attached for what I mean about structure. Again, thanks for all the hard work. Matt p.s. Another, less fundamental, suggestion that I have regards the use of strings like "3/8*". Once we pull values out of the XML, I don't think that those values should require further string parsing (i.e. for example find the slash, separate the numbers, then count the number of asterisks at the end). Instead I would recommend that such constructs be encoded atomically, e.g. <top>3</top><bottom>8</bottom><dots>1</dots> like MusicXML does. ..mjb On Tue, Mar 21, 2017 at 7:33 AM, Joe Berkovitz <joe@noteflight.com> wrote: > Hi Jeremy, > > Yes, there absolutely will be example scores. > > I have so far held off in order to avoid "example thrash" since converting > a set of convincingly complex scores is non-trivial labor, and I think some > of the structural underpinnings of MNX are not settled enough. I think once > we get an initial round of feedback (the next several weeks?) then it will > make sense to get on this. > > Best, > > . . . . . ...Joe > > Joe Berkovitz > Founder > Noteflight LLC > > 49R Day Street > Somerville MA 02144 > USA > > "Bring music to life" > www.noteflight.com > > On Mon, Mar 20, 2017 at 8:55 PM, Jeremy Sawruk <jeremy.sawruk@gmail.com> > wrote: > >> Will there be a repository of (public domain or properly licensed) >> example scores for MNX, the way there is for MusicXML? If so, I would >> suggest putting this somewhere in the MNX Github, either as a folder within >> the MNX Github, or as a separate Github repository. >> >> I have already started to write an MNX document. I think that I will be >> writing more MNX documents in the future that I would like to share with >> the community. >> >> Thanks. >> > >
Attachments
- text/xml attachment: musicxml-with-more-structure.xml
Received on Tuesday, 21 March 2017 15:22:45 UTC