Why GMNX is not necessarily SVG

I would like to address the idea that GMNX could perhaps just be SVG, with
special embedded elements in a specific, non-SVG namespace supplying music
notation data. (This XML pattern is sometimes referred to as "data islands")

The apparent win here is that browsers and other standard SVG viewing would
just render the SVG, ignoring the notation-specific data embedded within.
This seems to be one of the motivations behind James's suggestion of
encoding everything in a specialized dialect of SVG (SVGMN).

The idea is certainly up for discussion -- and folks (including James) are
free to file an issue to this effect -- but I'd like to explain up front
why I have avoided it. The main problems I see are as follows:

- This approach ignores the fact that multiple different performance
interpretations are often associated with a single graphical symbol or
region. For example, consider a simple repeated passage which is played one
octave lower on the second repetition.  Or a puzzle canon, in which the
same notes may yield different events at different times, due to the
delayed entry of the voices. In such cases, scattering the performance data
according to the SVG structure, if possible at all, results in performance
data that is fragmented and difficult to interpret.

- This approach forces all music performance data to be nested inside some
specific SVG element. This is a needless restriction on the relationship
between performance and graphics. It's entirely possible that the
performance of a notated piece could require the performer to integrate
information from different graphical regions of the score (e.g. reading a
poem from one area, and looking at a succession of color swatches in
another). In these cases, there's no logical place to put the performance
data (and it might as well go in the root of the document).

- Putting SVG inside a music notation format "lets SVG be SVG", and allows
exactly the same expressivity, but much more flexibility. It's just a
matter of using element IDs to connect the information.

Best,

.            .       .    .  . ...Joe