Both of these argue against any real significance to a standard. Some implementers don't care about following standards, and won't change their code to match a new (or old) standard. Other implementers want to do things outside the standard, and show a history of discussing ideas openly and avoiding conflicts. In both cases, a standard is not particularly helpful.
Lack of a standard reduces the probability of new implementations, though. I've just joined the list because I'd like to try writing an abc-to-SVG converter; that would entail writing a new parser. However, I don't want to have to reverse-engineer the current
state of the ABC language by reading an outdated spec, reading specs for various extensions, figuring out which of those extensions made it into deployed software and
which were just vaporware, and reading code to figure out extensions that haven't had specs written.
This means I can't really assess how complicated the task of writing an ABC parser is. Competing specifications such as MusicXML are uglier to read and not really authorable by hand, but at least there's a MusicXML specification available.
Google doesn't turn up either the 1.7 or 2.0 drafts that have been recently mentioned.
As a start, it would be very helpful if current versions of these drafts were available on the web somewhere, because they'd provide a clearer picture of ABC's current complexity.
--amk
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
