Abstract
Around 2000, many people realized that XML technology could be a great way to finally create a successful interchange format for music notation and digital sheet music applications. In the past, adoption of music notation interchange formats had suffered from both technical and social problems. Previous efforts like SMDL and NIFF never met their goals of becoming a standard music notation interchange format, even with the ISO 10743 seal of approval for SMDL.
The major technical problem was to design a format that was complete enough for both commercial and academic use, while usable enough to be approachable for developers. The major social problem was how to get the format adopted by the market leaders in music notation editing, both of whom were inclined to keep to their proprietary formats. MusicXML overcame these technical and social problems to become the first successful interchange standard designed for music notation applications. As of December 2006, MusicXML works with over 60 music applications, including all the market leaders for music notation editing and scanning. None of the other XML formats for music notation interchange have been adopted by applications outside of their own organizations.
Other application areas have similar adoption challenges, especially where market leaders might view a standard XML format as weakening a proprietary hold on customers. Examining how MusicXML overcame these technical and social barriers to become the de facto interchange standard for digital sheet music applications reveals some lessons that can be applied to other XML-based interchange formats:
- Apply usability techniques to language design in the same way that you would to GUI design. Use terms that domain experts understand. Where possible, avoid introducing concepts that are specific to applications in the domain, rather than to the domain itself.
- Develop the format together with software that reads and writes the format. Use evolutionary delivery to deliver early versions of both the format and the software, with frequent iterations to get both working well together. This particularly helps for meeting the twin goals of completeness and usability.
- Make sure that the format can exchange data in both directions with at least one market leader in your application area. Do this as early as possible in your development process. Do not expect the market leaders to do this for you.
- Market to other developers who would get a business benefit from using your format. This will be difficult until your format can exchange data with a market leader.
- Give format developers good support. Involve the development community in the design of the format. Be responsive to developers who are using early versions of your format and translation software.
- Avoid overhead. In a small market like music notation software, organizations like ISO and OASIS can be too costly in both time and money for even the largest industry players. Following the model of Adobe’s PDF format – an open format under single company control – can be more effective in these situations.
