pedersen@philmtl.philips.ca (Paul Pedersen) (02/13/90)
In article <1990Feb8.164921.22689@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <15894@haddock.ima.isc.com> jimm@ima.ima.isc.com (Jim McGrath) writes: >>... If ISO really wants their protocols >>to gain widespread acceptance they should make it easier to implement >>them. > >Implement? You think ISO cares about implementation? Couldn't prove it >by me, not considering some of the things they put in those protocols. >You don't understand: ISO protocols will gain widespread acceptance by >being rammed down our throats by politicians, not by being enthusiastically >accepted by implementors. That's how ISO works. >-- I'd like to expand on the above, given that I'm an implementor AND attend ISO meetings. ISO is only a forum in which to develop a standard. In other words, its a place where representatives from various companies and other organizations can get together and work out a common way of doing things. The big problem is that there are very few implementors on the ISO committees. I have received time and time again the answer : "we do standards, not implementations" when I bring up an implementation issue. Now, if the other members of the committee were implementors, I doubt I'd get this kind of answer. The solution has to be for the organizations sending representatives to ISO to send people who are interested in the "implementability" of the standard they are working on. Until this happens, the situation described by Mr. Spencer will remain :-( Paul Pedersen
davecb@yunexus.UUCP (David Collier-Brown) (02/22/90)
In article <1015@philmtl.philips.ca> pedersen@philmtl.philips.ca (Paul Pedersen) writes: | The big problem is that there are very few implementors on | the ISO committees. I have received time and time again the answer : | "we do standards, not implementations" when I bring up an implementation | issue. andrea@hp-sdd.hp.com (Andrea K. Frankel) writes: | This appears to vary widely from committee to committee. | [...] There are always interesting | arguments between the academic theorists who would dearly love the world | to conform cleanly to their models, and the pragmatists who are | concerned with coming up with a standard that doesn't run like a dog - | but in SC24, what generally happens is that the theorists lay the | general conceptual framework, and the pragmatists wrangle enough | concessions to end up with something realistic. Part of this dichotomy comes from the multiple meanings of "standard". It is educational to read the standards for french wines, for instance. They are almost completely concerned with what we tend to call "quality of implementation" and "verification" issues (:-)). I prefer to refer to ISO documents as specifications rather than as standards: they tell one what to do, and the better-written ones tell one how to discover if one succeeded. Given this interpretation as a starting point, and a particular standards document, an organization I once worked for: 1) decomposed the standard into a conformance document and a functional specification 2a) validated the functional specification, and 2b) developed a test plan, 3) arrived at a design 4) defined an initial subset, and 5) cancelled the project (:-)) If one tries to make a document (the standard) do more than one thing, one often gets in trouble. If you have a single, specific aim, you can make rapid progress, if the task is possible at all. "Spirited discussion" between implementors and academics can, and has, improved some standards substantially, but probably isn't sufficient. I'll put it in somewhat harsh terms: To try to make a standard serve multiple purposes raises some interesting completeness/correctness risks. --dave -- David Collier-Brown, | davecb@yunexus, ...!yunexus!davecb or 72 Abitibi Ave., | {toronto area...}lethe!dave Willowdale, Ontario, | Joyce C-B: CANADA. 416-223-8968 | He's so smart he's dumb.