Re: Introducing MNX [via Music Notation Community Group]

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

On Thu, May 19, 2016 at 3:14 PM, Jeremy Sawruk <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
>>
>>
>>
>>
>