Re: The MusicXML Technical Requirements document

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.

.            .       .    .  . ...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 3:41 PM, Joe Berkovitz <joe@noteflight.com> wrote:

> Hi James,
>
> Thanks for posting here -- I will put some kind of notice in the "Talk"
> sections to avoid this kind of confusion in the future.
>
> The Technical Requirements have simply been moved from their old location
> and are actively being revised. I completely agree that the original
> content labeled "Arbitrary apps working with notation" was not very useful
> or well conceived. It's already been partly reworked by transforming it
> into more specific user stories (now labeled as WEB1-WEB6 on the Use Cases
> page).
>
> The upcoming changes to the Technical Requirements will take a broader and
> more careful approach to connecting with all the user stories, not just the
> app/web/ePub related ones. I will be presenting some proposals of this sort
> in the timeframe of the meeting later this week.
>
> Let me respond to a few other points in your email.
>
> We can/should distinguish between web and off-line (i.e. desktop)
>> applications.
>> Developers have to decide which kind of app they are developing, and then
>> choose the appropriate tools (languages and technologies). Its a very good
>> idea for offline (desktop) applications to support MusicXML, but
>> Javascript+SVG is the name of the game on the web. Browsers are never going
>> to support MusicXML natively, but SVG already displays correctly "out of
>> the box".  An important distinction between these two types of application
>> is that desktop applications have to be installed, while web apps dont.
>> Also, web apps are (currently) always open-source -- which affects the
>> (financial) context in which they are written.
>>
>
> I agree that we should distinguish these cases. However I believe that the
> offline/online distinction does not really dictate a choice of which
> standards to use in which environments.
>
> MusicXML (or something like it) aims to be a standard that encodes
> notation, not an image of what notation looks like -- I'm sure we agree on
> that. That in itself tells us when to use it, vs. when to use SVG. The fact
> that browsers are not going to support it natively, doesn't affect
> MusicXML's relevance to the Web, or make it a "native-oriented" technology.
>
> For example, MathML is a W3C standard and a web technology for math
> formula markup, but it is generally not supported by browsers (and probably
> won't be): you need Javascript to render it. But it's been widely adopted
> to show math formulas in web pages, across the board. MusicXML is a lot
> like MathML: it can be used in any web browser, given an appropriate
> software library that can translate it on the fly into a browser-supported
> format.
>
> Web apps are not always open source, either. While I believe it highly
> likely that _libraries_ displaying MusicXML will be open source (both on
> and off the Web), this will shift financial value to the websites and
> applications that use these libraries. Much as open-source display of
> HTML/CSS shifted value away from browsers, and moved it to websites (and,
> yes, native applications!) that exploit these standards to deliver useful
> content or functionality.
>
> Conversely, many technologies originally designed for the Web are now
> considered best-in-class solutions in native environments (including SVG).
>
> So in the end, while this offline/online difference is instructive, I
> don't see that it affects our mission here. I think we're going to use lots
> of ideas from the Web, but not weld ourselves into the browser environment.
>
>
>> Most MusicXML editors already export SVG graphics, so I think this CG
>> should build on that, and define some standard way of describing music
>> scores in SVG. An SVGMusicScore standard could be much simpler than
>> MusicXML since it would not have to provide any comparable semantic
>> flexibility. The graphics (and associated temporal info) could be *created*
>> by an off-line application, and *run* using Javascript in the browser.
>>
>> If such an SVGMusicScore standard existed, developers could learn it and
>> use their accumulating knowledge to develop different, interoperable
>> applications. Over the past few years, we've learned that its very
>> important for the software industry to program to such open standards.
>>
>
> If you want to move away from semantic representation, then your approach
> makes perfect sense. SVG is a great graphical standard. But while SVG can
> be annotated with some semantic information, that doesn't make it easy to
> work with if you are concerned with the semantics. Imagine transposing an
> SVG score into a different key, or programmatically generating a melody.
> These are real use cases that do not need any graphical information, and
> where it's either irrelevant or it gets in the way.
>
> I suppose that I believe semantic representation of music is at the core
> of what this group, and MusicXML, is all about.
>
> ...Joe
>

Received on Monday, 4 April 2016 21:54:56 UTC