Re: Getting Off The Ground

Full disclosure: I'm on the MEI Technical Team.


>> 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.

MEI takes a comprehensive view of music notation -- that is to say, we're building a platform to represent music from all periods. While that *may* be a tick in the 'plus' box, it also means that it comes with a not insignificant learning curve. It's also a smaller community with limited existing software support (although we're trying to work on that one!) 

> 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.

While MEI uses XML to encode music, I like to think that there is a design behind it (and also MusicXML) that represents 'music' in the abstract, and simply uses XML as a convenient vehicle for it. The advantages of XML are that you get a lot of things 'for free,' including validation, schema tools, and iron-clad software parsers in almost every language. Yes, it can be cumbersome but it also can be quite powerful if used correctly.

Thus a well-designed music schema should define the rules of how to encode music, and the expression of those rules may then take whatever form is convenient.

> 
> 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".  

You may be interested in a project out of RISM Switzerland, Verovio:

http://www.verovio.org/index.xhtml

The idea behind it is that you can give it an MEI-encoded notation file, and it will render SVG in the browser. It's written in C++ but compiled to a JavaScript library with emscripten, so there are no server-side rendering components. Of particular note is the fact that it preserves much of the hierarchy of the music notation in the SVG rendering, reflecting the structure of the music in the SVG encoding. This becomes very powerful since it preserves the hierarchical relationship between, e.g., a rendered measure and the rendered notes inside the measure. 

It's because of this that we're also (in the MEI community) actively pursuing a stylesheet spec for music notation engravers.

Another project that has been looking at rendering MEI notation with SVG for early music is the Mono:di project. They've adopted a pure XSLT approach:

https://monodi.corpus-monodicum.de

> 
> 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.

I have experimented (successfully) with round-tripping MEI XML to JSON and back to XML, so there is no reason why this is not possible -- a hierarchical markup language is a hierarchical markup language. There's also no reason it could not go to YAML or any other representation. The simplicity of JSON is somewhat deceptive, though. To get the same functionality as XML you need special treatment of attributes, text, and nested tags which are concepts that are not in many "markup" languages. So, an XML snippet like:

<foo bar="baz">This is some <b>bold</b>text</foo>

Would need to expand to something like:

{
  "foo": [{
    "@attributes": { "bar": "baz" },
    "@value": "This is some",
    "@tail": "text",
    "b": [{
       "@value": "bold"
    }]
  }]
}

Which quickly becomes rather unreadable.

-Andrew

> 
>> 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

Received on Friday, 18 September 2015 22:32:30 UTC