- From: James Ingram <j.ingram@netcologne.de>
- Date: Sun, 22 May 2016 11:38:03 +0200
- To: "public-music-notation-contrib@w3.org" <public-music-notation-contrib@w3.org>
- Cc: Joe Berkovitz <joe@noteflight.com>, Zoltan Komives <zoltan.komives@tido-music.com>, Michael Good <mgood@makemusic.com>, jeremy.sawruk@gmail.com
- Message-ID: <80a25002-f621-245e-9f48-bbf506881bc4@netcologne.de>
Hi again, Sorry, but I'd like to say something more about: > *What is MNX About? > > *Now that we have a name, however temporary, we’d like to make some > statements about what MNX is intended to accomplish. These goals are > only partly derived from the many use cases and scenarios discussed so > far. They also represent the co-chairs’ ideas about how the CG should > spend its time, and where the payoffs lie for stakeholders. The payoff for those who have invested in software that works with MusicXML should be that large parts of that software are likely to be compatible with MNX. However, the whole point of creating a new standard is to enable standards-oriented application programming (i.e. the writing of *new* software). This is something that has been discovered to be important for the software industry only during the past few years. If this CG can produce a good standard (which I believe it can, given the combined experience of the participants), then even minority notations can be integrated seamlessly into the global XML notation community. The payoffs are likely to be enormous, both in academia and in the cultivation of music notation in general. I'm worried that the Chair might be trying to limit the scope of this project to CWMN (as defined by MusicXML). That would be counter-productive and, as far as I'm concerned, defeat the whole purpose of creating a new standard. All the best, James Am 21.05.2016 um 12:34 schrieb James Ingram: > Hi Joe, Jeremy, Michael, Zoltan, All, > > Thanks to the Chair for a very interesting document, and > congratulations on the new name! > > Joe said (in reply to Jeremy): >> Our intent is to develop a single, standard MNX "body type" (or >> module, if you like) for Common Western Music Notation documents, and >> that this encoding would be part of the MNX standard -- in other >> words, neither a recapitulation of MusicXML nor MEI's CMN module. > But, in the *Introducing MNX* document, > > *What Next?* says: >> A key part of this work will be the development of a family of CWMN >> document profiles that can significantly lighten the development burden. > I'm just beginning to understand MEI profiles, so please correct me if > I've misunderstood something. This posting is by way of ensuring that > we are all on the same page... :-) > > MNX must, of course, provide at least one CWMN schema, but I'd prefer > to re-build it from scratch (in the light of past experience, of > course), from simpler modules, rather than beginning at the top level > and trying to work down. I think a bottom-up approach would be more > likely to result in clean re-usable definitions at all levels. Maybe > my ignorance of MusicXML is actually going to be an advantage here. > :-) It would, for example, not be very difficult to define container > hierarchies that could be re-used in different schemas. > > I suspect that we are soon going to arrive at a module defining the > basic objects used in CWMN (staves, clefs, chord symbols etc.), but > that this module is not going to include /all/ the objects used by > CWMN (as defined by MusicXML). I also suspect that there will be > modules containing less used CWMN objects (such as infinitely nestable > tuplets) that not all editors would be expected to implement. We are > going to discover that CWMN is not the monolithic, well defined, > single entity that MusicXML assumes. > > Of course we should build on previous experience as much as possible, > and where mistakes have been made, they should be corrected. The > biggest mistake I see in MusicXML is the confusion between graphical > and temporal information. Graphical objects do not have fixed meanings > -- even in CWMN. The same is true in natural language. > > So MNX should distinguish *very sharply* between these two domains. > > As far as I'm concerned, MNX should be primarily about graphical > semantics (the relations between uninstantiated spatial objects). In > XML files, elements defining such objects can contain elements > defining temporal events. But the spatial behaviour of the graphical > objects (their semantics) must be kept as independent as possible of > their content. > In all music notations, there is one small connection between the two > domains, and in CWMN it takes the following form: left->right > corresponds to earlier->later, and synchronous events are aligned > vertically. So there has to be a reliable mechanism for determining > the /relative/ horizontal positions of note/chord/rest symbols on > different staves, and this relative left->right order may not be > contradicted by the earlier->later temporal information. But there > connection ends. > > *What is MNX About? *says >> These goals are only partly derived from the many use cases and >> scenarios discussed so far. > but, lower down, the document also says: >> ...our primary intent is for MNX to support uses of CWMN across the >> various user communities described in our use cases document... > I think MNX should be about enabling *all* the use-cases [1]. None of > them seem impossible. Especially given the use of MEI profiles. There > is a lingering feeling that the Chair is only interested in CWMN as > defined by MusicXML. Can you confirm that this is not the case? > > All the best, > James > > -- > http://james-ingram-act-two.de > https://github.com/notator > > [1] https://www.w3.org/community/music-notation/wiki/MusicXML_Use_Cases > > > >> Hi Jeremy, >> >> That's close to the idea, and the analogy to SVG embedding in HTML is >> good, but let me try to clear up a few possible misconceptions. >> >> - Our intent is to develop a single, standard MNX "body type" (or >> module, if you like) for Common Western Music Notation documents, and >> that this encoding would be part of the MNX standard -- in other >> words, neither a recapitulation of MusicXML nor MEI's CMN module. We >> expect that this encoding will incorporate ideas from multiple >> standards (see the "Something Borrowed" piece of the post). >> >> - Consequently, a container document is trying to do more than merely >> wrap up MusicXML or MEI documents in their present-day form. However, >> that would be actually possible and might even be useful. >> >> - Note that container documents would normally provide lots more >> information about each contained thing like bibliographic metadata, >> header information, etc. So the stuff inside the container no longer >> has to bear the burden of doing that. >> >> Best, >> >> . . . . . ...Joe >> >> Joe Berkovitz >> President >> Noteflight LLC >> >> +1 978 314 6271 >> >> 49R Day Street >> Somerville MA 02144 >> USA >> >> "Bring music to life" >> www.noteflight.com <http://www.noteflight.com> >> >> On Thu, May 19, 2016 at 3:14 PM, Jeremy Sawruk >> <jeremy.sawruk@gmail.com <mailto:jeremy.sawruk@gmail.com>> wrote: >> >> So is the general idea that MNX would encapsulate entire >> documents of different encodings (for example, how SVG can be >> embedded in HTML)? >> >> Example (pseudo-code): >> <mnx> >> <musicxml> (entire MusicXML document) </musicxml> >> <mei> (entire MEI document) </mei> >> ... (other complete documents) >> </mnx> >> >> On Thu, May 19, 2016 at 10:53 AM, W3C Community Development Team >> <team-community-process@w3.org> wrote: >> >> In this post we’re taking the first of a series of steps that >> will establish a >> specification for the notation encoding standard that’s the >> subject of our >> work in this CG. The steps here are focused on a name, a >> mission and a >> high-level approach. >> >> A Name, Of Sorts >> >> We’re proposing the use of a code name for the next standard: >> something that >> we can use as a label, yet which is temporary in nature: it >> isn’t a committed >> naming decision. We feel that it’s not right to stick with >> MusicXML as the >> name for this project: it may suggest to some that it’s going >> to address the >> same use cases in the same ways as MusicXML, or that there >> may be some bias >> against evaluating ideas from other quarters. >> >> For this code name, we’re proposing to call this project >> “MNX” for the >> time being. We don’t have to love this choice yet, because >> the name is >> replaceable. We just need something easy to say, easy to type >> and a bit >> open-ended. It stands for... “Music Notation X”, where X >> might mean the X in >> "extensibility", or the X in "next", or the call of the >> unknown, or the Roman >> numeral 10, or, perhaps, just a plain old letter of the alphabet. >> >> What is MNX About? >> >> Now that we have a name, however temporary, we’d like to make >> some statements >> about what MNX is intended to accomplish. These goals are >> only partly derived >> from the many use cases and scenarios discussed so far. They >> also represent the >> co-chairs’ ideas about how the CG should spend its time, and >> where the payoffs >> lie for stakeholders. >> >> An Open Framework, But A Focused One >> >> MNX provides an overall framework for encoding works of music >> of many different >> kinds. As such, it anticipates that more than one encoding >> system may be used, >> perhaps even within the same document. >> >> The MNX schema will begin by describing a notation-neutral >> container that is >> concerned solely with a document’s metadata, attribution and >> organization. >> This part of this framework does not reference any notational >> system. >> >> Inside the MNX container are one or more body elements of >> encoded music >> notation. These body elements can contain embedded documents >> of various types >> registered by some mechanism and policy to be determined. An >> MNX “body type” >> consists of an XML schema or sub-schema applying to some MNX >> body. An MNX body >> may also cite one or more document profiles that govern how >> its body is encoded, >> above and beyond the constraints of the XML schema itself. >> >> There will be a way for those who wish to create their very >> own digital >> representation of notated music to do so, and plug that into >> an MNX document. >> However, only some set of recommended types are likely to be >> supported by other >> parties and their software projects. So there is an obvious >> incentive to use a >> recognized type to encode a work, rather than inventing one’s >> own. The work of >> the CG will focus on a small number of such recognized body type. >> >> MNX comes bundled with a ready-made body type that supports >> Common Western Music >> Notation (CWMN), and which is biased towards a semantic >> representation of music. >> The encoded music is not required to reference any specific >> visual or aural >> rendering, although such information can be optionally >> included. This goal does >> not presume that there is a single unitary definition of >> CWMN, but the ways to >> tweak its boundaries must necessarily be limited in order to >> have a standard >> that solidly represents the vast majority of CWMN repertoire. >> Other body types >> will no doubt be invented to accommodate the gaps that >> result, and which make >> different design tradeoffs. >> >> The CWMN body type and its associated document profiles are >> the heart of MNX: >> our primary intent is for MNX to support uses of CWMN across >> the various user >> communities described in our use cases document, serving >> creative, academic and >> commercial interests alike. The hope is that MNX will at >> least inherit the >> degree of support found for MusicXML today, and will >> hopefully address many >> unmet needs of other musical constituencies. >> >> The initial work of the CG, therefore, will lie in >> elaborating the CWMN body >> type for MNX. Other body types will fall inside the circle of >> recommended types, >> of course, while yet others will be works-in-progress or >> experimental >> prototypes. These other body types will, at first, be the >> work of voluntary >> subgroups. >> >> Something Borrowed, Something New >> >> MNX is not starting from scratch: there’s a lot of useful >> work to draw on. We >> should strive to avoid reinventing the wheel. Rather than >> repeat some of the >> areas where MNX intends to innovate (e.g. styling, profiles), >> this section looks >> at some of the key existing work that we can make use of today. >> >> MEI does a great job of organizing musical texts with >> their attached metadata >> in an arbitrary structure (the “container” spoken of above).. >> MEI’s >> >> approach to metadata overall is very thoughtful and more >> comprehensive than what >> is available in MusicXML. >> MusicXML has a rich semantic vocabulary for CWMN >> proven by time and adoption. >> MusicXML can cope with a wide range of conflicts >> between visual notation and >> the intended aural rendering >> The MEI CWMN schema has a simpler approach to >> organizing elements that is more >> friendly to a DOM-based approach. >> Other projects including CMME and NeumesXML have >> looked at encoding neumes and >> mensural notation, and these should be examined for potential >> adoption or >> adaptation. >> >> Next Steps >> >> The best next step would be to create a family of spec >> documents that begin to >> capture the most significant ideas that we want to employ. >> These initial drafts >> will document concrete directions that can be discussed. They >> will follow the >> overall structure and formatting of other W3C specs in HTML, >> and will draw on >> W3C’s internal specification toolset ReSpec. >> >> We propose that the initial emphasis be placed on two >> specifications: >> >> The MNX container. MEI has already done a great job >> developing the concepts >> needed for a good approach to a container, and it’s possible >> that not much new >> ground may need to be broken here. Perhaps the key challenge >> here is that the >> notion of body type will need to be worked out and elaborated. >> >> MNX support for CWMN encoding. We expect the CWMN encoding >> piece to draw on the >> terms, concepts and vocabulary of MusicXML, but reworked to >> better support >> current encoding and programming best practices. A key part >> of this work will be >> the development of a family of CWMN document profiles that >> can significantly >> lighten the development burden. To leverage MusicXML >> adoption, the specification >> will be developed together with automated software to convert >> existing MusicXML >> files into MNX CWMN files. >> >> We expect another round of discussion on the CG list, >> naturally, but we wanted >> to take this opportunity to share our thoughts so that we can >> begin together on >> the next -- and very exciting -- bunch of work. >> >> Joe Berkovitz, Michael Good and Daniel Spreadbury >> W3C Music Notation Community Group Co-Chairs >> >> >> >> ---------- >> >> This post sent on Music Notation Community Group >> >> >> >> 'Introducing MNX' >> >> https://www.w3.org/community/music-notation/2016/05/19/introducing-mnx/ >> >> >> >> Learn more about the Music Notation Community Group: >> >> https://www.w3.org/community/music-notation >> >> >> >> >> > > -- http://james-ingram-act-two.de https://github.com/notator
Received on Sunday, 22 May 2016 09:38:45 UTC