MusicXML is a format for representing common Western music notation from the seventeenth century onwards (Good, 2001a). It is based on the Extensible Markup Language (XML). MusicXML can represent both classical and popular music. It is intended to be extensible to coverage of the requirements of early music and to less-standard notation needs of twentieth and twenty-first century scores. MusicXML was designed in response to the opportunities posed by Internet music publishing.
When Recordare, the developer of MusicXML, was started in 2000, digital sheet-music was available for sale, but supported uses were limited to transposition, printing, and using it with proprietary music players, such as Sunhawk’s Solero system. These uses did not compare well to the flexibility of digital audio available in CD or MP3 formats, nor to the availability of websites in HTML format. At this writing (November 2005) proprietary formats (e.g., from MusicNotes, Sibelius, and Sunhawk) still dominate the market. They are coupled with more restrictive digital rights management than is found for audio files at sites like Apple’s iTunes Music Store.
Unsurprisingly, digital sheet-music currently has a smaller share of the print music market than digital downloads have of the audio market. The need for a well-accepted symbolic music interchange format more competent than MIDI has long been recognized. Prior attempts to create an interchange protocol include the NIFF and SMDL formats described (along with many others) in Beyond MIDI (Selfridge-Field, 1997). None of these previous efforts was widely adopted.
To circumvent the problems of past interchange formats, the design of MusicXML followed two main strategies. First, the design of MusicXML was based on two of the most powerful academic music formats for music notation: MuseData (Hewlett, 1997) and the Humdrum **kern format (Huron, 1997). Both formats have large music repertoires available and have been used for diverse music applications. A format that incorporates and grows beyond these successes would have a solid technical grounding.
Additionally, the MusicXML definition was developed iteratively with MusicXML software. The initial prototype software did two-way conversions to MuseData, read from NIFF files, and wrote to Standard MIDI Files (Format 1). Handling these three very different formats demonstrated that MusicXML’s basic interchange capabilities were solid. We then moved on to support interchange with MakeMusic’s Finale program.
Figure 1.1 shows “before” and “after” views of a Bach fugue translated from the MuseData Stage 2 format (http://www.ccarh.org/publications/books/beyondmidionline/musedata) to display in Finale. More than one thousand encoded works of the classical repertory (2005) are available at http://musedata.ccarh.org. Most can be imported into Finale and Sibelius versions through 2005 via MusicXML. More than 800 additional works in the Humdrum format are available at Craig Stuart Sapp’s KernScores website http://kern.ccarh.org/ (Sapp 2005).
Iterative design and evolutionary delivery techniques have been used since the 1980s to produce more usable and useful computer systems (Gilb, 1988; Good, 1988; Gould and Lewis, 1985). With MusicXML, we have found that these techniques can also be successful in XML language design. Limited support for MusicXML 1.0 for music formatting was deemed to be the single greatest barrier to its use in Internet music publishing applications. In MusicXML 1.1 (May 2005) we added 70 new features to the MusicXML 1.0 language, most of which were focused on music notation formatting. The 1.1 additions and changes were carefully designed for upward compatibility, so that all MusicXML 1.0 files were also valid MusicXML 1.1 files. MusicXML 1.1 was soon adopted by major notation editing, scanning, and digital sheet-music sales applications.