As a long-time standards user and contributer (in the data communications field) my opinion is that there is no completely 'right way' to do a standards process. If there is a need for a function, it will get done lots of different ways before a standard is finally agreed. We can learn from history, by looking at two 'somewhat competing' standards bodies and what was achieved. (Note that the details may not be right, but you get my meaning) The International Standards Organization (ISO) created a bunch of standards for data communications which were a marvel of architectural rigour and elegance - anybody remember the Open Standards Interconnect 7-layer model. Unfortunately, they were cumbersome to implement and nobody wanted to be first because they were in a state of flux. In particular the network management standards were very difficult to understand. Meanwhile a bunch of yahoos took the most import parts of the OSI network management standards and implemented a simple network management protocol (SNMP) that could be quickly implemented by anybody. Once it was working they submitted it as a draft Request for Comments (RFC) to the Internet Engineering Task Force, and it quickly became the standard most network devices use today. FOR ALL ITS FAULTS, and it has quite a few, it was good enough to do the job and implementable quickly. Today, nobody cares about the OSI network management protocols. New versions of an IETF standard must be accompanied by a reference implementation, so you don't get the case where a standard is not implementable. To draw an analogy, we need to - issue the equivalent of an IETF RFC that describes the current standard and nominate a reference implementation. This means we need to freeze one of the open-source implementations at that level, and ensure that other implementations support it. A test suite would be a really nice thing to have, too. - issue a reference implementaton and specification for the next version of abc (which, by the way, does not need to support everything we've talked about so far, only the parts we agree on) Meanwhile, extensions are perfectly fine in anybody's software, but they should be identified as such. Eventually they become candidates for the standards process. By the way, I still haven't implemented the V: directive in Skink because I can't decide which of the several competing approaches is most likely to survive. Phil's recent work in reformulating the same tune to make it compatible over more packages gives me hope that we can come up with a common format. [EMAIL PROTECTED] wrote: > Phil Taylor said - > > >1. Anything but the most simple extension needs some experimentation > > >to find out what works. You've got to do it first, then try it out > with > >a lot of music to see if it's a good idea. > > > I don't see why that precludes discussing it on the list before > releasing it. > At the very least, that would mean people were aware of what was > being done. > > >2. If we had to wait for agreement nothing would ever get done. > > So it gets done whether there is agreement or not. Does this mean you > > wouldn't object to me introducing a sharps/flats and no tonic version > of the > K: command? > > >Nobody's hostile to anyone here (present company excepted, of > course). > > Well, Jim Vint seems to come in for some fairly robust criticism and > as for > me, at least you are responding to what I say rather than going > straight into > "Bryan bashing mode" . That's encouraging. > > >middle = was proposed after the draft standard appeared. > > So put up a new proposal. You are on the standards committee, dammit. > > >I never bothered proposing Gregorian chant as a general standard as > it's > >such a specialised area. > > Fair enough. Nobody is going to be accused of an incomplete > implementation > of abc if they don't include it in their software. On the other hand, > if it > was a published standard, people could take it up if they wanted and > ensure > that their version was compatible with yours. > > >>>Multivoice abc using V: started in abc2midi and (at least in its > basics) > >>>is now supported by most programs. > >> > >>In at least two incompatible versions (see above). > > > >Not completely incompatible (see above). > > That sounds a bit like "slightly pregnant" or "almost a virgin". Jack > Campin > posted an interesting version of Shingly Beach recently using BarFly > notation. Muse, abcmus and my own abc2nwc couldn't cope with it. > abc2win > produced all the right notes but not necessarily in the right order. > I don't > imagine abc2ps could handle it. Frank Nordberg recently posted > separate > BarFly and abc2ps versions of a tune. > > >The draft standard is just that. It represents one person's > proposals > >put up for discussion. I've made my opinion on that section clear on > > >several occasions, and will continue to do so. > > It actually represents something that someone has already implemented > and > then put up for discussion; a procedure that you endorse in your point > 1 > above. Once somebody has put a lot of work into implementing > something they > think is a good idea, they aren't going to throw it all away because > somebody > then says they don't like it, as I'm sure you'll agree. > > One day there will be a single agreed abc standard (maybe, but not > yet). > > Bryan Creer > To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
