Path: utzoo!attcan!uunet!cs.utexas.edu!jarvis.csri.toronto.edu!helios.physics.utoronto.ca!ists!yunexus!davecb
From: davecb@yunexus.UUCP (David Collier-Brown)
Newsgroups: comp.std.internat
Subject: Re: Standards and Implementation
Message-ID: <7856@yunexus.UUCP>
Date: 22 Feb 90 15:10:33 GMT
References: <1015@philmtl.philips.ca> <3318@hp-sdd.hp.com>
Organization: York U. Computing Services
Lines: 52

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.