Re: [SpecGL] 2.3 Normative (and non-normative) references

I'm assuming that the Normative References stuff will be a composite of 
what is now in the spec, with new stuff from Karl's distillation of 
Bjoern's comments:

http://lists.w3.org/Archives/Public/www-qa/2004Nov/0006.html

The latter talk about the value of being very specific with the reference, 
and the danger of referencing future versions, "If you think it might 
endanger your technology, don't make normative references to future 
versions, but to a specific date only."

I think we haven't mentioned one very specific danger of referencing future 
versions, and ought to.  If a particular version of your spec/technology 
normatively references future versions of another spec, then the 
conformance requirements of a specific version of your technology 
potentially change with time.  I.e., if Xblah 1.0 normatively references 
future versions of fooML, then the conformance requirements of the 
unchanged Xblah 1.0 might be different in May 2004 and May 2005 (if fooML 
advances to a new version with changed conformance requirements during that 
period).

This is potentially a recipe for chaos.

-Lofton.

(P.S.  There was a recent dialog in SVG about this.  Discussing whether SVG 
should or should not future-reference some ICC spec.)

At 04:41 PM 11/13/2004 -0500, Karl Dubost wrote:
>AI-2004102802 - Karl to write principle and good practice on normative 
>references, including time considerations, super setting or sub setting, 
>breaking conformance by Nov. 4.
>http://www.w3.org/QA/Group/2004/10/WD-qaframe-spec/#reference
>
>
>2.3 Normative (and non-normative) references
>
>A specification is rarely written in isolation. It inherits from 
>previously defined technologies and might set the future of other 
>specifications by defining their base. Then it is essential to clearly 
>defines what is the nature of the specifications (normative, informative), 
>the technology refers to and the implications of these references for the 
>future of the technology itself.
>
>As a side note, there is also an interest to study and understand the 
>conformance model of the technology which is developed in order to 
>minimize the difficulties of other specifications using it in a conformant way.
>
>2.3 Principle A:  Make a list of normative references
>
>What does it mean?
>         When a specification is developed, it relies at its core on other 
> technologies.  The Working Group doesn't need to define the core as it is 
> already clearly defined in other specifications. The Working Group has 
> then to identify any specifications which defines the core technologies 
> of the developed technology.
>
>Why care?
>         For the Working Group, it has an immediate benefit: "do not 
> reinvent the wheel". Using features which are already defined in other 
> documents helps to minimize the size of the document which is developed 
> and avoid too many ambiguities by rewriting the same concepts.
>         For the developers, it has the huge benefits of knowing which 
> part of the specification is based on another technology. It makes clear 
> what are the implications for the conformance. It may help them to 
> minimize their work by using conformant libraries already implemented 
> elsewhere.
>         For the users, it might help them to understand where the 
> technology is coming from and therefore how to use it in combination with 
> other technologies they might already know.
>
>Related
>         wiki topic on normative references
>         Manual of style
>         Pubrules ?
>         The reference tool maker.
>
>Technique
>         1. List all technologies your specification depends on
>         2. Define which version of the technologies you are using on the 
> specification
>         3. Identify each reference to these technologies in the body of 
> your document with a clear and unique label
>         4. Make a list of all these references in a section of your 
> document called Normative References.
>         Bonus: Use the format developed for extracting automatically 
> references from your document.
>
>Examples
>         All W3C Recommendations?
>
>
>TODO?
>
>2.3 Good Practice B
>         Make a list of informative references
>
>2.3 Good Practice C
>         Study all implications of your normative references choices
>
>
>--
>Karl Dubost - http://www.w3.org/People/karl/
>W3C Conformance Manager
>*** Be Strict To Be Cool ***
>

Received on Tuesday, 16 November 2004 21:47:10 UTC