RE: References and Modularity

The TAG looked at versioning and referencing many times in the last 10 years, and I spent a great deal of time doing some archeology to uncover what had gone before and see if we could make more headway on the topic.

However, the topic of normative references is well-plowed. In the end I didn't think the TAG needed to issue any "Finding" because there is already a W3C Recommendation which adequately covers the topic, namely 
http://www.w3.org/TR/qaframe-spec/


========================
Each normative reference to another specification (from W3C or not) should adhere to as many of the following principles as apply:

* Make reference to a precise and unique version of the other specification.
* When referencing a generic technology and all its future versions, be sure that the technology is orthogonal to yours and that future versions will not create incompatibilities for conformance or implementation.
* When referencing a generic technology and all its future versions, make it clear that the conformance requirements to a fixed version of your specification will potentially change over time to reflect changes made in the referenced technology as it changes in future versions.
* When using a specific feature of another specification, use the precise designation, wording of the feature and a unique and precise way to identify this feature in the specification (using the URI to the definition of the feature, using the exact section denomination).
* Use only the meaning defined in the reference; do not interpret or assume intention of the technology, as it may lead to different interpretations depending on the readers.
* Indicate any clear constraints on the reference without making it contradictory to the conformance model of the external reference.
* Clearly identify any normative reference that, if changed, could affect the publication schedule of your specification. Make sure that it has no implication on your conformance requirements for this version.
* If the referenced technology has extensibility points, indicate for each point whether your technology also extends at that point, restricts the range of extensions allowed at that point, or is transparent to that point.
=======================

Just giving a reference to an undated specification doesn't meet these guidelines, but it's certainly possible to "referencing a generic technology and all its future versions", you just need to "be sure that the technology is orthogonal to yours and that future versions will not create incompatibilities".   If the "and all future versions" documents you cite are managed by the same organization as the standard you're addressing, you might be able to get away with that, if that organization insists on cross-working group coordination. 

Is there any part of www.w3.org/TR/qaframe-spec/ you disagree with? 

And is there any reason not to give *both* the date/version/identity of the spec you read when the editor MADE the normative reference (the precise and unique version) , and *also* a pointer to the site where the latest version is likely kept?  (until it is forked, of course).

Larry


> -----Original Message-----
> From: L. David Baron [mailto:dbaron@dbaron.org]
> Sent: Wednesday, May 29, 2013 9:36 PM
> To: Robin Berjon
> Cc: www-tag@w3.org
> Subject: Re: References and Modularity
> 
> On Wednesday 2013-05-29 12:02 +0200, Robin Berjon wrote:
> > There is a strong tension, if not a strict incompatibility, between
> > modularity and stable references. Modularity requires some degree of
> > dynamic linking, or of independent layering. Stable references push in a
> > different direction. I think that we need flexible rules based on
> > expectation of good design, even if it means longer, harder transition
> > calls.
> 
> I'm pretty strongly on the modularity side of this balance.  I think
> there have been areas where the concept of normative reference to
> specific versions has been taken *way* too far.  I think one of the
> worst examples was IDNA, which led to bugs being filed such as
> https://bugzilla.mozilla.org/show_bug.cgi?id=289183 .  I think it's
> preposterous that different attribute values in the same document
> should be expected to have different conversions from a URI
> reference in string form to URI semantics.  It's excessive
> complexity for both implementors and users of the platform.
> Instead, new technology needs to be designed around real
> compatibility problems while not getting stuck debating
> compatibility problems that are purely theoretical.  (Yes, there's a
> continuum there that sometimes requires real judgment calls.  Making
> those calls is our job, and we shouldn't shy away from it.)
> 
> I've also been meaning to blog about this for a number of years (the
> planned part 2 to follow http://dbaron.org/log/2007-03#e20070325a ).
> Hopefully I'll get a chance to finish writing that post sometime.
> 
> Frankly, I would want to treat any normative reference to a specific
> version of a specification as inherently suspicious except when the
> reference is to a specification-definition tool such as WebIDL,
> since such a reference is likely to be a sign of poor modularity.
> 
> -David
> 
> --
> 𝄞   L. David Baron                         http://dbaron.org/   𝄂
> 𝄢   Mozilla                           http://www.mozilla.org/   𝄂

Received on Thursday, 30 May 2013 22:24:31 UTC