In message <[EMAIL PROTECTED]>, Steven Bennett
<[EMAIL PROTECTED]> writes
><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>
>
Seconded!
--
Bernard Hill
Braeburn Software
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
