Re: [SpecGL DRAFT] D3 - Principle: Address the extensibility topic inside specification.

Hi Karl
I like this - it is short and simple.  Comments and suggestion in line.

>D.3 Extensibility and Extensions
>
>Previous:
>---------------------------------------------
>Principle:
>         Deal with the likelihood of extensions. Consider whether some 
> parts of the specification will benefit from extensibility. If so, define 
> a mechanism to allow for the extension.
>---------------------------------------------
>
>Proposal:
>---------------------------------------------
>Principle:
>         Address the extensibility topic inside specification.

Replace with: Address the topic of extensibility in the specification

>Meaning:
>         Extensions might be encouraged or discouraged by the Working 
> Group. There is a benefit to address the value or danger of extensibility 
> for the technology which is currently developed.

to addressing the value or danger of extensibility for the technology which 
is currently being developed

>Formalizing the position of the Working Group by a clear defined section 
>and prose will remove ambiguities for the specification users about the 
>possibility of developing extension or not.
>
>Care:
>         There are strong chances that developers will create extension to 
> a specification, because they have specific needs which are not covered 
> by the specification and that they have to develop in a private specific 
> context.  Writing clearly how the extensions have to be developed is a 
> necessity to avoid a few issues: interoperability problems, minimal 
> support, harmonious future development.

There is a strong likelihood that developers will create extensions to a 
specification, because they have specific needs which are not covered by 
the specification. Writing clearly how the extensions need to be developed 
will help ensure that extensions are defined in a consistent manner leading 
to predictable handling of extensions and minimize issues such as: 
interoperability problems, minimal support, and harmonious future development.

>
>         The WG may consider that the technology is complete, 
> self-sufficient and don't need at all any extensions. In this

and doesn't need any extensions.

>case, it is necessary to write it clearly in the specification and to 
>explain why the technology is not considered

...to write this clearly in the specification...

>extensible. It might be just for the social benefit of the community to 
>ensure a maximum interoperability.
>
>Related:
>         http://esw.w3.org/topic/ExtensibilityGoodOrBad
>         http://www.w3.org/TR/2003/WD-webarch-20031209/#ext-version
>         http://esw.w3.org/topic/ExtensionSpeclite
>

Good idea, having this pointer

>Technique:
>         1. Create a section of your specification dedicated to the 
> extensions topic
>         2. Call it Extensions
>         3. Make a table of contents entry for it
>         4. Address the following principles and good practices of this 
> section
>
>Examples:
>         (I'm offline now. I'll add a few examples)
>         * CSS3 module: Syntax
>         W3C Working Draft 13 August 2003
>         http://www.w3.org/TR/2003/WD-css3-syntax-20030813/#vendor-specific
>         The specification "CSS3 module: Syntax" has addressed the topic 
> of extensions. It is clearly identified in the table of contents and 
> there's a specific section for it.
>

regards
Lynne

Received on Friday, 25 June 2004 09:20:14 UTC