Scott Lis wrote:Maybe there are other alternatives. JSON is lightweight and extensible. However, it looks like many of the representational problems have been solved with XML, and there are many tools already available.
The real issue is not the choice of syntax, JSON vs. XML or whatever: it is semantics -- what does the data *mean* or *represent*?
In my opinion, MusicXML as it exists has at least four deep problems, one of which cannot be fixed and three of which I see no prospect of fixing. I have brought all of them up on this forum, and I believe Michael Good and I have agreed to disagree about whether they are serious, fixable, or even problems at all, but I would like to state them again for the record, since the issue at hand has such long-lived consequences.
The unfixable problem is the collision between MusicXML's desire to represent music semantically and the desire to represent printed scores accurately. Probably the most serious of these is its mixing of two different methods of specifying X,Y coordinates on the page: relative to the "default location" (i.e., whatever the engraving algorithms of the implementation choose), and absolute on the page. MusicXML files that mix these -- which are common, and include the files produced by MusicXML's favorite implementation in Finale -- inherently simply cannot be rendered even approximately correctly by any software other than their original producer, unless that software has reverse engineered the producer's engraving algorithms. For example, I believe I have seen real vocal score files produced by Finale in which the notes were positioned using the
"default location" method but the lyrics or even some music symbols on the staff were positioned with absolute coordinates.
I believe the root of this problem is the failure to consider the graphic design of the page in terms of flow regions and fixed regions at an architectural level. While I am sure many score file representations have the same problem as MusicXML in this regard, I believe fixing it is not impossible in an archive format. Be this as it may, this problem is not fixable in MusicXML -- the current capabilities cannot be removed from MusicXML, MakeMusic has no incentive to rationalize the capabilities of Finale, and any acceptance of MusicXML as an archiving format must clearly accept current MusicXML output from Finale. (In the absence of a specification, I believe Finale's algorithms have become the de facto definition of what MusicXML files denote, which is a perversion of what it means to have an implementation-neutral standard.)
The three other problems are fixable in theory, but given what has actually happened in the 2+ years since MakeMusic acquired Recordare (namely, nothing visible), I see no prospect of this happening.
The first is that there is no specification of what is and is not a valid MusicXML file -- that is, an unambiguous mechanical test that can be applied to a claimed MusicXML file to produce a yes-or-no answer. Conformance to the DTD is necessary but not sufficient. The classic example of the problem is unterminated constructs like beams and slurs
("start" element with no "stop" element), which are syntactically valid at the XML level, but whose meaning and legality are not defined at the MusicXML level. I believe there are multiple problems like this in MusicXML.
The second is that there is no adequate specification of what even syntactically valid MusicXML files denote in terms of printed output. The worst offender is the "backup" element, but I believe there are others. Michael has said many times that "music is too complex, and there are too many interacting features and conditions" for this to be possible. Michael and I are both experienced musicians with many years' experience in software technology, but unlike Michael, I also have deep professional experience in reading and writing standards, and with all due respect to Michael's extraordinary work, I simply disagree with him about this. IMO, to the extent that "too many interacting features and conditions" are the problem, it is a problem of design, not a problem of the domain.
Finally, Michael has (in my opinion) actively encouraged the propagation of bad implementations of the current inadequate (but unquestionably valuable and useful) specification. The principle of "selective encoding" is used to condone MusicXML producers that do not output information that is available and representable. More seriously, and (in my opinion) without justification, I have documented Finale's implementation as disregarding information in MusicXML input that is clear, unambiguous, and clearly within Finale's capabilities, but this has not been considered a bug or significant deficiency. While this is not a problem with MusicXML per se, it is one that works against its solidity in practice.
The Library of Congress currently accepts a fair number of poorly defined, proprietary formats for archiving, including Microsoft Word. While this is lamentable, it is not catastrophic, because those formats have a de facto definition -- the single piece of proprietary software that implements them, which itself can be archived. MusicXML has neither a solid definition (like PDF and MIDI) nor a single controlled implementation (like Word): there is simply no way to ensure that an archived MusicXML file will be rendered accurately now, let alone accurately or even identically at some future time, which makes a mockery of the basic mission of archiving. MusicXML files cannot even serve well for analysis in the absence of a complete definition of their semantics.
We all know the saying "The best is the enemy of the good." It seems likely that that principle will carry the day here, since MusicXML is so clearly the most widely supported existing openly documented score representation format and since it is good enough for so many purposes. I don't mind being on the losing side of the discussion, especially since I probably won't be on the planet 20 or 30 years from now when Finale will no longer be around and no one will be able to reconstruct how those archived files are supposed to look. I'm just not very happy with the outcome.
L Peter Deutsch
