Re: Spec Guidelines: product classification and spec. modularity

At 07:49 AM 3/26/02 -0500, Lynne Rosenthal wrote:
>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.

Indeed.  I suspect that there are different concepts being discussed by 
Andrew and you.

>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.

This is the way I interpreted it.  I have a hard time seeing how to write 
any meaningful conformance statements for a standard like SVG or WebCGM, 
without such highest-level distinctions.  See the SVG 1.0 conformance 
clause [1].  It defines conforming content (standalone, embedded fragments, 
etc), conforming generators, conforming interpreters (including viewers).

By the way, content doesn't really fit under "class of products", so the 
wording in Spec Guidelines ought to be general enough (or specific enough) 
to encompass it.

>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.

You'll see examples of this again in SVG conformance clause [1] -- e.g., 
SVG viewer conformance (in some of the several possible flavors) requires 
conformance to DOM and to CSS.

>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.

I agree that Spec Guidelines should not require specific conformance 
patterns when there are external dependencies and/or 
modularization.  However, Spec Guidelines should require that 
specifications must, where there are dependencies and/or modularization, 
address and be clear about conformance in these cases.  This is how I 
interpret what you're saying next...

>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)



>At 09:41 AM 3/25/02, Andrew Thackrah wrote:
>>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 Sunday, 31 March 2002 20:36:32 UTC