Following the example of many zip-based XML formats, MusicXML has a strictly defined way to determine where the root MusicXML file is within an archive. Each MusicXML zip archive has a file located at META-INF/container.xml. This container describes the starting point for the MusicXML version of the file, as well as alternate renditions such as PDF and audio versions of the musical score.
The container.xml file is defined by the container.dtd file. Given the simplicity of the format, there is no corresponding .xsd file at this time. As an example, let us look at the Dichterliebe01.mxl file available on the MakeMusic web site. Here is its META-INF/container.xml file:
<?xml version="1.0" encoding="UTF-8"> <container> <rootfiles> <rootfile full-path="Dichterliebe01.xml" media-type="application/vnd.recordare.musicxml+xml"/> </rootfiles> </container>
The container element is the document element for this file. It contains a single rootfiles element. The rootfiles element in turn contains one or more rootfile elements. The MusicXML root must be described in the first rootfile element. The full-path attribute provides the path relative to the root folder of the zip file. A MusicXML file used as a rootfile may have score-partwise, score-timewise, or opus as its document element.
Additional rootfile elements can describe alternate versions such as PDF and audio files. Multiple rootfile elements can be distinguished by each one having a different media-type attribute value. For instance, if the Dichterliebe01.mxl file contained a PDF rendition as well as the MusicXML file, the container.xml file would look like this:
<?xml version="1.0" encoding="UTF-8"> <container> <rootfiles> <rootfile full-path="Dichterliebe01.xml" media-type="application/vnd.recordare.musicxml+xml"/> <rootfile full-path="Dichterliebe01.pdf" media-type="application/pdf"/> </rootfiles> </container>
If no media-type value is present, a MusicXML file is assumed. However, if multiple rootfiles are present, it will probably make things more clear to include the media-type attribute for all rootfile elements.
The zip archive can also include images that are referenced with the MusicXML image and credit-image elements, or other media that are referenced using the MusicXML link element. MusicXML 3.1 does not specify where these files need to be located in the zip file, but it is probably least confusing if images or other files of a similar type are grouped together in a subfolder within the zip archive.
The first file in the zip container should be a file named mimetype. The contents of this file should be the MIME media type string
The mimetype file should be encoded in US-ASCII and must not be compressed or encrypted, and there must not be an extra field in its zip header. The contents of the mimetype file must not contain any laeding padding or white space, and must not begin with a byte order mark.
The mimetype file helps applications identify a compressed MusicXML file by reading the first few bytes of the file. EPUB and other zip-based formats also use a mimetype file for the same reason. Older versions of MusicXML before version 3.1 did not specify this mimetype file, so applications may still see containers without it.