There are many fine computer music programs in the world. Unfortunately, sharing music between them used to be difficult. This was a real problem since no one program can do everything equally well. Having to reenter musical data for each program you want to use is a big inconvenience to everyone who uses more than one music software program.
Before MusicXML, the only music notation interchange format commonly supported was MIDI. MIDI is a wonderful format for performance applications like sequencers, but it is not so wonderful for other applications like music notation. MIDI does not know the difference between an F-sharp and a G-flat; it does not represent stem direction, beams, repeats, slurs, measures, and many other aspects of notation.
People had recognized for years that a new interchange format was needed, but no prior attempt at creating a new standard format had succeeded. NIFF had probably been the most successful attempt to date, but its use was very limited and the format was not being maintained. SMDL was the most ambitious attempt, but no software actually used it.
An Internet-friendly standard format is necessary for the growth of the Internet music publishing market. Before MusicXML, it was like using the Internet before HTML was invented, or using synthesizers before MIDI was invented.
NIFF and SMDL were noble efforts to solve the same type of interchange problem that MusicXML addresses. So why don’t we use them rather than inventing something new?
NIFF represents music using a graphical format. There is no concept of a “C” in NIFF: instead, you determine pitch by its placement on a staff. This type of graphical music representation has a long and distinguished history. It works well for the scanning programs that were the focus of NIFF’s work. But it works poorly for many other types of applications, such as sequencing and musical databases. For both of these applications, MIDI works much better than NIFF; for notation, though, NIFF is more complete than MIDI. MusicXML is designed to meet the interchange needs for all these types of applications.
A graphical format like NIFF really does not work well for general interchange, which is one of the main reasons NIFF has not been adopted by more programs. Another major impediment is that NIFF is a binary format, rather than a text format like XML. It is much easier to write and debug programs that read and write to a text format vs. a binary format.
SMDL suffered from the problem of trying to be a general-purpose solution to the problem of representing all possible musics of the past, present, and future. In addition, the project was not grounded in practical implementation experience. The result was something so complicated that practically nobody can understand it. The overwhelming complexity greatly inhibited SMDL’s adoption – it certainly inhibited us! – and no commercial software supports it.
MusicXML was based primarily on two academic music formats:
Eleanor Selfridge-Field from CCARH edited a magnificent book called Beyond MIDI: The Handbook of Musical Codes. Studying this volume made it clear that, as we had been advised, MuseData and Humdrum were the most comprehensive starting points for the type of language we wanted to build.
The first beta version of MusicXML was basically an XML updating of MuseData, with the addition of some key concepts from Humdrum. Since both formats have been used primarily for work in classical and folk music, MusicXML was extended beyond those boundaries to better support contemporary popular music. In recent releases, MusicXML’s capabilities have been greatly expanded so it can serve as a distribution format for digital sheet music as well as an interchange format. Many features have been added in order to make MusicXML near-lossless when it comes to capturing how music is formatted on the printed page.
XML was designed to solve exactly the type of problem we face today in music software. Say you have 100 music applications, each with its own format. For each application to communicate with the other, 10,000 separate programs would need to be written without a common interface language! With a common interface language, each application writes only one program, so only 100 separate programs would be required. Consumers gain enormous value at relatively small cost to the software developer.
XML builds on decades of experience with its predecessor SGML, as well as the experience with the explosive growth of HTML and the Web. XML hits the magic “sweet spot” between simplicity and power, just as HTML and MIDI have done in the past. It is designed to represent complex, structured data, and musical scores fit that description.
Using XML frees us from worrying about the basic syntax of the language, instead letting us worry about the semantics – what to represent, versus the syntax of how to represent it. Similarly, there is no need to write a low-level parser to read the language: XML parsers exist everywhere. Basing a music interchange language on XML lets music software, a relatively small community, leverage the investment in tools made by much larger markets such as electronic commerce.
Yes. MusicXML 3.1 is developed by the W3C Music Notation Community Group and licensed under the W3C Community Final Specification Agreement..
No. It is important for the MusicXML format itself to be free and open source. MakeMusic transferred responsibility for the MusicXML format to the W3C Music Notation Community Group to help ensure its continued success within the music industry.
MakeMusic does not see a similar advantage to making our own Finale MusicXML software open source. Our Sibelius plug-in is not open source, but we may decide to change that in the future. Many open source applications include MusicXML support.
Many companies, music software developers, and scholars are using MusicXML in their products and research. People use MusicXML with many different types of notation software, such as:
See our MusicXML software page for a more complete list, including links to each application.
One of the great things about basing our work on XML is that there are tools available for practically every computer platform.
At Recordare, we used Microsoft tools for our first generation of Dolet software. The original Dolet for Finale plug-in was written in a mix of Visual Basic 6.0 and Visual C++ 6.0, using Microsoft’s MSXML parser. The Microsoft parser was designed to be easy to use within Visual Basic and succeeded admirably. We had great success with it.
If all you want to do is write MusicXML files, not read them, you really don’t need a parser, though you may find it useful. A scanner like SharpEye Music Reader, for instance, does not have any great need to read MusicXML files. Its MusicXML support is written in C, like the rest of the program, without using any special XML tools. The pae2xml translator is written in Perl. The Dolet 6 for Sibelius plug-in is written in ManuScript. You can also use XSLT to read and transform MusicXML files.
There are many XML sites that can guide you to XML tools beyond what we list here. If you are using an XML parser, in most cases you will probably be using the XML DOM (Document Object Model) to handle MusicXML files. Good DOM support is likely to be more important than SAX support for MusicXML programs.
Many tools today will automatically generate classes from an XSD schema definition. MusicXML’s schema has some complexity that can require manual edits of the automated output, but many developers find these tools to save a lot of time in their MusicXML development.
When we started developing MusicXML, a DTD (Document Type Definition) was the only official W3C recommendation for defining an XML document. Since that time, XSD (XML Schema Definition) has become an official W3C recommendation, and alternative standards like RELAX NG have also become available.
When XSDs were first released, neither the supporting XSD software nor the state of MusicXML application usage was sufficiently advanced to take advantage of this technology. XSDs are more complex than DTDs, so it was clear there would be a cost to creating a MusicXML XSD schema. At the time it was also not clear how support would evolve for XSD, RELAX NG, and other schema alternatives. It thus made sense to stay with DTDs for the releases of MusicXML 1.0 and 1.1.
XSD and MusicXML technology have both matured significantly in the past few years. Developer tool support for XSDs is now as pervasive as for DTDs. New XML tools such as XQuery and XML data binding tools can work much better with XSDs than DTDs. While RELAX NG has some advantages over XSDs, its software support is not yet as pervasive as for XSDs.
In addition, MusicXML’s move from an interchange to a distribution format makes it increasingly important to provide the most powerful tools possible for automated quality assurance. Validating against an XSD can catch many more errors in XML document creation than validating against a DTD.
These combined customer needs and opportunities regarding XSDs led us to develop a MusicXML 2.0 XSD that was released in September 2008. The XSD puts much more of MusicXML’s semantics into the language definition itself, rather than just in the documentation. Thus there are many documents that validate against the DTD that do not validate against the XSD, but these reflect MusicXML file errors that you do want to catch as early and automatically as possible.
DTDs remain more readable than XSDs for many people. To learn MusicXML, you may find it easiest to read the DTDs, the XSDs, or both in combination. This will depend on your experience and comfort level with the different technologies. The XSDs will generally offer more precise definitions than the DTDs since the format is now much more strongly typed.
This is mainly a stylistic decision. Several XML books advise representing semantics in elements rather than attributes where possible. One advantage of doing this is that elements have structure, but attributes do not. If you find that what you are representing really has more than one part, you can create a hierarchical structure with an element. With attributes, you are limited to an unordered list. For information retrieval applications, it can also be easier to search directly for elements rather than for attribute/element combinations.
In MusicXML, attributes are generally limited to a few uses:
In both MusicXML 1.1 and 2.0, the third category – suggesting how an element would best be printed – grew enormously. So you will find that MusicXML 3.1 files make much more use of attributes than do MusicXML 1.0 files. The principles determining when to use elements and when to use attributes have remained the same.
In summary, we follow common recommended practice by using elements for data and attributes for metadata. We find this works well. Certainly there are DTDs and XSDs in other domains that use attributes much more extensively, and they work well too. Either way can do the job as long as it is applied consistently.
While there are a lot of MusicXML elements, we have tried to limit them to elements that directly represent musical concepts. We have tried to avoid using elements that would introduce concepts not found in musical scores. For example, there is no “timeslice” element as found in formats like NIFF. We have generally found that we can represent what applications need without having to introduce artificial elements.
MusicXML is both an interchange and distribution format. In both cases, ease of comprehension is much more important than terseness. Musical representation is complex enough without trying to figure out an abbreviated code. The XML specification advises that “terseness in XML markup is of minimal importance”, and we believe this is really true. Somebody who understands the domain should be able to figure out the basics of an XML file simply by reading it. We believe that MusicXML meets this goal, where several other musical XML proposals do not.
There is of course a place for terse text formats like abc or Plaine and Easie, which allow easy and fast text entry of musical data. There are converters for both abc and the Plaine and Easie codes to MusicXML.
Uncompressed MusicXML files do take up a lot of space, which can be problematic for digital sheet music distribution. MusicXML 2.0 added a compressed zip format with a .mxl suffix that can make files roughly 20 times smaller than their uncompressed version. As an example, a four-page Joplin rag takes up 518K as an uncompressed .musicxml file, but only 19K as a compressed .mxl file. This is even smaller than the MIDI representation, which is 21K, and the MXL file contains much more data about the music.
In order to see a MusicXML file as music within a browser, you need to use a web application that can understand, display, and playback MusicXML files. In the past these applications often used Flash, but nowadays they usually use HTML5.
MusicXML 3.1 has two registered media types:
Perhaps in the future, browsers will be able to automatically respond to these media types so that files outside of web pages will be displayed and played back automatically.
It would be possible to build an XSLT stylesheet to convert MusicXML into a web-readable format, and a proof of concept for this was done by one MusicXML user. However, building a professional quality XSLT for music notation would be a difficult task.