Re: [ISSUE] Clear GP/Principle statements

Le mar 28/09/2004 à 00:44, Karl Dubost a écrit :
> A volunteer to go through? Reply positively before Wednesday evening. 
> If no answers, I'll do it.

Here is my take at it; that shouldn't prevent other from doing it too :)

(I've removed those that I think are OK)

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

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

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

I think this one needs some care, but I'm not very inspired to change
it... (gee, both are my own writings :)

> ICS-017-GP: Subdivide the technology to foster implementation

I think the GP doesn't really convey what the text below is really
about... What about:
"Create subdivisions of the technology when required by the variety of
implementations"
That still doesn't read very well, so better suggestions are more than
welcome, but I think at least it makes more sense out of context, and
better reflects the rest of the section.

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

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

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

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

> ICS-025-Pr: Address the extensibility topic inside specification.

"Address extensibility"? (inside the specification is redundant; so is
the the notion of "topic")

> ICS-026-GP: Define the extension mechanism

If extensibility is allowed, define an extension mechanism.

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

Identify deprecated features.

Dom
-- 
Dominique Hazaël-Massieux - http://www.w3.org/People/Dom/
W3C/ERCIM
mailto:dom@w3.org