Re: Getting Off The Ground

On 9/17/2015 6:13 PM, Antila, Christopher wrote:
> Dear Co-Chairs and Community:
>
> Thank you for your welcoming and exciting introduction! Please find 
> our comments below.

Indeed.  Mine too. I've kept the nCoda folks' comments that I want to 
elaborate on, but in general I agree with the philosophy behind all they 
said, and just want to elaborate on one aspect.

> - Are these the right major goals? What’s missing? What should go?
>
> Regarding MusicXML-related goals:
>
> As the name of the group is the “Music Notation Community Group,” not 
> the “MusicXML Community group,” we should question together whether 
> MusicXML is the most appropriate foundation for a web-friendly 
> standard for music notation.
>
> We acknowledge the influence and benefits that MusicXML has brought to 
> the music notation community as a common language shared between 
> applications. Furthermore, we endorse the format’s continued 
> development, and we are very pleased to see it taking place in an open 
> and transparent way. We question, however, whether or not MusicXML is 
> the right basis for a web-friendly music notation standard.
>
> Given the diversity of music documents and their applications -- for 
> composition, online critical editions, arrangement, music pedagogy, 
> etc. -- we find that MusicXML falls short in several fundamental ways:
>
> 1.) MusicXML is tied to the MIDI standard in a historically accidental 
> and cumbersome way, meaning such basic characteristics as duration are 
> difficult for beginners to understand.
> 2.) MusicXML assumes a unitary rather than manifold model of a musical 
> work, which makes basic online functionalities such as version control 
> and collaboration cumbersome or impossible. Such a unitary model also 
> prohibits creation of online scholarly editions that correlate 
> multiple sketched versions of the same musical ideas or passages.
> 3.) MusicXML was designed as an interchange format between music 
> applications and, by design, does not encode all document information 
> required by a fully-featured music notation system. The goal of the 
> group, as we understand it, is to choose an online representation 
> standard for music documents.
> 4.) MusicXML is restricted to musical documents expressed as common 
> music notation, or a small set of alternatives. This limits the 
> format’s capabilities for new notation styles, for non-Western styles, 
> and for unconventional uses.
>
> Considering the aforementioned disadvantages, we note the following 
> characteristics of the Music Encoding Initiative’s XML-based encoding 
> format (MEI):
>
> 1.) MEI provides a comprehensive and consistent model of musical 
> notation, unencumbered by legacy applications and MIDI compatibility.
> 2.) MEI is suitable for scholarly applications, as it provides 
> explicit facilities for addressing the manifold nature of musical 
> works, allowing for all manner of variants and alternatives.
> 3.) MEI is developed by an existing community with years of experience.
> 4.) MEI was developed as an extensible format from the start, and 
> community members are actively working on extensions for niche 
> communities that would be nearly impossible to incorporate in MusicXML 
> (neumatic and mensural notation are already standardized). New and 
> alternative types of musical documents and encodings could be 
> incorporated over time, much as HTML5 is gradually being amended.
> 5.) MEI has also been used to encode characteristics of musical 
> documents, musical metadata, for use in specialist databases and 
> libraries. In this way, MEI provides not only a means of encoding 
> notation, but of all musical data, no matter the culture or medium of 
> initial creation.
> 6.) MEI has been developed as a free and open standard from the start.
>
> We recognize that MEI is not a ready-to-go, ideal solution for all 
> web-based music notation needs. In particular, MEI does not currently 
> support a stylesheet-like separation between “content” and 
> “appearance,” which is one of the most important lessons to be learned 
> from HTML and CSS. In spite of this, it is our strong conviction that 
> MEI is a more suitable base upon which to develop such a web-friendly 
> format. 

I looked at MusicXML once, maybe too long ago, and found it deficient in 
many respects, although I doubt I made a list at the time. nCoda's list 
will do for now. I've never examined MEI.

It would be interesting to have someone's opinions of the strengths of 
MusicXML and the deficiencies of MEI, which have not not been listed by 
nCoda. Perhaps such comparison and contrast would allow the conceptual 
benefits of both schemes (and maybe others) to be leveraged into a 
standard that would be better than either. If that route is taken, it 
would be good to clearly document the migration of each to the new, and 
where the limitations of each exist. It should be up to conversion 
utilities to compensate (automatically where possible, or with user 
input where necessary) for the deficiencies in older formats, rather 
than have "options" or "defaults" in the new standard to "guess" at what 
is missing. Make the new standard crisp and clean.

Above, "we should question together whether MusicXML is the most 
appropriate foundation for a web-friendly standard for music notation."  
And the alternative discussed, MEI, is another variety of XML.  XML is a 
precise form of expression, and it is somewhat human readable, which are 
both useful characteristics. However, it seems unlikely from what has 
been said that either form of XML will be directly displayable by web 
browsers, as is, say HTML (which is not quite XML), or SVG.

Yes, there was an XHTML, but it had limited uptake, and my impression of 
the reason why is that there are significant number of HTML coders that 
code HTML by hand, and the extra wordiness of XHTML to make it conform 
to XML killed it off... HTML 5.0 is not, if I understand correctly, 
quite XML compliant.

SVG, in spite of being cross-browser and I think XML compliant, last I 
checked there are a number of corner cases where what gets displayed 
from one browser to the next is quite different... but the semantic 
content is lines, curves, and characters, not notes, staffs, clefs, and 
other music notation. So representing a "chord" in SVG involves breaking 
down the music notation into a variety of lines, curves, and characters, 
so that is not directly useful for representing semantics of music.

I've heard of XSLT, but I'm not familiar with it except that at a 
conceptual level, it transforms XML based syntax into "other stuff". One 
question that comes to my mind is if XSLT can be used to transform the 
"web-friendly standard for music notation" to SVG, and if that should be 
a requirement for the "web-friendly standard for music notation".

If XSLT cannot perform such a transformation, then I wonder if an 
XML-based notation is the most web-friendly format for this purpose? If 
Javascript must be involved to transform "web-friendly standard for 
music notation" to HTML/CSS/SVG, then perhaps a notation based on JSON 
would be more web-friendly than a notation based on XML. Or, there are 
various mechanisms to translate between JSON and XML, although I haven't 
explored their limits. JSON tends to be slightly less wordy than XML, 
simply because it uses quoted strings to delimit content: rather than 
XML's <keyword>value</keyword> (which causes the values to get lost 
among the keywords), JSON uses keyword="value", which saves both storage 
size and computer and mental effort when parsing/reading.

> We’re pleased that our group’s co-chairs solicited the input of the 
> entire group on these matters. Furthermore, we’re excited to work with 
> the community in the future, regardless of the path forward chosen as 
> a result of our conversation together.
Me too.
Glenn