Spec Guidelines: product classification and spec. modularity

Hi,
I have some comments on the outline of checkpoints 2.1 - 2.4 in the spec. 
guidelines document.
This ties in with Lynne's discussion about modularity in specs

The checkpoints deal with the requirement of a spec. to detail classes of 
products and conformance requirements for those products.

I think it is important to capture this information but a specification is 
not the place to do it.

Here's why:
  * Classification is products is an open-ended task.
    This places an obligation on spec maintainers to update the spec for 
each    new product class. Spec updates for reasons other than a change in 
the    technology being described are usually undesirable (confuses 
implementers and    vendors, can be exploited by marketers etc).

  * Classifying products is a commercially sensititive issue and this 
could lead    to unwanted interference in the spec.

  * Some products will implement several specifications. That will mean 
that such    types of product will have to be listed in more than 
specification. There is a duplication    of information here with the 
extra burden of keeping the various specs. in synch.       e.g. a company 
creates a product that implements spec. v1 but the product does not    fit 
into any existing class. Can they claim conformance to the spec? Or do 
they    have to wait for a new version of the spec? If they wait, they can 
then say 'we    implement spec v2' whereas their compeitors are saying 'we 
[only] implement v1' - see how    this could be abused?!
   In the Open group we have the idea of a 'product standard' to handle 
product  classification. This is mainly a device to aid certification 
programs but   the result is to keep product classification independent of 
specifications. The product  standard recognises that a product must be 
identified - given a class label and  that it's conformance requirements 
must be stated. CRs are usually simple and  refer to the Normative specs   
e.g. 'implements all mandatory requirements of RFC2616'
  Optional requirements are also identified

  The product standard goes further and identifies environmental 
dependencies for  operational and portability requirements. This is very 
important and it's also  outside the scope of a base spec so it's useful 
for a product standard to capture  this. 
  We could have guidelines recommending that spec authors create product 
classes
  (product standards) but I think these should managed as separate 
documents. They
  would quote conformance requirements by referencing particulat normative 
specs and
  would be ties to the quoted version of the spec.
   This affects guideline 3 also: if a product is not an implementation of 
a recognised  class can it claim conformance? If so - what is the value of 
a product class at all?

  (this is why in The Open Group we use product standards in relation to 
certification   programs in which one cannot claim conformance unless the 
product fits a recognised class -  but this is obviously innappropriate 
here)
   -AndrewT

Received on Monday, 25 March 2002 09:43:41 UTC