Evolution/References

From W3C Wiki

This section discusses the issues around references to specifications that update. (This was originally in [References], not all of the issues raised there have been copied here.)

If spec A points to spec B, and there is a new version or edition of spec B, it hard to know in advance whether the new version should apply. The applicability needs to be examined against multiple constraints interoperability, security, accessbility, internationalization, and other constraints. Will the combination happen "in the wild" anyway?

Specifications and registry entries frequently include references to other specifications. Sometimes those references are intended to reference a specific version or edition of the specification; in other cases, the reference is intended to allow for update and evolution.

Implementers must proceed with caution. ((Note TAG issue, QA recommendation on references))

References to specifications can be given in a variety of ways:

Explicit dated reference, with no upgrade rule
Noting an exact version
Dated reference, with explicit upgrade rule
Noting an exact version, but explicitly stating how to treat updates
Undated reference, noting "work in progress"
E.g., as preferred for internet draft
Undated reference just giving a URI
assuming "Cool URIs don't change" that the reference will not change in any way that matters.

References in Standards

Many standards organizations try to mandate a policy about this. For example, the IETF tries to avoid "downlevel references", so that a specification that is expected not to change (an "Internet standard") does not make normative reference to a document that is expected to change (an "Internet Draft" or a "Proposed Standard"). Of course, this kind of rule is only useful when the organization in charge of updating the target has an update policy which would require it to keep in mind the requirements imposed by referencing document.

IETF notion of "IETF review" vs. W3C notion of "working group review" means that dependencies may not be reviewed, accepted, etc.

On the other hand, one might accept an update to a referenced spec B from a spec A, if the update to B was done with an explicit reference to the needs of A implementation community, or if the update to B was explicitly couched as an update to A.

References in Registries

Registries also contain references to specifications, with possibly a different policy about whether the registered value automatically follows specification updates.

References in Internet Media Type registry

If an organization is able to make a variant of a format or language available as a MIME type, and to get at least some readers & search engines to accept it, then some content providers might start using the variant, and as an effect, the values will use the new meaning with or without a specification update.