Music Notation Community Group

Music Notation Community Group
Skip to toolbar
Skip
My W3C Account
Music Notation Community Group
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/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
2021-05-15
MusicXML 4.0
Licensing commitments
2021-02-14
SMuFL 1.4
Licensing commitments
2019-01-30
SMuFL 1.3
Licensing commitments
2017-12-13
MusicXML Version 3.1
Licensing commitments
Chairs, when logged in, may publish draft and final reports. Please see
report requirements
Co-chair meeting minutes: April 8, 2026
Daniel Spreadbury
Posted on:
April 8, 2026
GitHub organisation changes
The W3C has decided to migrate Community Group GitHub repositories from the
w3c
organisation to the
w3c-cg
organisation, to make their status clearer. This results in the public URLs for specifications etc. having changed. In general this has gone relatively smoothly, but for a few days there were some broken links and missing redirects. These have been repaired, but if anybody in the community spots any broken links, please let us know.
MusicXML
Karim has proposed that he introduces some “office hours” for MusicXML, providing a specific time on a regular basis where he makes himself available to developers. He likes the idea of there being a regular rhythm for times when issues and discussions will be triaged, and perhaps participate in real-time discussion. Karim will research some possibilities for real-time discussion and make an announcement on the mailing list when something is set up. If community members have any ideas about what would make these “office hours” useful, they are invited to post their ideas as a discussion at the MusicXML GitHub.
MNX
Adrian is feeling good about the current proposal for the specification of fermatas (
issue #106
). The feedback we’ve had from the community is all for things that can be added in the future, so the plan is to proceed to merge the proposal for now.
Notationref
Adrian is still working through the MusicXML branch to implement information about the level of support for each notational element in MusicXML. It’s laborious and Karim is also reviewing parts of it.
Next meeting
The next co-chairs’ meeting is scheduled for
Wednesday 29 April 2026
Co-chair meeting minutes: March 24, 2026
Daniel Spreadbury
Posted on:
March 24, 2026
Meetings
We have decided to move the co-chair meeting to a bi-weekly cadence on Wednesdays, starting 8 April 2026. Our Tuesday meetings will remain, but will be purely focused on MNX specification issues.
MusicXML
Karim has started working on the roadmap for the MusicXML 4.1 release. He’s intentionally keeping it modest so that it can be possible to release reasonably often. Adrian has started work on adding MusicXML information to the new
notationref
format: he proposes that once this has been finalised, MusicXML and MNX should each host their own notationref JSON data, so that this can be kept up-to-date as new commits are added to the standard.
MNX
We discussed the encoding of fermatas. We agreed that we would encode the appearance of the fermata (using the values from the
fermata-shape
enumeration in MusicXML as the basis) separately from its played duration (for which we proposed a kind of abstract duration enumeration, which would have values for automatically-determined duration, no effect on playback duration, and abstract durations from very short to very long). We propose that fermatas should be attached to events in sequences, with the special case of a fermata on a barline being encoded in the global bars list. Adrian will prepare a formal proposal for this and publish it for community feedback in the coming days.
Next meetings
The next MNX working group meeting is scheduled for
Tuesday 7 April 2026
. The next co-chairs meeting is scheduled for
Wednesday 8 April 2026
Co-chair meeting minutes: March 10, 2026
Daniel Spreadbury
Posted on:
March 10, 2026
Community Group meeting
A reminder that we will have a virtual meeting next
Tuesday, 17 March 2026 at 4pm UTC
to which all Community Group members are invited. This meeting is a chance for the co-chairs to provide an update on each of the CG’s specifications – SMuFL, MusicXML, and MNX – and for the new MusicXML specification editor and co-chair, Karim Ratib, to introduce himself to the community.
MNX
Adrian has completed the specification for which characters are allowed in IDs (
issue #503
): up to 256 ASCII characters, and no spaces or non-printable characters can be used. This ID system is designed to make it possible to use the internal IDs used by other applications (for example, MuseScore) in MNX documents.
We spent a bit of time discussing the default file extension for MNX documents, and whether we would need an OCF-style container for MNX, per
discussion #416
. Our current thinking is that we probably do not need a container, so we propose that MNX documents should have the file extension
.mnx.json
. Consuming applications can check the file extension, that the document parses as JSON successfully, and that it has a top-level
mnx
key.
Next meeting
The next meeting is the Community Group virtual meeting on
Tuesday 17 March 2026
. The next co-chairs’ meeting is scheduled for
Tuesday 24 March 2026
Co-chair meeting minutes: February 24, 2026
Daniel Spreadbury
Posted on:
February 24, 2026
SMuFL
Karim has some ideas for changing the metadata and tools for working with them, so Daniel encouraged him to open issues for those things
MNX
The schema now has an official version number, and the version number is incremented with each revision; it started at 1 and is now at 4 already;
issue #497
is thus addressed.
There has been some good discussion about measure indexes, measure numbers, and how you point at measures from other places within an MNX document (
issue #447
). The indexing part has now been nicely addressed: we previously used a 1-based index for referring to bar numbers. We discussed changing it to being 0-based, but instead we decided to use the measure ID. Multi-measure rests, the measure rhythmic position object, and system (part of the layout infrastructure) now all use IDs.
One remaining thing for measure numbers is the label (
issue #501
). There has been a spirited discussion about how to encode the label. We don’t yet have a really clear definition of what we’re trying to achieve: it could be more than simple numbers. A couple of suggestions have been made for how this should be encoded. Myke proposes that this is good enough for now, and that we punt issues concerning bar numbering for Broadway and other similar niche cases for the future, or encourage that community to make a proposal that we can include later on.
The next issue to consider is what constitutes a valid ID. We don’t currently provide any info beyond that it should be a string. Our original idea was a simple alphanumeric value, but Robert Patterson pointed out that it would be nice to save MuseScore’s internal ID, which contains other characters. Adrian will make a proposal for
issue #503
for this. We briefly discussed whether the string should use only printable ASCII characters, and agreed this is probably sufficient.
Next meeting
The next co-chairs’ meeting is scheduled for
Tuesday 10 March 2026
Co-chair meeting minutes: February 10, 2026
Daniel Spreadbury
Posted on:
February 10, 2026
Co-chairs
A point of clarity: following the appointment of Karim Ratib as the new MusicXML specification editor, he is also now co-chair of the Community Group, joining Adrian and Daniel. Myke is no longer co-chair, but remains closely involved in the development of MNX. The Community Group web site, GitHub repositories and wiki will all be updated in due course to reflect this.
MusicXML
Adrian, Daniel, and Myke congratulated Karim on the excellent start he has made as spec editor, including making contact with other experts in the community and making some initial decisions about long-standing issues. Karim is also working on a presentation about his vision for the future of MusicXML and how it compares to MNX, which he will share at the forthcoming Community Group meeting in March.
MNX
Adrian has merged the pull request for the encoding of full measure rests, so
issue #475
is now closed. Adrian has also made some small documentation changes to close issues
#480
and
#481
Per
discussion #494
, community member Robert Patterson has implemented MNX import and export for MuseScore, and his pull request has been accepted by the MuseScore developers. This has raised the importance of versioning of the specification, so that it is easier to identify the level of support in applications like MuseScore, per
issue #497
After some discussion, we propose that we will use a URL for the version of the form
that doesn’t resolve to a valid URL. We propose that while MNX is in heavy development we will simply increment the integer at the end of this URL, and then consider jumping to, say, 1000 for the first stable release.
We discussed
issue #447
, and agreed that we should remove
index
from
global-measure
, since it is no longer needed.
Next meeting
The next co-chairs’ meeting is scheduled for
Tuesday 24 February 2026
Co-chair meeting minutes: January 27, 2026
Daniel Spreadbury
Posted on:
January 27, 2026
Forthcoming Community Group meeting
Everybody in the Community Group is invited to attend a virtual meeting on
Tuesday 17 March 2026 at 4pm UTC
(5pm CET, 11am EST, 8am PST). This meeting will give the first opportunity to hear from our new MusicXML specification editor, Karim Ratib, and updates on the MNX and SMuFL projects.
We will share the Zoom link for the meeting in due course. In the meantime, please save the date!
Changes to co-chair meetings
Following Karim’s appointment, the co-chairs have decided to modify our cadence of meetings. We will continue to meet every two weeks, rotating through three meetings: two meetings will be focused on MNX, with the third being more broadly about updates from the spec editors of all three active projects (MNX, MusicXML, and SMuFL).
MNX
Adrian has implemented group barline styles (
issue #471
), as discussed in the previous co-chair meeting, and has updated relevant example documents to make use of this new functionality.
Adrian has also created a branch with a new approach for full measure rests (
issue #475
). The new approach introduces a
fullMeasure
attribute on
sequence
. Events no longer have a
measure
attribute, which means that duration for events is now always required, which is a good improvement, and also allows a simplification in the parsing of sequence content. A
new example document
has also been created to demonstrate these changes. Further community feedback is welcomed before this is adopted into the specification.
Next meeting
The next meeting will be an MNX working group meeting, on
Tuesday 10 February 2026
New MusicXML specification editor appointment
Daniel Spreadbury
Posted on:
January 27, 2026
Karim Ratib
We are pleased to announce the appointment of Karim Ratib as the new MusicXML specification editor, with immediate effect. He succeeds Michael Cuthbert, who will remain one of the three co-chairs of the Community Group, but will now focus his efforts entirely on helping drive the MNX specification forwards.
Members of the Community Group will have an opportunity to meet Karim for the first time in our planned virtual Community Group meeting in March 2026.
In Karim’s own words:
My name is Karim Ratib. A professional software engineer by trade, I am also a lifelong music lover and player. Although I wrote my very first music application around 1985 on the venerable Sinclair ZX Spectrum, I was introduced to modern music notation software about ten years ago when I started adapting classic Egyptian popular songs to my modest guitar and singing abilities. My dreams of creating the “Arabic Real Book” soon took the back seat to understanding and enhancing how music technologies support use-cases outside the mainstream. Since then, I’ve engaged with many music communities online – MusicXML, SMuFL, MIDI, MuseScore, Verovio to name a few. As a firm believer in the benefits of open formats and open source for the common good, I am delighted to accept the role of MusicXML editor. My goal is to support the evolution of MusicXML by fostering a worldwide community of music notation stakeholders, from experts and musicologists to performers and learners, without forgetting the developers of music tools. I will apply my skills and experience in engineering management to maintain this valuable format and I hope to be an effective steward during the time of my tenure.
Co-chair meeting minutes: January 12, 2026
Daniel Spreadbury
Posted on:
January 12, 2026
MNX
For applications that need hints for the encoding of ties across repeat endings or other non-contiguous notes (
issue #476
), we have now added a
targetType
attribute to the
tie
object.
For encoding whole measure/bar rests (
issue #475
) we propose adding a
fullMeasure
attribute on the
sequence
object, which can contain a
representation
object, which can contain a
rest
object (and perhaps in future objects of another type, for example to allow you to specify that it should be blank rather than showing a rest).
We also discussed Adrian’s proposal for how to encode barline grouping across multiple staves (
issue #471
), and decided that we would expand the proposal such that the default should be for barlines to join all staves belonging to the same instrument. We discussed how to handle edge cases like organs (where typically the staves for manuals are joined by a single barline, and the staff for the pedal has its own independent barline) and whether this would require explicit encoding.
Next meeting
The next co-chairs meeting is scheduled for
Tuesday 27 January 2026
Co-chair meeting minutes: December 30, 2025
Daniel Spreadbury
Posted on:
December 30, 2025
MNX
We discussed some of the issues and discussions that have been raised by members of the community in the last little while:
Discussion #469
proposes that the
measures
object in part should be mandatory, and should have the same number of items as the global
measures
object; we agree, and will make this change.
Discussion #467
asks what a consuming application should do when
mnx.supports.useBeams
is set to
false
, but beams are encoded in the document anyway. For the moment, we will recommend that if
useBeams
is
false
, the consuming application can decide whether any encoded beams in the document should be respected. In the future, we foresee the need to specify strategies for beaming at the level of time signature/meter or measure, so that documents can encode only beaming overrides (places where notes should be explicitly unbeamed or beamed); we will return to this in future.
Discussion #472
asks for clarifications concerning how sequences and beams interact. The general principle is that beams should only reference events from the same sequence, except in the case of beams that cross barlines, in which case, the sequences will be different but must belong to the same part voice.
Next meeting
The next co-chairs meeting is scheduled for
Monday 12 January 2026
Co-chairs meeting minutes – December 2, 2025
Daniel Spreadbury
Posted on:
December 2, 2025
MusicXML
We discussed the candidates for the MusicXML specification editor position, and both the depth and quality of commitment of this community to MusicXML impressed us and warmed our spirits. The co-chairs will be contacting candidates in due course to discuss next steps.
MNX
We continued to discuss tempo markings (
issue #113
) following our discussion in the previous co-chairs meeting. We decided that swing or rhythmic feel markings, despite often being displayed in line with tempo markings, or sometimes in place of them, are sufficiently different from tempo marks as to be encoded using a separate object, which we will return to in future.
After much discussion, we arrived at a proposal for a minimal representation of tempo: a label, defined as a simple string; and the tempo value, defined as a note value unit and a numeric value, both of which are optional. We’ll assume that consuming applications will be able to construct a default displayed appearance for the tempo item using either or both of these values. To make it possible to specify precisely how the tempo should be displayed, we propose adding an optional rich text object, which can define the displayed appearance. We propose extending the formatted text item to define references to other objects, so it’s possible to reference the label and tempo value data in order to avoid redundantly encoding the same values in two places.
We welcome feedback on this proposal, which you can read
here
Next meeting
The next co-chairs meeting is scheduled for
Tuesday 16 December 2025
Tools for this group
Learn about available Community Group tools and how to configure a group's site to include links to tools on w3.org or elsewhere.
Mailing List
@ public-music-notation
@ public-music-notation-contrib
@ internal-music-notation
Wiki
IRC
Version Control
GitHub repository
MNX GitHub repository
MusicXML GitHub repository
Notation Ref Github repository
RSS
Contact This Group
Get involved
Learn more about how to join a group.
Anyone may join this Community Group. All participants in this group
have
signed the
W3C Community Contributor License Agreement
Join or Leave this group
Chairs
Daniel Spreadbury
Adrian Holovaty
Karim Ratib
Participants (
357
View
all participants
Archives
April 2026
March 2026
February 2026
January 2026
December 2025
November 2025
October 2025
August 2025
July 2025
June 2025
May 2025
April 2025
Categories
Announcements
Events
Minutes
MNX
MusicXML
SMuFL
Use Cases
Footer Navigation
Standards
Groups
Get involved
Resources
News & Events
About W3C
Contact W3C
Contact
Help
Support us
Legal & Policies
Corporation
Systems Status
W3C Updates