Normative References

Purpose

Normative references between specifications are typically references to established standards previously published by recognized groups or to work in parallel in W3C. As a W3C specification progresses toward Recommendation such normative references rarely raise concern provided the referenced specification is stable and has licensing terms that are consistent with royalty-free implementation of W3C Recommendations, or the parallel W3C work is proceeding on a similar schedule. Borderline cases arise when a specification contains a normative reference to another specification that is not yet an established standard or that has licensing restrictions that may interfere with the intended use of a W3C Recommendation.

This document explains considerations the Director takes into account when evaluating normative references from W3C documents at transitions on the W3C Recommendation track. These considerations may be used by the Working Group while evaluating the risk associated with specific design choices during the group’s deliberations. The Director may refer to this document when a transition request is being decided.

At a high level, when a W3C specification has normative references to other documents the Director considers 3 factors: stability, schedule and licensing. Any of the factors described in this document are fodder for Director consideration. No single factor is decisive. Different cases will involve different combinations of these factors. The Director may consider other factors not listed in this document as well; e.g. the likelihood that W3C may wish to submit the Recommendation to ISO and the PAS criteria for normative references.

Stability

The Director considers the stability of the referenced documents by evaluating the probability that the referenced documents will change and in which timeframe. In the unfortunate event that the referenced document will change, the risks to deployed resources (deployed markup, other standards, documents, code, products, applications, …) will be considered as well as associated recovery strategies.

There are several factors that the Director needs to consider as part of a stability assessment.

External organizations

Who produced the document?

Is it produced by a group that the Director believes follows the OpenStand principles?
Is the normative version of the referenced document available in English? If not, is there an English translation?
Is the referenced document available on the Web at no cost and without limitation?

Stability of the referenced document

What is the stability of the referenced document as a whole?

What stability claims do the organization and group who published the referenced document make about that document?

For example, in the case of a reference to a W3C document, is that document not yet a Proposed Recommendation?
Is the referenced document subject to change, how often, and to what degree? Are there specific dated and/or versioned references?
What is the change control policy for the referenced document?

Stability of the referenced part(s)

What is the stability of the referenced part(s)?

How specific is the reference? Finer grained precise references are easier to evaluate.
Was the referenced part previously published in a W3C Recommendation or other standard?

For example, the name of the Document interface in DOM4 is also in the DOM Level 3 Core Recommendation.
Have the organization and group who published the referenced document reviewed and approved the way the referenced part is used and referenced?

Nature of the dependency

What is the nature of the dependency on the referenced part(s)?

How is the referenced part used?
1. Is the reference to the name of a interface or to a definition without relying on details? (so that any changes would have no impact on the source of the reference)
Who is impacted by the referenced part?
1. Is the reference to something that is normative to implementors of the specification or normative to users of implementations of the specification?
  For example, if the referenced document changes:
  1. Will implementers of the W3C specification need to change an implementation of an algorithm specified in the referenced document? Users may be affected as a result of changes in the implementation. (eg an encryption algorithm)
  2. Will the text of the W3C specification need to be revised to follow a new grammar from a referenced document? Implementers and users may be affected if the grammar is exposed (eg change in lexical representations of XML Schema datatypes).
  3. How will implementors and users be impacted if a term used in a W3C specification is defined in a referenced document and the definition changes? The W3C specification may be independent of the details of the definition; however, implementers and users may be impacted by the change. (eg URL, well-formed XML)
If a change impacts deployed resources, what will be the recovery strategy?

Status of implementations

What is the status of the implementation of the referenced part(s)?

What is the deployment of the referenced part(s)?
Are there tests and test results for the referenced part(s)?

Licensing

W3C seeks to issue Recommendations that can be implemented on a Royalty-Free basis.

What are the licensing terms of the referenced documents?

Are the technologies in the referenced parts available under terms that are compatible with the W3C Royalty-Free licensing requirements?
What are the risks that the referenced part(s) may be encumbered by patent(s)?
What are the policies identifying the rights and obligations of implementors of the referenced document that apply to implementors of the W3C specification?
Does the reference conform to the normative referencing policy of the organization who published the referenced document?
What normative references are made by the referenced document and are the licensing terms of those technologies compatible with 1‒3 above?
In the case of W3C documents, is there an open exclusion opportunity on the referenced document?