Re: The MusicXML Technical Requirements document

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