Re: [ISSUE] Clear GP/Principle statements

QA WG,

I added a few comments and suggested rewording.
I added 3 possible issues (end of the mail). I would like your opinions 
before I record them as official issues.

Le 28 sept. 2004, à 07:18, Dominique Hazaël-Massieux a écrit :
>> ICS-005-GP: Provide an Implementation Conformance Statement (ICS)
>> proforma.
>> ICS-006-GP: Require an Implementation Conformance Statement (ICS) as
>> part of valid conformance claims.
>
> I don't think the abbreviation needs to appear at all in the GP; at
> least, I don't think it needs to appear in both of them.

Agreed.

>> ICS-013-GP: define the terms in-line, and consolidate the definitions
>> in a glossary section
>
> Suggested rewording:
> Define the normative terms in-line, and consolidate these definitions 
> in
> a glossary.

here I think we loose a bit of the section issue. Do we want absolutely 
to have to a glossary inside the specification or can it be outside of 
the spec ala QA glossary. Depending on that the sentence can be 
slightly changed.

>> ICS-014-GP: Re-use existing terms, and don't redefine them

Use terms already defined without changing their definition.

>> ICS-017-GP: Subdivide the technology to foster implementation
> "Create subdivisions of the technology when required by the variety of
> implementations"

Create technology subdivisions when needed for implementation diversity.

Still not good.

>> ICS-020-GP: Define rules for creating profiles
>
> Suggests:
> "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.
> (see my suggested wording before)

 From http://www.w3.org/mid/1096299340.15676.182.camel@stratustier
"Determine the need for each option. Make sure there is a real need for
the option."


>> ICS-022-GP: Indicate any limitations or constraints
>
> "Indicate limitations and constraints of the optional features"; I 
> think
> it needs more work since one of the intent of the GP is to encourage
> narrowing the optional features altogether.

Limit the choices on optional features by defining all their 
limitations and constraints.

Sounds more positive:
Optimize the choices on optional features by defining all their 
limitations and constraints.


>> ICS-023-GP: Address the impact of the option
>
> Hmm... It's unclear to me whether this really belongs to a 
> specification
> (i.e., do we want to see the discussion of the impact of an option in
> the spec itself, or in a separate document, or....). The obvious
> rewording would be "Address the impact of optional features on
> interoperability", but again, I think this probably needs more work.


If a group has decided to create optional features, it means they have 
done a cost/analysis benefits of this choice (in the best case). Though 
as Dom said I don't expect to see it in the specification itself, 
because it's more the results of an internal discussion. At the same 
time it's an important topic.
	Three possibilities:

1. Straighten the notion of the Good Practice by requesting a 
section/wording for each optional feature to clearly define in which 
framework they apply and what are the risks of implementing them. In 
the same order, we could request a practical implementation section 
which guide the developers through these choices... But is it not the 
goal of spec? running in circle.

2. This good practice is moved to the QA Handbook as something which is 
a requirement to address when when the WG starts to deal with optional 
features.

3. Keep the last section about quality process that I was saying that 
can't be proved, make it an appendix of specification guidelines, and 
put into it everything which is related to work organization of a 
specification but can't be proved to be present in a specification.
	For each principle and guideline, if I read a WD, can I say without 
problems, Yes, No or N/A. If not it may be part of this section.

>> ICS-024-GP: Make options easy to find. Use tags to label options.
>
> s/options/optional features/
> "Using tags" is probably more of a technique than a GP.

	"Clearly identify optional features."
	Agreed for the technique

>> ICS-025-Pr: Address the extensibility topic inside specification.
>
> "Address extensibility"? (inside the specification is redundant; so is
> the the notion of "topic")

Create a section addressing extensiblity in the specification.
or
Address extensiblity in the specification.

Once again this will be difficult when a technology is divided in many 
specifications (documents). I'm reading a lot of specifications and 
it's sometimes very difficult to apply strictly SpecGL because of the 
organization. It's my usual rant ;) on technology package:
			multi-documents versus monolothic document.
When we say specification, I'm more incline to think technology, the 
technology being a set of documents which define the technologies in 
terms of modules, profiles, etc.
In both cases the technology can have modules, profiles, levels, etc. 
but some will divide it in multiple documents to ease the editing work.

I wonder if it's something we should ask the TAG or the Process 
document to address if there is consensus on that in the WG.


>> ICS-026-GP: Define the extension mechanism
>
> If extensibility is allowed, define an extension mechanism.

ok.

>> ICS-029-Pr: Identify each deprecated feature.
>
> Identify deprecated features.

ok.


Possible Issues:
	- multi-documents technology
	- inline or external glossaries
	- GP/Principles that can be objectively proved versus operational 
technology GP/Principles


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