Hierarchies are as fundamental to XML syntax as they are to musical notation. These are examples of notational concepts to which the organizational concept of hierarchies seems to have an obvious application:
There are sometimes reasons not to express all of these relations as hierarchies.
Hierarchies can be viewed from top to bottom or bottom to top. For example, we could replace the chord-contains-notes hierarchy with a sequence of notes with a common chord attribute:
<note chord= "chord1" ... /> <note chord= "chord1" ... /> <note chord= "chord2" ... /> <note chord= "chord2" ... />
Here it is indicated that the first two notes belong together because they share a common value (“chord1l”). This way of grouping is seen in several binary and XML-based formats. While it is usual for such groups to share common values, there is no single place where they can be stored.
It is generally preferable to store data in one single, well-defined place. Storing data with a common function in different places is costly and error-prone.
To almost every rule in music notation there is an exception (e.g. beams can cross bar lines, melodic lines can cross staves, line-breaks can occur in the middle of measures, and so forth). Such occurrences make the use of hierarchies inadvisable. XML provides accommodation for hierarchical exceptions through links.
How do we represent objects (such as beams) which contain other objects and various parameters determined by the other objects when we cannot employ hierarchies analogous to the “measure-contains-notes” one? If we grouped the notes with the common value procedure, we would have no single place to store such information as the gradient of the beam. One solution offered by XML is to make the beam an element with a unique identifier (id), e.g.
<beam id= "beam1" .../>
XML provides a mechanism that assures that this identifier occurs only once in a document. Then we use notes as follows:
<note beamRef= "beaml" .../>