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.
We were very pleased to receive a pull request from new contributor, Owen Williams, who identified a problem with the storage of the dynamic constants.
Measure repeats
The work on encoding measure repeats (issue #520) has been incorporated into the spec, including some new example documents (here and here).
Pointing
We discussed at some length the issue around the pointing object in strong accent (issue #525), and we believe that this is directionally correct. We think that making it possible to define an arbitrary glyph is not really right: it’s not really helpful to be able to define, say, a clef glyph to appear for a marcato. We propose that we should address this on a per-object basis, and use an appropriate term for each object, rather than trying to force everything to fit this single term.
We are also considering whether the term orient to describe whether an item is placed above or below the staff should be changed: upon reflection it feels as if placement (as used in MusicXML) would be clearer.
Next meeting
The next working group meeting is scheduled for Tuesday 11 August 2026.
The updated documentation site is up, and as of the last few days now also has search functionality.
Work is continuing on the test infrastructure. Every commit now goes through a set of test that are meant to validate the schema’s syntax, and tests for the examples included in the documentation. Schematron infrastructure is now also in place, and work is proceeding on coming up with trapping issues that are syntactically valid but semantically incorrect. Karim eventually hopes to document how developers of implementations of MusicXML can use these tests to validate that their application’s export is semantically correct.
Myke Cuthbert has also contributed his fork of the MusicXML test suite to the CG, and that repository has now been moved to the w3c-cg organisation.
In addition to this important infrastructure work, Karim has started working on the roadmap for MusicXML 4.1. He’s made a checklist of everything that would need to go into a pull request for a schema modification: this needs to include not only the schema modification, but also documentation, examples, and so on. Now that he has the process, he’s following it and refining it as he goes. Two or three items have already made it onto the roadmap and he is working on more. This Version History page will be maintained with the changes as they arise.
Karim is also encouraged by the detailed discussions on specific notations, including for improving the representation of ties and slurs. Karim also plans to send a regular update to the public mailing list with progress on specific issues.
notationref
Karim has merged in the current state of support for MusicXML to notationref. Our plan is to move the canonical location for the MusicXML and MNX JSON files to their individual repositories.
Next meeting
The next co-chairs’ meeting is scheduled for Monday 10 August 2026.
Myke was unable to attend this meeting due to travel commitments, so only Adrian and Daniel were in attendance for this session.
Dynamics
We agreed to expand the number of dynamic levels from ppp<->fff to pppppp<->ffffff, to match MusicXML and the range of glyphs provided in SMuFL (#521)
For accent-dynamic, we agreed that we would use the same dynamic levels as an immediate dynamic, with two enumerations for prefix and suffix, allowing you to specify a prefix of s, r or nothingand a suffix of z or nothing. (#521)
We agreed that we would add an optional ID – for now called visuallyContinues – that specifies a previous dynamic that should be considered as linked for the purposes of alignment (#521)
We revisited how we handle fp dynamics and propose that we remove attackValue and instead encode them as accent-dynamics, with a new residualValue value to specify that the dynamic level continues as p (#522)
To accommodate a gradual dynamic that ends on a different staff, we will add endStaff to dynamic group, using the staff number (#523)
Measure repeats
We haven’t had any community feedback on the proposal for measure repeats (#520), so Adrian plans to go ahead and add this to the spec as-is.
Next meeting
The next MNX specification working group meeting is scheduled for Tuesday 28 July 2026.
Adrian has added the work to date on dynamics to the specification. After further discussion in the meeting today, we have settled on a system that provides four dynamic types: immediate, gradual, relative, accent.
For the case of fp dynamics, there’s an “attackValue” (allowing a distinction between attack value and persisted value) for immediate dynamics.
To specify the end of a hairpin, there’s an “end”, matching how ottavas are encoded (as opposed to the original idea of giving the hairpin a duration).
There’s a “glyphs” array, allowing the encoding of a specific series of SMuFL glyphs, for cases where the enum of dynamic values doesn’t include what should be visually rendered.
Instead of rich text (which would by definition require the redundancy of encoding the dynamic value twice), there’s a “prefix” and “suffix”, both of which are strings.
There’s a “relative” type, for dynamics such as “più p” (meaning “quieter”).
We’ve also decided to add “n” (niente) to the dynamic value enum.
Measure repeats
Adrian has created issue #520 with a proposal for measure repeats, based on the discussion in our previous meeting. We welcome community feedback on this proposal.
Beat repeats
We spent the remainder of the meeting discussing potential approaches for beat repeats, or slashes. A couple of promising approaches presented themselves, but we will discuss further in our next meeting and then formulate a proposal.
Next meeting
The next MNX specification working group meeting is scheduled for Tuesday 30 June 2026.
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.
w3c/smufl
