Re: Music Notation on the Web - Last Call?

Hi Roger,

You're not as alone as you think you are. However, it may take a bit  
longer to solve the problem than one might hope for. I am not urging  
you, or anyone, to give up. I am just suggesting a bit of patience in  
light of the rough terrain.

I'm not a "MusicXML guy" so much as a guy who has worked a great deal  
with notation software, has built a notation editor, and who  
recognizes the inherent trickiness of the territory. MusicXML,  
whatever its syntactic complexity, does address a lot of the right  
issues to deal with this trickiness, and has more industry uptake than  
anything else. That doesn't make it impossible to improve. It just  
means that the requirements that it has had to address, in order to  
achieve its current status, should not be ignored. Conversely, the  
failures of the past should be examined and learned from also. Another  
failed music standard would be a bad thing.

The RDF/Turtle analogy is interesting. Could MusicXML's syntactic  
complexity or verbosity be reduced in some potential future format,  
while still addressing a meaningful core of notation semantics? Yes, I  
am sure that it could (and I have also tangled with RDF, so I  
appreciate the comparison)!  But... can it be done straightforwardly,  
taking the industry forward along with it, and executed in the scope  
of the current concerns of the group?  I urge caution.  Please excuse  
the oversimplification, but RDF is basically about graphs of triples.   
MusicXML -- and any other hypothetical standard that seeks to be  
useful -- is going to be about a set of much more complicated  
constructs and relationships with overlapping and conflicting  
interpretations in the musical world. Making it compressed and  
readable is only going to be a small part of the battle.

Finally, as was previously observed, CPDL's contents is not a real  
metric of the success or failure of MusicXML today. Some sites offer  
exhaustive access to MusicXML. Some do not.  What you see on CPDL is  
really a measure of the immaturity of the entire notation ecosystem  
(sites, vendors, standards) with respect to semantic notation data.

...Joe

On Dec 14, 2010, at 3:04 PM, Cutler, Roger (RogerCutler) wrote:

> I must confess that I'm about to give up on this -- basically  
> because I seem to be out there completely alone.  I have a pretty  
> strong feeling that something really needs to be done, but I don't  
> seem to be striking a lot of chords with people.  An analogy that  
> occurs to me:  The W3C people had a tendency to think that the XML  
> representation of RDF solved all problems -- except in practice just  
> about nobody actually used it, or perhaps only used it as a last  
> resort.  Now they have finally figured out that recognizing and  
> standardizing Turtle (which is much more compressed, readable and  
> easy to write for simple tasks) is a REALLY good idea.  You MusicXML  
> guys seem to be saying that MusicXML can do anything anybody wants  
> -- but for some reason it really doesn't seem to have much uptake.   
> For example, you note that there are 94 MusicXML scores in CPDL.   
> Well, there are links to 84 ABC scores.  Neither number is very  
> impressive and they are all external links -- CPDL does not  
> "natively" offer either.
>
> If there are people lurking out there who would like to see  
> something happen here it would be nice to hear from you.
>
> -----Original Message-----
> From: public-xg-audio-request@w3.org [mailto:public-xg-audio-request@w3.org 
> ] On Behalf Of Dan Brickley
> Sent: Tuesday, December 14, 2010 11:44 AM
> To: Michael Good
> Cc: public-xg-audio@w3.org
> Subject: Re: Music Notation on the Web
>
> On Tue, Dec 14, 2010 at 6:27 PM, Michael Good <musicxml@gmail.com>  
> wrote:
>> Hi Joe,
>>
>> You may well be right about this, but they are perceived issues  
>> even if not
>> real issues. I think it's best to be able to go to site owners and  
>> say
>> "we've fixed your problem" rather than saying "that's not really a  
>> problem."
>> Sometimes just the aesthetics of space inefficiency are enough to  
>> make it a
>> problem.
>>
>> The compressed file format offers many other advantages anyway. This
>> includes keeping linked/included images together with scores in a  
>> single
>> file, and offering a dedicated .mxl suffix rather than a generic .xml
>> suffix. The tradeoff is that it's a binary file rather than a text  
>> file,
>> albeit a very well-understood, standardized binary format (vanilla,
>> Java-compatible zip files).
>
> For what it's worth, this was the design also taken by the W3C Widgets
> group, see Widget packaging spec, http://www.w3.org/TR/widgets/
>
> I think they had some headaches figuring out how exactly to cite Zip
> from a formal W3C spec, but http://www.w3.org/TR/widgets/#zip-archive
> is the current text.
>
> More than a few ebooks formats do the same I'm sure,
> http://en.wikipedia.org/wiki/Comparison_of_e-book_formats ...
>
> cheers,
>
> Dan
>
>

... .  .    .       Joe

Joe Berkovitz
President
Noteflight LLC
84 Hamilton St, Cambridge, MA 02139
phone: +1 978 314 6271
www.noteflight.com