Quote:
Originally Posted by RustyBrooks
I don't entirely agree, but I also don't think a slavish xml-to-json translation is a particularly strong argument. I've written music software for years and I think this representation for a note is fairly awful.
Among other problems, the XML schema essentially loses type - you have things that are numbers that get represented as strings. The DTD may or may not make this plain in the XML, but it's something the parser has to "know" and in JSON, if done right, you'd just have proper numbers and strings.
I don't think the representation they chose is a particularly good one. "16th" for christ's sake. Laboriously pointing out step and note when pretty much everyone recognizes "C5". The inclusion of both duration and type is probably redundant unless this is meant to be an encoding of a performance where notes are not strictly tied to their official note length.
The XML in that example is MusicXML, which is the open data interchange for music notation engraving. MusicXML is used in pretty much everything, from MuseScore, Sibelius, Guitar Pro, etc.
I think there is some benefit to the style they use, but yes, you are correct, MIDI-style formats are cleaner.
***
I simply I don't think that JSON does a very good job of handling larger data dumps.
Here's another example, from the eBay API:
http://developer.ebay.com/devzone/re...rder__get.html
You'll have to scroll down a bit, but the payloads, both going out and coming in, are very large and difficult to deal with correctly. In the eBay API JSON example, the prices are strings, etc, so same issue as the XML irt to typing.
It's also impossible to appreciate how expansive and malleable that API is without taking in 50 orders at a time. Many items are optional, there's different outputs for different kinds of orders, and many other fun little traps.
I'm not saying that XML is better per se, and I believe JSON is better for smaller payloads than XML. I'm just not convinced that XML or JSON is particularly good for large structures.