From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ac39a12d5faf5b14 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-04-16 21:39:58 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!colt.net!newspeer.clara.net!news.clara.net!psiuk-p2!psiuk-p3!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Rant! (was) Development process in the Ada community Date: Tue, 16 Apr 2002 13:28:47 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: References: <3CB46975.90408@snafu.de> <3CB77A6B.5090504@snafu.de> <184076622a7c648f157c56e417bd86d4.48257@mygate.mailgate.org> <3CB9375F.8040904@snafu.de> <3CB9AF3C.8030301@snafu.de> <3CBC5281.1040202@snafu.de> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1018978130 19278 136.170.200.133 (16 Apr 2002 17:28:50 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 16 Apr 2002 17:28:50 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:22632 Date: 2002-04-16T17:28:50+00:00 List-Id: "Michael Erdmann" wrote in message news:3CBC5281.1040202@snafu.de... > > Interesing, i did not know this. Is there any information about this > in the net? May be this formality is why most of the people in the > community are not taking part in the standarization process. > Well think about some of the packages that are in the appendices right now. Things like Ada.Strings.Fixed. There is a quite detailed description of the behavior of each subprogram in there and I'd suspect you need some part of the validation suite aimed at testing compliance with that specification. Furthermore, all they provide is a spec and that means the vendors have to go out and build the bodies - which for a string package may not be that big a deal, but for something like - say - a GUI would be *waaayy* much bigger and would hence meet resistance from the vendors. (Do you really think they're just chomping at the bit to rush out and spend millions just to get themselves compliant with the next Ada standard? ;-) > > This is what is normally called a defacto standard. Raising initial > interest for a certain sloution and setting up alliences to enforce > the solution normally creates such standards. But if these alliences > breaking up, such standards start to dissolve and lot of derivates > of the original solution are back on the market gain. I like to > avoid this. > Trying to do anything real formal to avoid divergence is just going to get too costly and difficult. What might work better is some version of "Standardization By Inertia" If you got some committee of vendors and users to agree on some libraries as the de facto standard and there was a reference implementation the vendors all adopted, chances are it would just stay the way it is because nobody is going to want to spend their own money to change it without a compelling reason. Think, for example, if all the vendors agreed to just ship the Booch Compoinents with their compilers and make it the de facto standard. People w ould be using them based on what they knew of the reference implementation and they'd expect their vendor to give them a conforming copy. If extensions were desired, there'd be a strong incentive to get them into the reference copy so long as doing so wasn't unnecessarily difficult. (The users and the vendors don't want to go updating everything in the world if BC v2.0 comes out with differences from their divergent paths.) > But your second tier idea may be the right point! This second tier > could become some kind of public entry process for the ISO WG which > is in the first stage (input) less formal and at the output as formal > as ISO requieres. > Establishing such a second tier interface to the public would be > an interesting project for the open source community, and may > be some ideas of the JPC may be taken over for this purpose. > I really think that once you stick the initials "ISO" on it you're asking for a rigid, validatable, *sloooooow* process to be put in place. It would be better to form something up under some less formal structure. It might work better to do something under the auspices of SIGAda - that's how ASIS got done, IIRC. You need the input and guidance of the vendors because if they won't sign up to include/implement whatever you come up with, the whole game is over. If the vendors said "We'd be interested in libraries that cover the following subjects...." and your working group could come up with an answer they'd be willing to adopt, *and* you could come up with the necessary resources to build a reference implementation, you might see a fairly quick and agile process evolve that probably wouldn't see a lot of divergence from the "standard". I really doubt that lobbying for *anything* to happen under ISO is going to result in any sort of process that meets the objectives you seem to be supporting. The less formal it is, the more likely it will be to move quickly and be willing to listen to what you have to say. If you got something that was adopted as a de facto standard, it would likely be a lot easier to get it included into the ISO standard after that point - if that seems at all important if/when that happens. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com