Musicxml

No discussion of music representation would be complete without mention of XML and the XML sub-languages devoted to music, most specifically MusicXML and MEI. Other extant systems are MPEG4 Structured Audio, which allows structured representation of audio signals, and MPEG7 Notation. My position is that XML-based languages are inappropriate for the generalized markup of musical metadata, because XML imposes a single fixed hierarchy on the data it marks up. In music, however, it is very easy to construct examples in which one requires multiple hierarchies, as outlined in section 4.3. This problem is not restricted to music, but there is evidence that the XML research community treats it as a problematic property of data, known as ‘overlapping’, rather than as a shortcoming of the representation language. For example, DeRose writes:

OSIS…, a standard schema for biblical and related materials, has to deal with extreme amounts of overlap. The simplest case involves book/chapter/verse and book/story/paragraph hierarchies that pervasively diverge; but many types of overlap are more complicated than this.
The basic options for dealing with overlap in the context of SGML or XML are described in the TEI guidelines. … Thus, I present a variation on TEI milestone markup that has several advantages. This is now the normative way of encoding non-hierarchical structures in OSIS documents.

The telling phrase, here, is at the end. In fact, the data described is not non-hierarchical, but multiply hierarchical (in other words, the structure is, formally, a graph, or maybe a semi-lattice, but not a tree). The use of the term ‘nonhierarchical’ here suggests that the author believes that only tree structures are actually hierarchical – an archetypal case of a hammer owner requiring everything to be a nail.

It is worth emphasizing that this does not mean that we cannot use XMLbased representations for multiply hierarchical

structures. We can easily do so Computer Representation of Music in the Research Environment 21 by using the XML component simply as a syntax checker for whatever it is we are representing; in some contexts, this may even be useful. Further, there are certainly musical contexts where fully multiple-hierarchical representation is not necessary. The important distinction is between merely using the syntax of XML (or other representation, for that matter) and using its inference capabilities. If we merely use the syntax, we gain few, if any, of the advantages of the system, but nevertheless import all the extra work and complication it implies, which then raises the question of why we bother to use it at all.
The upshot of XML’s restriction to trees is that the advantages of using the language can only be applied to a simplistic subset of musical markup, without adding non-uniform extra features (such as the ‘milestone markup’ mentioned above). This in turn draws the use of XML for music representation into question, because it becomes necessary either creatively to abuse existing features of the language (as above), which is undesirable, or to implement the mechanism properly to represent one’s data on top of XML, in which case one is needlessly (and therefore unacceptably) increasing the mechanistic overhead of one’s representation. Either of these approaches might be described as bad engineering.
Furthermore, XML is not really intended to be a knowledge representation language, but rather a data interchange format.