Introducing MNX

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