Skip to toolbar

Community & Business Groups

Music Notation Community Group

The Music Notation Community Group develops and maintains format and language specifications for notated music used by web, desktop, and mobile applications. The group aims to serve a broad range of users engaging in music-related activities involving notation, and will document these use cases.

The Community Group documents, maintains and updates the MusicXML and SMuFL (Standard Music Font Layout) specifications. The goals are to evolve the specifications to handle a broader set of use cases and technologies, including use of music notation on the web, while maximizing the existing investment in implementations of the existing MusicXML and SMuFL specifications.

The group is developing a new specification to embody this broader set of use cases and technologies, under the working title of MNX. The group is proposing the development of an additional new specification to provide a standard, machine-readable source of musical instrument data.

w3c/musicxml w3c/mnx w3c/smufl

Group's public email, repo and wiki activity over time

Note: Community Groups are proposed and run by the community. Although W3C hosts these conversations, the groups do not necessarily represent the views of the W3C Membership or staff.

final reports / licensing info

date name commitments
MusicXML Version 3.1 Licensing commitments
SMuFL 1.3 Licensing commitments
SMuFL 1.4 Licensing commitments
MusicXML 4.0 Licensing commitments

Chairs, when logged in, may publish draft and final reports. Please see report requirements.

Publish Reports

Co-chair meeting minutes: July 4, 2024


Adrian has added an example MNX document for grand staff instruments, illustrating three key aspects: the part object has a staves object to specify the number of staves, each sequence needs to specify which staff it belongs to, and each clef likewise needs to specify its staff. No specification changes were required to accommodate this example. We discussed briefly whether it makes sense to move the staff from inside clef up to the positionedClef object, where the rhythmic position lives, and agreed that we should.

