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.
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.
The main focus for MNX development continues to be the proposal to move MNX from using XML to JSON.
Adrian is working on sample MNX documents in JSON format but doesn’t yet have anything to share; he expects to have some documents ready to share before the next co-chairs’ meeting. He is also continuing to look at the various options for JSON schemas in order to provide validation for those developers who are looking for it.
The co-chairs would also like to remind the community about issue #288, which is still under active review. This issue concerns reworking the accidental attribute for notes to remove redundancy and instead specify whether the accidental should be visible. Adrian proposes to move to a pull request for this issue, unless the community has any further feedback.
Next meeting
The next co-chairs’ meeting is scheduled for Tuesday 14 February 2023.
The co-chairs discussed at length the feedback we have received so far concerning our proposal to adopt JSON as the format for MNX documents in future. We consider the issue still open, and welcome further feedback from the community. Please catch up with the existing discussion in issue #290 and discussion #291, and add your feedback to the discussion thread rather than the issue.
As a next step, Adrian is going to prepare one or two MNX documents in JSON format so that the community can see some concrete examples of how a non-trivial MNX document will look in JSON. We are also going to investigate the different possibilities for JSON schemas, and will create a basic JSON schema to demonstrate validation for MNX documents.
Adrian has also updated the MNX specification to reflect the recent decision to encode sounding pitch rather than written pitch in MNX documents.
MusicXML
Myke is currently investigating the status of the musicxml.org domain, which has been offline for some time.
Next meeting
The next co-chair meeting is scheduled for Wednesday 1 February 2023.
My fellow co-chairs and I have been considering making a fundamental change to MNX: we’d like to use JSON instead of XML.
Read all about it in this new GitHub issue. In it, I outline the rationale and arguments for/against. And after you’ve read it, please leave your feedback!
Given that this would be such a huge change, I wanted to post a quick blog entry here, to cast as wide of a net as possible for potential feedback. I hope you’re as excited about this idea as I am.
This was the final co-chair meeting for Michael (Good), who is leaving his position as co-chair today as he prepares to retire this week. New co-chair Michael Scott Cuthbert has been joining our meetings for the past two or three iterations in any case, so going forward the three co-chairs will be Daniel, Adrian, and Myke.
We thank Michael for all of his contributions to the community group, and of course his broader contributions to the field of music notation over the past two decades. He will be missed, though he will remain a member of the Community Group and we know he is looking forward to contributing to the group’s activities in his retirement.
Meeting at MOLA Conference in Berlin, Friday 2 June 2023
We are pleased to announce that plans are moving ahead for the W3C Music Notation Community Group to hold an in-person meeting on Friday 2 June 2023 as part of a new technology-focused day immediately preceding the 41st Annual MOLA Conference, to be hosted by the Berlin Philharmonic (2–5 June 2023).
The Tech Fair, to be held at the Hanns Eisler School of Music, will be an opportunity for technology-focused presentations, potentially including from organisations and companies that are members of the Community Group. If you would be interested in participating in the Tech Fair, please contact the chair of the MOLA Technology Committee, Mark Fabulich, and Amy Tackitt, MOLA’s Administrator. Mark can be reached at mfabulich at bso dot org, while Amy can be reached at amytackitt at aol dot com (please excuse the simple obfuscation of the email addresses; this is to avoid them being too easily picked up by scrapers and bots).
The current expectation is that the W3C Music Notation Community Group meeting will take place at the conclusion of the Tech Fair schedule, at 3.30pm Berlin time (2.30pm London time, 9.30am New York Time, 6.30am Los Angeles time). We encourage as many CG members as possible to plan to attend in person, but we are also planning to provide online access to the meeting if possible.
More details will be forthcoming in due course.
MNX
The co-chairs have been discussing a significant proposal about which Adrian will provide more information in a separate blog post soon – keep your eyes open for that.
Adrian also reported that he has yet to complete the work on modifying the specification to work through the implications of the change to using sounding pitch rather than written pitch throughout MNX, but is planning to work on this very soon.
MusicXML
Myke has raised issue #478 concerning the measure attribute for the rest element, and what it means for irregular cases such as pick-up bars. Michael provided an initial comment that the intention is that the type element is controlling for what gets displayed, but will look into this a bit further and add a comment to the issue. Any further feedback on this issue from other implementors of MusicXML would be welcome.
Next meeting
The next co-chairs’ meeting will be on Wednesday 18 January 2023.
There has been some good discussion around the proposal for how to represent differences in note spelling between layouts (issue #287), though as yet no winner has emerged. The current front-runner is some variation on Adrian’s proposed Option 2, which encodes the shift from the sounding pitch to the written pitch using a pair of diatonic/chromatic values, and an optional “part-accidental” attribute to specify whether it should be visible independently from the accidental for the unshifted pitch. Adrian will produce some examples using this approach in a pull request for further discussion.
Consensus has at least developed around changing the representation of pitch in MNX to be sounding pitch rather than written pitch, so Adrian proposes making this change to the specification and to the examples (only the octave lines examples would really be affected).
Adrian has written up a proposal for cleaning up the redundancy in the accidental attribute in issue #288, and further community feedback is welcomed.
Next meeting
Due to the forthcoming holiday period, the next co-chairs’ meeting will be on 3 January 2023.
The social media accounts for MusicXML on Twitter and Facebook that have been maintained by Michael on behalf of MakeMusic will be transferred into the stewardship of the W3C Music Notation Community Group, with Myke appointed as the new maintainer of these accounts. These accounts will be handed over to Myke around the time of Michael’s retirement in January.
As a reminder, the W3C Music Notation Community Group also has a YouTube channel where recordings of our in-person and online meetings can be found.
MNX
Issue #287 with the proposal for how transposing instruments and differences in part layouts should be handled is still awaiting community feedback, which would be most welcome!
In the meantime, Adrian has been working on trying out these proposals in the mnxconverter project, including some refactoring on the main branch to prepare for the proposed changes to how pitch is handled in MNX (using sounding pitch instead of written pitch). In conjunction with this, Adrian has also created a new branch (mnx-287) in which he has tried out the importing of MusicMXL files and transposing the pitches in there to sounding pitch using a simple algorithm.
We also discussed the accidental attribute of the note element (see examples here). At the moment, accidental redundantly specifies the type of accidental that is also expressed as part of the micro-syntax for the pitch attribute. After some discussion, we agreed that Adrian should write a proposal for changing the meaning of the accidental attribute to capture whether and how the accidental is shown using a simple enumeration. Adrian will write an issue outlining this proposal in the near future.
Next meeting
The next co-chairs’ meeting is scheduled for Tuesday 6 December 2022.
Michael Scott Cuthbert has agreed to take on the roles of MusicXML spec editor and co-chair of the W3C Music Notation Community Group to succeed Michael, who is retiring at the start of January 2023. Myke joined today’s meeting for the first time. We are delighted to welcome Myke as incoming co-chair and look forward to his contributions to the group’s efforts.
MusicXML
In a previous meeting, the idea was posited that the Dolet plug-in for Sibelius might be transferred into the guardianship of the W3C Music Notation Community Group, but the decision has been made that in due course MakeMusic will release the source code for the plug-in in a public GitHub repository licensed under the MIT License.
MNX
Adrian has created issue #287 to cover the proposal for how to encode instrument transposition. There’s a lot of detail contained in this proposal and we welcome feedback from the community. Adrian’s next step is to try these ideas out in the mnxconverter project with some real MusicXML data to see how it works in practice.
Next meeting
The next co-chairs’ meeting will be on Tuesday 22 November 2022.
MusicXML spec editor and co-chair selection process
The three co-chairs discussed at length the interviews that were held last week with the three excellent candidates to succeed Michael as MusicXML spec editor and Community Group co-chair. Daniel will be contacting the candidates soon to discuss the outcome of the selection process.
MNX
Adrian is still working on the proposal for how differences in enharmonic spelling between concert and transposed pitch scores and parts might be captured (issue #34), and expects to have a proposal ready for review soon.
SMuFL 1.5
Daniel has made some progress on some of the issues in the SMuFL 1.5 milestone (you can review the open pull requests here), and hopes to devote some more time to some of the remaining straightforward issues involving the encoding of new symbols in the coming week.
Next meeting
The next co-chairs’ meeting will be in four weeks, on Tuesday 8 November 2022.
Adrian brought an initial proposal for the encoding of pitches between transposed and concert pitch layout (issue #34) for discussion. The co-chairs have agreed on the basic details, and Adrian will present the proposal to the wider CG once some examples are a little more fleshed out.
MusicXML
As we prepare for Michael’s retirement, one of the issues he is looking to resolve is the future of the Dolet for Sibelius plug-in. MakeMusic has expressed the wish to convert the plug-in to use an open source license, and Michael asked his fellow co-chairs to consider whether the CG would be a suitable home for this plug-in. Another alternative would be for Michael to host the plug-in on a public respository himself, but he does not want to be responsible for the future maintenance of the plug-in. If any CG members have any thoughts or ideas about this plug-in, or would be interested in taking on the maintenance of the plug-in in future, they are welcome to the contact the co-chairs.
The three co-chairs are also in the process of scheduling meetings with the candidates who have expressed an interest in taking on the roles of spec editor for MusicXML and co-chair.
Next meeting
The next co-chairs’ meeting is scheduled for Tuesday 11 October 2022.
As part of the W3C TPAC 2022 conference, the W3C Music Notation Community Group held an online meeting via Zoom on 15 September 2022. The presentations from the meeting are posted at:
We recorded the meeting on Zoom and have posted it online at YouTube. Zoom provides an automatic transcription feature, so a complete transcript is also available via closed captioning. The video starting times for each part of the meeting are included in the headings below.
The following people attending the meeting via Zoom:
Michael Good, MakeMusic (co-chair)
Adrian Holovaty, Soundslice (co-chair)
Daniel Spreadbury, Steinberg (co-chair)
Douglas Blumeyer
Eric Carraway, percuss.io
Michael Cuthbert, MIT
Jim DeLaHunt
Fabrizio Ferrari, Virtual Sheet Music
Samuel Fuentés Fernandez, Universidad Politécnica de Madrid
Dominik Hörnel, capella-software
Reinhold Hoffman, Notation Software
Markus Hübenthal, capella-software
James Ingram
Jeff Kellem, Slanted Hall
Tristan Labelle
Mingyu Lei
Christina Noel, Musicnotes
Alexander Plötz
Klaus Rettinghuas, Enote
Philip Rothman, NYC Music Services
Jeremy Sawruk
Dominique Vandenneucker, Arpege Music
Introduction to the Music Notation CG (2:16)
Michael Good began with an introduction to the work of the W3C Music Notation Community Group. This includes the very popular published standards, MusicXML and the Standard Music Font Layout (SMuFL), as well as the newer MNX project that is under development.
MNX update (7:30)
Adrian Holovaty provided an overview on recent MNX progress. We addressed several difficult architectural issues over the past year, including:
The new concept of “layouts,” which allow music to be encoded in a single MNX file with multiple representations (e.g. full score, condensed score, individual parts). Each representation is called a score. Layouts contain the presentation information for a score, or for a system within a score.
A “styles” infastructure, providing a way to apply presentation information to a subset of notation in the score. Inspired by CSS stylesheets, styling can be applied either globally to elements, or by classes that are specified within the musical data. Styles can be global to a document or specific to a score.
How to represent notational differences between scores and parts (as opposed to the aforementioned layouts and styles). The first area we addressed is multimeasure rests, which are defined on a per-score basis within an MNX document. This should be able to serve as a model for other data that differs between scores and parts, such as enharmonic note spelling.
All these features work together to help separate presentation information from musical semantic information, a key requirement for many of the MNX use cases.
The MNX specification and “By Example” documents were both moved over to the group’s new documentation system in the past year, and some smaller specification issues were also addressed.
Jim DeLaHunt asked about preparing choral rehearsal scores that emphasize one voice part while de-emphasizing others—say by putting the singer’s part on one staff, and the remaining parts on a single combined staff with smaller notes—and what features would be used to achieve this. Layouts are the main feature that would be used here. This is an example of an MNX use case for digital score features that goes beyond what is available in printed scores.
Next steps with MNX are to:
Finalize the list of V1 features, now that most of the outstanding major architectural issues have been addressed.
Implement each remaining V1 feature using an example-first approach.
Continue implementing the mnxconverter open-source utility for converting from MusicXML to MNX.
People can get involved by following the MNX issue tracker on GItHub. Posting opinions, even if it’s just a thumbs-up, is helpful. We also post updates on the Community Group blog, but most MNX conversation happens on GitHub.
SMuFL update (25:05)
Daniel Spreadbury provided an update on plans for SMuFL 1.5. While the new version will add a few dozen new symbols, the main focus is on improving font-specific metadata, especially regarding optional glyphs. This includes:
Defining categories of optional glyphs (e.g. for different sizes or different historical periods)
Allowing grouping of optional glyphs into sets
Making it easier for applications to use, and present to the user, optional glyphs as alternates.
SMuFL 1.5 will also rework the definition of fonts used in text-based applications. It will move away from supporting simple music layout like the Bach font does, and instead support the simpler and nowadays much more common use cases of inserting individual musical symbols into text. As far as we know, Bravura Text is the only font that has ever implemented the more complex text font specifications.
We are also asking for translated human-readable descriptions for glyphs and ranges. Transifex provides a translation platform which is available for free to open-source projects like SMuFL, and that is where we have set up the translation project. We have the SMuFL 1.4 versions of ranges.json and glyphnames.json posted on this project and would be grateful for community contributions. Please don’t feel that you need to translate all 12,000 words to help out. Any translations or reviews of translations will help.
Another way to contribute is to follow the SMuFL GitHub issue tracker. The SMuFL 1.5 milestone indicates what is in scope. Look for issues with the label “Awaiting feedback” for those in particular need of review, often dealing with larger issues than just adding a well-documented glyph to a specific range.
Jim asked about the impact of the Unicode 15 release. Daniel answered that new Unicode releases generally do not affect SMuFL. All of SMuFL’s characters are in the Private Use Area in the Basic Multilingual Plane, which does not change between Unicode versions. While it is possible in the future that we might want to include some SMuFL ranges in Unicode proper, it is not currently in our plans, especially as more and more fonts and applications adopt the SMuFL standard.
Jim also asked about the use of OpenType variable font techniques in music notation fonts. OpenType variable fonts allow a single font to act like multiple fonts with continuous interpolation between different designs. Daniel answered that SMuFL tries to be as font-agnostic as possible. Even though most fonts these days are OpenType fonts, not all application contexts provide access to a wide range of OpenType APIs. There doesn’t seem to be anything that SMuFL needs to say about SMuFL variable fonts, aside from possibly adding some new information to the font-specific metadata file.
Jeff Kellem confirmed that there isn’t much, if anything, that SMuFL needs to do in order to define variable music notation fonts. However, no music notation applications are currently using those features. If they do in the future, OpenType metadata is probably sufficient, SMuFL probably would not need to add new font-specific metadata, but might want to provide recommendations about particular features to use.
Philip Rothman asked about the possibility of doing something better for chord symbols. Chord symbols work more like music notation, but applications treat them more like text, picking and choosing from text and music fonts and combining them in ways that are unique to each application. Could SMuFL provide a spec for chord symbols, perhaps using OpenType features, that would let a font specify how to mix the text and musical symbols together so that chords would look the same in any application?
Daniel replied that this is a huge area, having helped implement two of the systems that Philip referenced. The level of guidelines for chord symbols would be much more complex than current SMuFL guidelines, in part because it really involves 2D kerning and scaling. Also, would applications use this, given that each application already has its own complex way to display chord symbols? Relying on OpenType features could also limit how many applications could use this. The attraction of the idea is clear, but the complexity seems daunting—an order of magnitude more sophisticated than SMuFL’s current registration guidelines. It is an interesting idea to ponder when looking beyond SMuFL 1.5.
Jeff replied that equation rendering for math fonts might provide a model for this of work. There are kerning tables specific to the math use.
Klaus Rettinghaus asked about whether to report an issue to SMuFL or to Bravura if you do not know where the issue actually is. Daniel answered that the rule of thumb is that visual problems with a particular Bravura symbol should be reported to Bravura, and pretty much anything else reported to SMuFL. Daniel follows both repositories and can transfer issues back and forth, so please don’t let that uncertainty keep you from reporting issues.
Michael asked about adding other languages to the translation project beyond the five languages currently there (French, German, Italian, Japanese, Spanish). If you sign up to the Transifex project, you can specify which language you want to translate. So request a new language and Daniel will be happy to set it up.
Instrument data update (1:00:18)
Daniel reviewed the idea, originally brought to the group by Daniel Ray of MuseScore, to build an open database of structured data about musical instruments for use in music notation software. When we updated the charter earlier this year, we added this project to the scope of the Community Group.
We did have conversations with a few people who were interested in this project, but have not yet actually gotten started. The likely starting point will be to collect a list of use cases, like we did with MNX. We will need someone to volunteer to lead this project in order to make progress. This person need not be a group co-chair. If you are interested, please contact the co-chairs.
We would like to make some progress on this project by the time of next year’s meeting.
MusicXML update (1:06:02)
Michael provided a brief MusicXML update. Since MusicXML 4.0’s release in June 2021, we have been collecting issues for future versions on GItHub. There are no current plans for working on a version 4.1. We would first like a critical mass of issues, and our current preference would be to have at least a complete MNX 1.0 draft before starting a new MusicXML version.
However, with Michael’s retirement, these plans are all subject to change based on our next topic: leadership changes and the search for a new MusicXML specification editor and group co-chair.
Leadership changes (1:07:55)
Daniel discussed the Community Group’s upcoming leadership change. Michael will be retiring on 6 January 2023 and stepping down as Community Group co-chair at that time. We are looking for someone to serve both as Community Group co-chair and MusicXML specification editor.
We have been in touch with a few people already, but we don’t want to overlook anyone who might be interested. If you would like to be considered, please contact the co-chairs by Friday, 23 September 2022. Daniel has been leading the communication process for the search, so please feel free to email him directly. We will then be arranging times for the three current co-chairs to meet with each candidate. We need to be moving on in order to have a new co-chair and specification editor in place by early January.
What does it mean to be a co-chair and specification editor? The co-chairs meet for an hour every two weeks to discuss the current specifications and any other group-related issues, such as our annual meetings. Feedback on the specifications that are not your primary responsibility is also encouraged, as we discuss these issues at our co-chair meetings, especially around MNX.
The specification editor is responsible for writing and producing the new version of the MusicXML specification. This includes managing the GitHub backlog and issue list and determining scope for future releases, and coordinating the work involved in producing the specification. For MusicXML it is particularly important for the specification editor to be able to test changes, so access to an implementation that you can change is beneficial.
Jim asked if it is important that the new MusicXML specification editor also be a co-chair. Daniel answered that we believe that it is, in order to have equal representation for each of our three major specifications. Also, being a spec editor is much more work that being a co-chair, so if you’re a spec editor you might as well be a co-chair.
Jim followed up on that given that MNX is becoming more important while MusicXML is more static. There could be a separate co-chair who is not a spec editor to provide three perspectives in the co-chair meetings. How much work would actually be involved as a MusicXML spec editor, and does that person need to be in the top tier of Community Group leadership?
Daniel replied that it’s likely there will be new MusicXML release with more features, but we don’t know when that would be or what it would look like. However, we cannot escape that MusicXML is implemented in over 250 applications that are used by hundred of thousands, if not millions, of musicians on a daily basis. So even maintaining MusicXML in terms of improving documentation and other tasks could take a decent amount of work.
Planning for in-person meetings (1:22:22)
Daniel discussed possibilities for in-person meetings. We haven’t had one since April 2019 at Musikmesse, but Musikmesse is now permanently cancelled. NAMM was much smaller in 2022 than in previous years, though held in June rather than the usual January dates. Possible options include:
TechChill, a startup-oriented conference in Riga held in February, suggested by Daniel Ray
The NAMM show in Anaheim, being held in April 2023 before reverting to January dates in 2024
TENOR, an academic conference tentatively planned for Boston in 2023
The Music Encoding Conference, being held in Paderborn in September 2023 as a joint meeting with TEI
Music Austria, perhaps the closest thing in Europe to Musikmesse, but held every two years so not until 2024
Another possibility is an organization’s offices, like Steinberg in Hamburg or IRCAM in Paris. But independent meetings outside of an event are tricky for getting permission or funding to travel unless you live nearby.
Daniel asked for people’s thoughts and suggestions on other possible events, and people’s opinions on in-person meetings in general.
Michael mentioned W3C TPAC in person as a possibility. It alternates between Asia, Europe, and the Americas, and also tends to have a higher registration fee than music events like Musikmesse and NAMM.
Christina Noel mentioned that NAMM would be easy for her to attend since Musicnotes regularly goes there. But she’s willing to show up in person whereever.
Jeff mentioned music librarian conferences or orchestrator conferences as a possibility. Daniel mentioned that for MOLA in particular, the technology industry is not really invited to that conference. Invitations tend to be one-off special guest appearances. Daniel wondered if other performing organizations might be possible, but groups like the Musicians Union don’t tend to have big shows any more.
Michael Cuthbert suggested a music notation meetup. Daniel mentioned that this provides a way around the standalone event issues with travel.
Daniel requested that if anyone has ideas for venues for in-person meetings, please let the co-chairs know.
Q&A (1:32:41)
Jeremy Sawruk asked about an event at ISMIR. Michael said he should have included it and overlooked it. This year it is in India, but 2023 has not been announced yet—it is typically announced at the previous year’s conference. It does move around a lot as an international conference.
Michael Cuthbert asked how W3C has been working as an umbrella organization. He has heard about the changes at W3C with MIT no longer being a hosting organization, and also ran into great problems trying to vote his approval for the MusicXML 4.0 specification.
Daniel answered yes, even though there is some wonkiness in voting and in joining / leaving the group. We get free infrastructure like the blog and GitHub account, as well as staff support. The biggest advantage could be the legal framework in place for developing these types of unencumbered, royalty-free standards.
Michael Good also answered yes, it’s been a fantastic home. It’s a better home than he expected, since he was concerned about the level of support at a free price level. But attending the CEO overview at TPAC this week showed the importance of Community Groups in terms of growing the W3C developer community, and making W3C the place where web standards happen. Community Groups get the W3C working on new things, often serving as feeders to W3C Recommendations. The number of developers associated with W3C has increased from 1,500 to 15,000 in the past 10 years. The importance of the community as an asset to W3C helps explain why we get better support than expected. He also thinks that W3C’s move from a consortium sponsored by four different organizations (including MIT) to a separate legal entity sounds like a good thing that will make W3C a stronger organization and thus be beneficial to us.
Adrian also answered yes, emphasizing the credibility that W3C provides to our work, especially for newcomers to the music notation world coming from a web developer background.
Jim mentioned that he would love to see seamless inter-conversion between MusicXML, MNX, and MEI, as well as a music notation diff tool to compare scores. Is there any obstacle to conducting that work under the auspices of the Community Group?
Adrian replied that his long-term vision for the mnxconverter is to support two-way conversions with multiple formats, including formats like MEI and abc. Tools like music diff are great things to experiment with in open-source implementations once MNX 1.0 is released. It’s not clear whether these would be produced in the Community Group or elsewhere, but is of great personal interest. We’re a ways away from that at this stage. Jeremy seconded Adrian’s point about general-purpose music notation tools, which is something he thinks could be developed within the context of MNX. Perhaps this could be a generalized plug-in interface, or music notation API.
Christina asked how far we think we actually are away from MNX V1. Adrian replied that it’s hard to say. Enharmonics and other score/part differences are the main remaining major piece, but then there are lots of details like articulations that need to be carried over. Finding time is an issue so more contributors, like Christina has been, are most welcome. Fortunately the list of big remaining architectural decisions has dwindled considerably in the past year or so.
Michael Cuthbert suggested that RomanText and other microformats might also be contributed to the Music Notation Community Group. We don’t have to necessarily work on things as big as MusicXML and MNX and SMuFL. Microformat spec editors probably don’t need to be co-chairs as the spec might be edited once every seven years or so when somebody finds a problem.
Meeting closed (1:52:22)
Michael Good concluded the meeting with information about how to join the Community Group and keep in touch with what is going on. He also thanked everyone for making the community such a great place for the continued maintenance and development of all these great music notation standard. He especially thanked Joe Berkovitz for his role in starting the Community Group. With his upcoming retirement, it feels really good to know that MusicXML and the other specs will have such capable leadership.
w3c/musicxml
