Comments on CC/PP Working Draft

As a member of the QA Working Group, I reviewed the 
<http://www.w3.org/TR/2003/WD-CCPP-struct-vocab-20030325/>CC/PP Working 
Draft with respect to its ability to satisfy the QA Framework: 
<http://www.w3.org/TR/2003/WD-qaframe-spec-20030210/>Specification 
Guideline (SpecGL).  There were some things that it does very well  in 
particular, provide examples. However, it is lacking major aspects required 
by the SpecGL  in particular, a conformance clause and other information 
related to conformance.

The relevant SpecGL guideline and/or checkpoint are indicated in [ ].

1.  Identifying what needs to conform and how.  [G2]
Although the information is in the CC/PP specification, there is no 
explicit statement regarding the class of product that the CC/PP applies to 
[CP2.1] or the type of specification (i.e. category of specification 
[CP2.3]). There seems to be 2 classes of products (targets of this spec): 
1. processors and 2) data format or profile derived from the spec's rules 
for profiles (I'm not sure which, I think the latter).  The category of 
specification could be classified as 'rules for deriving profiles'.

2.  There is no conformance clause.  [G3, G10]
No conformance clause [CP 10.1].
It is not clear what is required in order to conform to this 
specification.  The conformance requirements are scattered in the text and 
thus, get lost.  For example, in section 4.3, there is a statement that all 
CC/PP profiles must conform to the RDF schema in Appendix B and in the 
title of Appendix B, the spec indicates that the Appendix is optional for 
processors.  Statements like these belong in a conformance clause.  A 
conformance clause would provide information (what must conform and how) 
and enable the reader to easily identify and locate the information without 
having to read the document from cover to cover.

It was difficult to determine if there are any universal requirements for 
minimum functionality [CP3.1].  The section on structure is normative and 
identifies the components and defaults that are required, but it is not 
clear if there are any minimal requirements that all profiles must 
satisfy.  Nor is it clear if there is a minimal set of what all processors 
must handle.

There does not appear to be any special conformance terms [CP3.2], but then 
again, there is no conformance clause or indication of what it means to 
conform to this spec.

The specification does have a normative reference section. [CP10.2]

3. Specifying conformance claims [G11]
There is no discussion of this.  It is not clear if there are different 
conformance designations (e.g., degrees or types of conformance) [CP11.1]. 
Conformance claims are not discussed [CP11.2], nor is a conformance 
disclaimer [CP11.3, CP11.4].

4.  There is no Implementation Conformance Statement (ICS) proforma [G12]
It may be possible to make the argument that a profile is in fact an ICS, 
since it identifies the capabilities of a device.  However, some type of 
ICS would be useful for this type of specification.  An ICS is useful in 
disclosing options and discretionary behavior and values and in assessing 
conformance against only the relevant requirements.

5. There are no test assertions [G14]
The test assertion is a statement of behavior, action or condition that can 
be measure or tested and is derived from the specification's requirements.

6. The other Guidelines of the SpecGL [G1, 4, 5, 6, 7, 8, 9, 13] are either 
satisfied or not applicable.
The CC/PP specification has a scope section [G1] and does identify what is 
in scope as well as what is out of scope.  It does an excellent job in 
using examples.
The CC/PP specification does a good job at satisfying G9 Extensions.
For[G4, G5, and G6], which address ways to divide the technology, there did 
not seem to be any modules [G5] or functional levels [G6].  As for 
profiles, even though the definition of profiles is different in CC/PP than 
in SpecGL, the checkpoints can apply and are satisfied.  In particular, 
CP4.4 (rules for profiles), since that is what the CC/PP is all about.
G7 (deprecated features) does not apply.
It was difficult to determine if [G8] (define discretionary items) was 
satisfied.  I think that the checkpoints, except for CP8.5, are satisfied.
Although [G13], does not clearly identify conformance requirements, it 
meets 3 of the 4 checkpoints.

regards
-- Lynne




Lynne S. Rosenthal
NIST, 100 Bureau Drive, Stop 8970
Gaithersburg, MD 20899-8970
(301)975-3353, fax (301)948-6213
lynne.rosenthal@nist.gov