Re: Spec Guidelines: product classification and spec. modularity

This brings up an important point - that is, as we write the Framework 
documents, we need to be careful regarding the terminology we use and that 
we explain/define the terms.

Specifically, in the Spec guideline -  class of products' is used to refer 
to the types of implementations of a specification (at the highest level) 
--- in WebCGM this would be generators, the metafile, interpreters; for the 
UAAG this would be user agents.
As for modularity - there are several ideas here.
1. a specification often depends on other specifications or parts of other 
specifications. For example, requiring a player that conforms to the 
current specification to support CSS, DOM and be capable of 'playing' all 
compliant XHTML content.
2.    an implementation of a specification may be comprised of several 
components.  Some of these components may be required in order to have a 
conforming implementation of the current specification.  For example: SMIL 
has modules and requires specific modules be present to claim conformance 
as well as some modules are dependent on other modules (e.g., SyncMaster 
module requires the SyncBehavior module)

The Spec guideline should not require #1 or #2 above, nor should it require 
specific components/modules. However, the Spec guideline should recognize 
that there are specifications that do this, and in those cases a 
Guide/ckpoint can help to ensure that appropriate steps are taken to fully 
specify what needs to be specified (e.g., make normative reference to 
specifications on which the current spec depends, are there modules that 
are required to claim conformance)

--lynne

At 09:41 AM 3/25/02, Andrew Thackrah wrote:
>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
>