Re: Why GMNX is not necessarily SVG

Just to reiterate something I said earlier: I don't think this issue
changes the goals of GMNX, or what we call it. Saying that GMNX is SVG with
embedded data islands (instead of a notation encoding with some SVG inside
it) is just another approach, an architectural choice we can make.

.            .       .    .  . ...Joe

Joe Berkovitz
Founder
Noteflight LLC

49R Day Street
Somerville MA 02144
USA

"Bring music to life"
www.noteflight.com

On Thu, Apr 27, 2017 at 3:19 PM, Joe Berkovitz <joe@noteflight.com> wrote:

> 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
>
>