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/smuflGroup'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.
Following some feedback from Robert Patterson on our proposal for how to encode dynamics, we agreed that we would change gradual dynamics to express their extent using measure position instead of duration. This is both consistent with how octave lines are encoded.
We also decided that gradual dynamics should have no end value, because this can create an ambiguity in the event that you have multiple abutting gradual dynamics. We will instead only define the starting dynamic, and if you need to define the end dynamic, you will add an immediate dynamic at the gradual dynamic’s end position.
We also decided that we would not need to encode messa di voce in a special way: a crescendo-diminuendo swell can be encoded as a pair of abutting gradual dynamics.
Adrian will tighten up these final details and then add the current proposal to the specification.
Measure repeats
We made good progress on an initial design for measure repeats, sometimes known as ditto or simile marks. We propose that each measure will have an optional measure repeat object, which will be set for the first measure that shows the measure repeat; for a one-measure repeat, each successive bar will have this set; for a two-measure repeat, the first bar will have this set, and the second bar will not, and so on. Each measure repeat will specify the number of measures to be repeated, an optional count (to show that this is the nth repeat in a sequence of measure repeats), and an optional number of slashes in the measure repeat symbol.
Adrian will prepare a formal proposal for this in due course and share it for community feedback.
In our next meeting we will discuss beat repeats, or slashes.
Next meeting
The next specification working group meeting will is scheduled for Tuesday 16 June 2026.
Adrian has put together a proposal for the encoding of dynamics (issue #518) which is now ready for community feedback. However, we quickly got involved in discussing the text object, and how it didn’t feel quite right that in common cases (such as “sempre f“) it would be necessary to effectively encode the value of the dynamic (f) twice, once in the value field and then again using a SMuFL glyph in the text field.
We propose that instead we should have prefix and suffix fields that contain a plain string that can be drawn to either side of the dynamic value. In this way, text only needs to be specified for very unusual cases.
We also talked at length about modifiers, and ended up with a proposal of the values for an enumeration that can go alongside value (containing, among others, “more”, “less”, “immediately”, “as much as possible”, etc.).
This led us to consider dynamics that express an immediate relative change, such as “a little louder” or “much softer”, and so we propose that we will add a new relative dynamic type.
Adrian will extend the issue with formal proposals for these aspects, and we look forward to reading feedback from the community about them.
Measure and beat repeats
We had planned to discuss bar/measure and beat repeats (issue #122) but ran out of time. We will consider this in our next meeting. If any members of the community would like to bring any specific concerns in this area to our attention, we invite you to add details to issue #122 ahead of our next meeting.
Next meeting
The specification working group will next meet on Tuesday 2 June 2026.
Daniel, Adrian and Karim were unable to meet, but Karim has provided the following MusicXML update.
MusicXML
The new MusicXML docs site (issue #644) is fully functional and pending some cosmetic fixes before we can deploy it live. We’ve received some feedback already and encourage more users to review it. One specific area where we could use more eyeballs is the changes made to the xsd schema files to move the documentation from the site back into the specific elements/attributes/types:
Milestone 4.1 has been revived and the set of tagged issues is more or less final. I believe I have a good grasp on what needs to be done for each, but I welcome community review of those issues specifically.
Regarding milestones and releases, and given some feedback from Michael Good (@mdgood), I am thinking of targeting multiple minor releases per year, which will include documentation changes and minor edits to the schema such as new enumeration values, new attributes. Deprecations, new elements and other major changes will be kept for major releases once per year or less. I’ve started a Milestone 5.0 to that effect. What’s missing is a “release manual” which lists all the chores needed for a release.
Semantic validation (pull request #627) is stalled and will resume over the summer. The core proof of concept is done (Schematron being the selected technology). A good initial set of validations has been identified, mainly thanks to Werner Lemberg (@lemzwerg). What’s missing is to organize all this in a new “test” area of the repo.
Next meeting
The next co-chairs’ meeting is scheduled for Wednesday 3 June 2026.
Adrian has also updated MNX in notationref to account for these changes.
We spent the majority of the time resuming our discussion about the representation of dynamics, with a particular focus on how gradual dynamics (hairpins, cresc., dim., etc.) should be encoded. After some lively discussion, we arrived at consensus on an approach that Adrian will write up for community discussion in the coming days.
Next meeting
The next MNX specification working group meeting is scheduled for Tuesday 26 May 2026.
We believe that any remaining issues arising from the move from the w3c GitHub organisation to w3c-cg have now been resolved. However, we think that there is more we could do in future to protect against these kinds of changes, and are considering a new domain for all the projects of the CG to live behind, so that we can have new canonical URLs completely under our control. We’ll provide more details in due course.
MusicXML
Work to replace the specification based on the doc generator with a new version built on Astro is proceeding well. Progress can be followed at issue #644 and pull request #651.
Karim reported on the interesting discussions that have been proceeding in the issues and discussions on the MusicXML GitHub repository, and some of the ideas that are percolating. In particular, he is excited about the possible boundaries that are being revealed, and especially where the line should be drawn between being descriptive versus prescriptive.
Karim is also working on a set of semantic tests (issue #621) which aims to supplement schema validation of MusicXML. If members of the community have ideas for the kinds of MusicXML documents that could form the basis of these kinds of tests, where there are clearly invalid constructs that are syntactically valid, they are welcome to contribute them to this thread. As an example of the kind of semantically invalid structures that this could include, a document that contains a “to coda” marking but is missing the “coda” marking with a matching label. These situations are very common and impossible to avoid using only schema validation.
SMuFL
Daniel briefly described a new issue (#336) he added to the SMuFL 1.5 milestone to describe the basic appearance of a music font, i.e. whether it has an engraved or handwritten appearance.
Next meeting
The next co-chairs’ meeting is scheduled for Wednesday 13 May 2026.
Fermatas (issue #106) are now complete, and can be found in the specification here.
One missing detail is that we do not currently encode both the orientation of the fermata relative to the staff as well as the direction in which the fermata symbol itself is pointing. Adrian proposes that we encode this using orient for placement and pointing for the direction of the symbol. We will also add this to the other event.markings items for which it makes sense (for example, pointing makes sense for strong accents/marcatos, but not for regular accents).
Bowing marks
Adrian proposes that we add up bow and down bow to event.markings. We propose adding a bowDirection entry with an enumeration with values representing up bow, down bow, and bowing freely (which is sometimes depicted as showing both up bow and down bow symbols next to each other).
Arpeggios
We discussed how arpeggios could be encoded. After some back and forth, we propose that a list of arpeggios should be found in the part measure, at specific rhythmic positions (in the same way that clef changes are encoded). We propose a direction enumeration with auto (implying up), up, and down, and a boolean arrow, false by default, that specifies whether an arrow should appear. We also propose an object to encode the starting and ending notes by ID, which if used must specify both. (This may prove useful for other similar notations with specific starting and ending points in future.)
We also propose a similar object for chords that definitely should not be arpeggiated, which is typically drawn as a square bracket to the left of the chord, the equivalent of MusicXML’s non-arpeggiated element.
Hairpins
Towards the end of the meeting we began a brief discussion about hairpins (continuous gradual dynamics). There is much more to discuss, but as a starting point, we plan to extend the existing dynamic object to have an optional end position (or ID for an event) so that it can describe a range, and then consider how to specify the value (dynamic type) in order to denote that it represents a gradual vs. immediate change. Adrian will make a proposal for community discussion.
Next meeting
Our next meeting is scheduled for Tuesday 12 May 2026.
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.
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.
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.
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.
w3c/smufl
