Re: The MusicXML Technical Requirements document

Hi,

Being new to this CG, I have to admit that I'm a bit confused about how 
to use the various channels of communication on offer.
I've now read Joe's list-message (quoted below) more carefully:
> I look forward to discussion on the list as well as in person. 
and realise that my comments on the MusicXML Use Cases document
(https://www.w3.org/community/music-notation/wiki/Talk:MusicXML_Use_Cases)
should probably have come here. Sorry for the confusion.
Should I try to delete my reply and post a copy here?

Here are some thoughts on the *other* document: MusicXML Technical 
Requirements.
I think the sub-title
> Arbitrary apps working with notation
underspecifies the problem: 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.

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.

Note that its quite feasible to use a namespace to add custom temporal 
information to (graphic) SVG objects. This has nothing to do with SVG's 
animation capabilities (which are not needed in scores that have to be 
printable on paper). Such a namespace would also be part of any 
SVGMusicScore standard.

---
Suggestions:
The "Considerations" section of the "MusicXML Technical Requirements" 
document seems to apply mostly to web applications. I think this should 
be made explicit, and the document edited accordingly. Desktop 
applications are covered by MusicXML, but web apps are not.
Maybe rename this document to "Technical Requirements and Considerations 
for Web-based Applications"

all the best,
James
https://github.com/notator


Am 03.04.2016 um 20:35 schrieb Joe Berkovitz:
> Hello CG,
>
> In preparation for the discussion of use cases and other substantive 
> questions at this week's upcoming meeting in Frankfurt, I've 
> undertaken a major rewrite of this document:
>
> https://www.w3.org/community/music-notation/wiki/MusicXML_Use_Cases
>
> The main changes are as follows:
>
> - I have reworked all the use cases into short narratives or stories 
> describing specific user roles pursuing a musical goal.
>
> - I have rewritten the section on Document Content to propose a 
> starting point for thinking about what kinds of content that the 
> standard might handle going forward.
>
> - I have added a new section on Document Profiles to propose a 
> possible path for resolving the tension between faithful 
> representation of human documents and semantic completeness/consistency.
>
> - I have excised some of the quasi-use-cases in the former section on 
> Technical Requirements and turned them into bona fide stores.  The 
> remainder of that section is now located in a new Wiki page located here:
>
> https://www.w3.org/community/music-notation/wiki/MusicXML_Technical_Requirements
>
> I will be continuing to work on the above Technical Requirements 
> during the coming week and will let the CG know as this occurs.
>
> Finally, I should also take pains to point out that not everything in 
> these documents reflects a full concensus from the Chairs. There are 
> some viewpoints which are my own, and I've tried to label these as 
> "proposals"; my hope that these will be helpful in our making progress 
> together.
>
> Of course not all of us will be in Frankfurt, so I look forward to 
> discussion on the list as well as in person.
>
> Best,
>
> .            .       .    .  . ...Joe
>
> Joe Berkovitz
> President
> Noteflight LLC
>
> +1 978 314 6271
>
> 49R Day Street
> Somerville MA 02144
> USA
>
> "Bring music to life"
> www.noteflight.com <http://www.noteflight.com>