Adrian has also created a pull request for the support element, which in the first instance is intended to specify whether the document encodes the visibility of accidentals (pull request #347). The field useAccidentalDisplay defaults to false, i.e. by default it is assumed that the consuming application is expected to use its own algorithmic approach to determining where accidentals should appear. If the document does not have useAccidentalDisplay set to true, but then nevertheless specifies accidentalDisplay for one or more notes, we have specified that will be invalid MNX; we are not yet sure whether we can make the JSON schema complain about this issue, but we will look into it. We welcome community feedback on this pull request before we merge it.


Adrian has made the corresponding change to the doc generator for MusicXML to encode long strings as arrays to improve the readability of the diffs (pull request #526).

Next meeting

The next co-chairs’ meeting is scheduled for Friday 19 July 2024.

Co-chair meeting minutes: June 21, 2024


Adrian has documented that staves are numbered using a 1-based system (git commit).

Adrian has made a change to the specification to remove the micro-syntax for measure location, which was used in six different places in the spec. He has introduced a new object measure rhythmic position that defines the rhythmic position within a particular bar. The git commit message specifies the various places where these changes have been made. The specification and examples have also been updated accordingly.

Adrian is next going to work on a pull request for the supports object for accidental visibility (see minutes of previous meeting), and will follow up with examples that show how things are encoded with reference to a specific staff (discussion #343).

We talked for a while about rich text encoding (with reference to issue #280) and discussed how this might look now that we’ve moved to JSON. Daniel agreed to write up an issue capturing some of the discussion as a starting point for further feedback.

Next meeting

The next co-chairs’ meeting is scheduled for Thursday 4 July 2024.

Co-chair meeting minutes: May 30, 2024


In our last meeting we discussed changes to cautionary accidentals in order to focus on encoding their appearance rather than their semantics, and Adrian has now implemented this via a new enumeration in accidental-display, allowing us to encode that an accidental should be parenthesised or bracketed (commit). There will be more work to do in this area in future concerning encoding the reason for the accidental’s appearance, but we will return to that in future.

We also discussed the need to specify whether a MNX document encodes the display of accidentals, and Adrian plans to move on to this next, preparing a pull request for an initial implementation of a new supports object, which will form the beginning of a general-purpose way of describing the approach to encoding.

Adrian has also made a few improvements to the doc generator tool, including ensuring that Windows newline characters are removed (issue #338), and changing the way the raw JSON file that holds the metadata for the format such that it uses a list of strings, removing new lines from the file and making it easier to read diffs (issue #340). Adrian will make the corresponding change for the MusicXML repository as well.

Adrian also fixed some remaining kebab case values to change them to camel case for the barline-type object (issue #342). A similar change needs to be made for the octave-shift values for octave lines (issue #344), which Adrian will do in due course.

Discussion #343 raises an issue concerning how we encode the staff on which a clef should appear for a multi-staff part, and indeed how in general sequences, events, and notes are assigned to staves. We already have a staff index for parts and sequences, but we will need to add this to both events and notes in order to provide full flexibility in encoding voices, chords, and individual notes that can be assigned to another staff. Adrian will prepare a proposal for this, with some worked examples for multi-staff instruments.


Werner Lemberg has opened discussion #518 concerning the encoding of enclosures in directions. Myke proposes that we specify that sibling directions within the same element with the same enclosure type should share a single enclosure, unless a new putative enclosure-break attribute is set; this attribute would be of yes/no type and default to no. Ideally, we would specify enclosure on the higher-level direction element if it is intended that all of the child elements should be enclosed, but because the current default usage of enclosure on the first child element of direction-type assumes that the enclosure will be inherited by each subsequent child, this feels like too big a change. We welcome further community discussion in discussion #519.

Next meeting

The next co-chairs’ meeting is scheduled for Thursday 20 June 2024.

Co-chair meeting minutes: May 16, 2024


Following on from our last meeting, Adrian has resolved the existing cases where enumerations had the duplicate value none. The affected enumerations were staffSymbol (where none has been replaced with noSymbol), tupletDisplaySetting (noNumber) and barlineType (noBarline).

Paul Overell identified a small error in one of the example projects (issue #336), which Adrian has also fixed.

Werner Lemberg has raised concerns about the line endings in the Git repository (issue #338). Adrian hasn’t yet looked at this issue, but thinks it should be not too problematic.

Werner also raised an issue about the use of the terminology for accidentals, and in particular the use of the term cautionary, which is considered ambiguous (issue #331). In accidentalDisplay, we will remove cautionary and editorial and add a new value enclosure to specify whether and how the accidental is bracketed.

At the moment, MNX specifies that accidentalDisplay must be present if an accidental should be rendered. After some discussion, we have decided that we should relax this restriction, since we are concerned that this might be difficult for every class of applications (since it implies that they should have implemented an algorithm for determining where and whether accidentals should be displayed). We propose adding a supports dictionary to MNX, similar to (but more structured than) the identically named element in MusicXML, to allow the exporting application specify its approach towards encoding accidentals (and, in future, other notations). Adrian will create a pull request for this in due course.


There has been some lively discussion concerning our proposal to move the DTD doctype identifier to a domain that is under the direct control of the CG (discussion #503). We welcome further feedback from the community on this issue. Myke suggested the one possibility would be to try changing the doctype identifier during the development phase of MusicXML 4.1 to uncover any problems, with a commitment to review the decision before the end of the development period.

Adrian also fixed a problem with the Python requirements.txt for the doc generator tool that needed to be pinned to a specific version of Django so that Myke could get it running on his own system in preparation for a MusicXML revision.

Next meeting

The next co-chairs’ meeting is scheduled for Thursday 30 May 2024.

Co-chair meeting minutes: April 25, 2024


Adrian has been working on some issues opened by Yuriy Kravets:

  • #334: There were several key names in the specification that used hyphens rather than camel case; Adrian has now fixed this. A few values remain that contain hyphens, and Adrian plans to fix these in due course. Adrian has also updated the MNX converter where needed to handle these changes.
  • #335: This required adding an enumeration for the showValue value for tuplets (inner, none, both)
  • #333: The staffSymbol object was missing the value none for its enumeration; this has now been added.

Myke pointed out that it might be preferable to have more specific values than “none” for enumerations, since “none” can be a special keyword in several languages (typically equating to “null”, “unknown”, or “undefined”). We spent some time discussing possible approaches to this, and agreed that in principle we should use a more specific value than “none”. Adrian will review the other enumerations and see which others should be modified.

Adrian has also been working on the MNX viewer, and it can now handle some more notations, including accidentals, repeat barlines, and so on.


Myke proposes that the DOCTYPE system identifier for MusicXML should move from to a URL within, since the latter is under the control of the CG, while the former (quite rightly) remains under the stewardship of MakeMusic. We welcome community feedback on this issue, so please share your thoughts here.

Next meeting

The next co-chairs’ meeting will be in three weeks, on Thursday 16 May 2024.

Co-chair meeting minutes: April 11, 2024


We’ve started to feel that a good chunk of the “bones” of MNX are becoming reasonably stable — so Adrian has put together an initial version of a live MNX viewer:

This tool lets you enter raw MNX code and view a graphical rendering of the music. To our knowledge, this is the first-ever software that renders MNX JSON — an exciting milestone!

At the moment, it’s limited to very basic music, as the primary goal was to establish the underlying web infrastructure for the tool. Adrian plans to continue working on the viewer to add support for more of MNX.

The purpose of the tool is twofold. First, we hope it helps developers get to know MNX by experimenting and interacting with it. Second, it provides an opportunity to “eat our own dogfood” by writing code that parses MNX, to get a practical sense of the developer experience. Adrian has reported it was reasonably easy to build this and identified a few small ways we could improve our documentation to make it smoother.

It’s important to note this viewer is built on the (closed-source) Soundslice technology, for no other reason than pragmatism: it’s what Adrian knows from his day job. It was much faster to do that than to learn another notation rendering library. We’d be delighted if somebody in the community wanted to lead an effort to build an MNX viewer using completely open-source software. Please get in touch if you would be interested in this.

Community member Yuriy Kravets raised a handful of issues which Adrian has been looking at. Issue #327 was closed without taking action. In #328, Yuriy proposed that the denominator for time signatures should be allowed to use units of 16 and 32, so Adrian has tightened up the encoding of time signature denominators to use an enumeration. In #326, Yuriy pointed out that the type attribute for barlines was not required, and Adrian has tightened this up too.

Next meeting

The next co-chairs’ meeting will be in two weeks on Thursday 25 April.

Co-chair meeting minutes: March 28, 2024


Adrian has improved the doc generator system to handle enumerations (issue #321), and the automatically generated JSON schema now also includes this information, so that all the allowable values for string-based types are specified.

There were a couple of JSON objects that didn’t have enumerations defined, so Adrian has added them where it was simple to do so. A couple of issues remain where the intent is to use the values from MusicXML, but Adrian hasn’t yet gone ahead and brought those values over; this will be done soon.

Myke suggested that we should probably prefer lower camel case rather than using hyphens to separate multi-word enum values, as this maps more cleanly onto the default enum types in languages like Javascript and Python. Adrian agreed that this would be a good change.

Next meeting

The next co-chairs’ meeting is scheduled for Thursday 11 April 2024.

Co-chair meeting minutes: March 7, 2024


Adrian has merged the pull request #322 for event markings: MNX now supports 11 types of markings in the event object. Adrian has added support to the MNX converter for importing these markings from MusicXML.

In issue #323, Myke suggested that we should disambiguate the use of the term position, which was currently being used both for rhythmic position and for vertical position within the staff. We now use staff-position for vertical positiion. Adrian has also implemented support for this in the MNX converter.

Adrian also found an old issue #256 to rename tied to tie, which has now been updated in the specification, examples, and in the MNX converter.

Next, Adrian is planning to tackle issue #321, to improve the generation of the JSON schema to include all of the possible values for enumerations in the schema.

Next meeting

The next co-chairs’ meeting is scheduled for Thursday 21 March 2024.

Co-chair meeting minutes: February 22, 2024


Adrian has created a pull request (#322) to address issue #103 with a proposal for the encoding of 11 different markings, including all the MusicXML articulations (with the exception of the markings that should be note-specific, namely the jazz articulations like scoop and fall) and single-note tremolos. We decided to go ahead and merge this pull request since there has been no dissent from the community on the proposal as described in the original issue.

As a next step, Adrian will implement support for these new markings in the MNX converter.

We also briefly discussed Myke’s issue #323 about the reuse of the word position to refer to both rhythmic position and vertical position within the staff, and we propose using staffPosition for position with the staff, to disambiguate the two dimensions.

Next meeting

The next co-chairs’ meeting is scheduled for Thursday 7 March 2024.

Co-chair meeting minutes: February 8, 2024


Adrian has been continuing to think about how to encode articulations (issue #103). In order to side-step the issue of determining once and for all what constitutes an articulation, which could be a controversial issue, he is proposing that we use a less semantic, more general way of grouping notations that apply to all the notes in a chord, i.e. in MNX terms at the event level.

After some further discussion, we have settled on the idea of having an object called markings within event that defines a set of markings that can be added to the event; for example, staccato, tenuto, accent, marcato, and so on. These will be objects in their own right, but can typically be empty unless they need to define any specific additional information such as placement, symbol overrides, etc.

Having arrived at a consensus among the co-chairs, Adrian will now prepare a pull request with a proposal for community feedback.

Next meeting

The next co-chairs’ meeting will be on Tuesday 22 February 2024.