Re: Introducing MNX [via Music Notation Community Group]

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
>
>
>
>