Re: The MusicXML Technical Requirements document

There is actually a more serious issue with XLink in SVG: it confers
interactive linking behavior on the element that possesses the link. Click
the element, and the agent displaying the graphics is supposed to navigate
to the given target.

In an interactive context for displaying the SVG, like a web browser, this
would probably be undesirable. One would not want to navigate to some
element in a target XML document encoding the music one was viewing, except
in the nerdiest of situations.

.            .       .    .  . ...Joe

Joe Berkovitz
President
Noteflight LLC

+1 978 314 6271

49R Day Street
Somerville MA 02144
USA

"Bring music to life"
www.noteflight.com

On Mon, Apr 4, 2016 at 6:29 PM, Joe Berkovitz <joe@noteflight.com> wrote:

> In Noteflight we also annotate all the SVG we render, so we can reliably
> trace back everything visual to the original data model. It works well.
>
> Xlink is one choice, but not the only one. If one did use XLink, one would
> want to also use XBase to cut back on verbiage. This way you can declare
> somewhere in the SVG element a base URL to which all these "traceability"
> pointers are relative:
>
> <svg ... xml:base="https://somewhere.com/myscore.xml/">
>   ...
>   <g xlink:href="#note123">...</g>
>   ...
> </svg>
>
> The only trouble with XLink is that it locks you into one notion of what
> links from SVG elements to some target mean: you can only have one
> xlink:href per element.
>
> I was suggesting using data- attributes, which can be tacked onto pretty
> much any node: you just name your attribute anything you want, so long as
> it begins with data-. They are not officially supported in SVG 1.1 but are
> proposed for SVG 2. This has the advantage that other types of outgoing
> links could be added as well as the one we're contemplating here. That
> would look like this:
>
> <svg ... data-music-base="https://somewhere.com/myscore.xml/">
>   ...
>   <g data-music-ref="#note123">...</g>
>   ...
> </svg>
>
>
> .            .       .    .  . ...Joe
>
> Joe Berkovitz
> President
> Noteflight LLC
>
> +1 978 314 6271
>
> 49R Day Street
> Somerville MA 02144
> USA
>
> "Bring music to life"
> www.noteflight.com
>
> On Mon, Apr 4, 2016 at 6:10 PM, Christopher Antila <christopher@antila.ca>
> wrote:
>
>> On 04/04/2016 05:54 PM, Joe Berkovitz wrote:
>>
>>> Actually I have one more response on the idea of SVG representing scores
>>> --
>>> a positive thought.
>>>
>>> I think there is value in standardizing some optional data in an SVG
>>> rendering of MusicXML that can point back to the elements in the original
>>> MusicXML document, a sort of "traceability". This way, there is always
>>> the
>>> option to understand what semantic musical data some given SVG element is
>>> derived from -- providing one has both documents in hand, and that the
>>> SVG
>>> was rendered in this conformant way.
>>>
>>> This is similar in some ways to the way the Verovio viewer renders MEI
>>> into
>>> SVG (see http://www.verovio.org/structure.xhtml). However, it might be
>>> nicer to use a data- attribute to refer back to the source document,
>>> rather
>>> than some ID naming convention like Verovio uses.
>>>
>>
>> This is a great idea, and from the looks of Wikipedia's article about the
>> XLink specification, SVG already supports the required attributes.
>>
>> https://en.wikipedia.org/wiki/XLink
>>
>> I've never thought about using XLink with MusicXML, but why not? This
>> type of solution seems useful in a wide variety of situations!
>>
>>
>> Christopher Antila
>> nCoda
>>
>>
>