Re: [ISSUE] Clear GP/Principle statements

By the draft minutes of QA WG Teleconf 2004-10-04
http://www.w3.org/mid/6.0.0.22.2.20041004120817.01cb8118@wsxg03.nist.gov

I also have updated the Editor's draft
http://www.w3.org/QA/Group/2004/10/WD-qaframe-spec/ [Member Only]

ICS-001-Pr: Include a conformance clause
ICS-002-GP: Define the specification conformance model in the 
conformance clause
ICS-003-GP: Specify in the conformance clause how to distinguish 
normative from informative content.
ICS-004-GP: Provide the wording for conformance claims.
ICS-005-GP: Provide an Implementation Conformance Statement proforma.
ICS-006-GP: Require an Implementation Conformance Statement as part of 
valid conformance claims.
ICS-007-Pr: Define the scope
ICS-008-GP: Write simple, direct statements in the scope.
ICS-009-GP: Use examples or use cases to illustrate
ICS-010-Pr: Identify who or what will implement the specification
ICS-011-Pr: Define the terms used in the normative parts of the 
specification
ICS-012-Pr: Create conformance labels for each part of the conformance 
model
ICS-013-GP: *** See Below
ICS-014-GP: Re-use existing terms, and don't redefine them
	Minutes: Use terms already defined without changing their definition
ICS-015-Pr: Use a consistent style for conformance requirements and 
explain how to distinguish them
ICS-016-Pr: Explain which conformance requirements are mandatory, which 
are suggested and which are optional
ICS-017-GP: Subdivide the technology to foster implementation
	Minutes:  Create subdivisions of the technology when warranted by the 
variety of use cases.
  	Comment: Need umbrella to encompass more than use cases, but also 
requirements, technology, etc.
ICS-018-Pr: If the technology is subdivided, then indicate which 
subdivisions are mandatory for conformance
ICS-019-Pr: If the technology is subdivided, then address subdivision 
conditions or constraints
ICS-020-GP: Define rules for creating profiles
	Minutes: If the technology is profiled, define rules for creating new 
profiles.
ICS-021-GP: Determine the need for each option. Make sure there is a 
real need for the option.
	Minutes:  Make sure there is a real need for every optional feature. 
ICS-022-GP: *** See Below
ICS-023-GP: *** See Below
ICS-024-GP: Make options easy to find. Use tags to label options.
	Minutes: Clearly identify optional features.
ICS-025-Pr: Address the extensibility topic inside specification.
  	Minutes: Address Extensibility
  	Comment: Does this need to be addressed in multiple documents when a 
technology is split into several specifications?   
ICS-026-GP: Define the extension mechanism
	Minutes: If extensibility is allowed, define an extension mechanism.
ICS-027-Pr: Prevent extensions from breaking conformance
ICS-028-GP: Define error handling for unknown extensions.
ICS-029-Pr: Identify each deprecated feature.
	Minutes: Identify deprecated features.
ICS-030-Pr: Define how to handle each deprecated feature
ICS-031-GP: Explain how to avoid using a deprecated feature
ICS-032-GP: Identify obsolete features
ICS-033-GP: Define an error handling mechanism
ICS-034-Pr: Do quality control during the specification development.
ICS-035-GP: Do a systematic and thorough review.
ICS-036-GP: Write sample code or tests.
ICS-037-GP: Write Test Assertions.


* DISCUSSION *
==============

ICS-013-GP: define the terms in-line, and consolidate the definitions 
in a glossary section
Dom: Define the normative terms in-line, and consolidate these 
definitions in
a glossary.
Minutes: Should Glossary be in-line or outside the spec?  What does 
‘normative terms’ mean? Clarification needed by dom.


ICS-022-GP Indicate any limitations or constraints
	Dom: Indicate limitations and constraints of the optional features
	Karl 1:Limit the choices on optional features by defining all their 
limitations and constraints.
	Karl 2: Optimize the choices on optional features by defining all 
their limitations and constraints.
	Minutes: Lofton doesn’t like the addition of ‘optimize’ in the 
statement. Latest proposed wording, talks about optimizing, this is 
something that wasn’t in the original CR.  Meaning of this is drifting 
from what was originally meant. Good idea to revisit the original CR 
checkpoint to understand what was meant, since we are drifting away 
from the original intent.  Karl – Optimization comes from the 
description of narrowing the choices.  Karl will indicate the original 
CR text in the new working group draft – this will help in 
understanding the document. More discussion needed.
	QA SPEC CR: 5.3 Indicate any constraints on the number of 
choices/options that can be implemented for discretionary items.

ICS-023-GP: Address the impact of the option
	Minutes: Can a discussion about optimization be part of a 
specification?  If no, then this is a process oriented thing.  Is this 
appropriate inside a technology specification?  If yes, should have 
both pros/cons.  Discussion of the consequences of a choice should be 
part of a specification.  Once a specification introduces optionality, 
then it is too late to warn users.  Main thing is that spec writers 
consider it very carefully.  Does it make sense to include a discussion 
about why options are bad, but you included them anyway?  Karl to make 
this a new Issue – try to clarify optional features, how to deal with 
them, address them.


-- 
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager
*** Be Strict To Be Cool ***