<delurk> Hi! I've been following the list for only a short while now (joined it because I'm considering writing a completely new ABC program using Cocoa/GnuStep/Objective C), and have been following the discussion of how to approach a new version of the standard with interest. I don't know if what I'm about to suggest has been suggested before, but it seems like a fairly critical idea if the community is serious about developing a new standard.
Coming from a background of having written a variety computer communications protocols and APIs, it's fairly clear to me that the real key to writing any new specification is adding some identifier that says that the tune conforms to the new specification. For example, maybe something like: %%ABC3.0 ...anywhere in a tune's header will indicate that the tune's encoding conforms *strictly* to the ABC version 3.0 (just an example version...) specification. (Note -- I rather agree with some of the comments here that there should be no file level commands in the next spec - everything should be internal to the tune...) If the version identifier is missing, you parse the tune as you would any previous ABC tune and deal with the idiosyncrasies of the old format however you like. If it's present, though, you can parse it strictly to the 3.0 specification -- no deviations allowed. If you know you only recognize ABC version 2.9 and earlier, you can *try* parsing it to that spec, but should warn the user why it might not work. Once you have that versioning mechanism in place, you can revise the ABC spec to something *far* more internally consistent, and deprecate items from the spec that are problematic. You could even make changes to the spec that would break older non-conforming programs if you like. (Might not be a bad idea to do just that as a means of nudging users of those older non-conforming programs to upgrade...) Finally, once the new standard is hammered out, it *has* to be a strictly conforming standard -- parsers can't be allowed to ignore deviations. Otherwise, program XYZZY will come along and add something unexpected, it will fork into MXYZZY and YZZYX, and before you know it you're back where you started. Some kind of RFC mechanism can be used to propose, comment on, review, and implement changes. IMHO, -->Steve Bennett <relurk> Phil Taylor wrote: > Yeah, that's the rub. The thing to bear in mind is that we don't have to > stay compatible with abc2win, since the people who use that program don't > need the more advanced features which we are adding to the language. > On the other hand, we do have to maintain some compatibility with abc2win's > files, because they are priceless. What we must avoid is adding something > to the language which prevents new programs which conform to the newest > standard from being capable of dealing with abc2win's files. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
