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 Team take 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 Team 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 Team considers 3 factors: stability, schedule and licensing. Any of the factors described in this document are fodder for Team consideration. No single factor is decisive. Different cases will involve different combinations of these factors. The Team 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 Team considers the stability of the referenced documents by evaluating the probability that the referenced documents will change and in which timeframe. In the event that the referenced document will change in a way that is not backward compatible, 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 Team needs to consider as part of a stability assessment.

External organizations

Who produced the document?

1. Is it produced by a group that the Team believes follows the OpenStand principles?
2. Is the normative version of the referenced document available in English? If not, is there an English translation?
3. 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?

1. 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?

   For example, does the document have an explicit and clear stability statement readily apparent to its readers and near to the start of the document?

2. Is the referenced document subject to change, how often, and to what degree? Are there specific dated and/or versioned references?

   For example, in the case of a document that has both stable and unstable sections, is each section clearly labeled as "stable" vs. "in progress" vs "proposal".

3. 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)?

1. How specific is the reference? Finer grained precise references are easier to evaluate.

   For example, in the case of a document that has clearly identified stable and unstable sections, do the stable sections have fragment identifiers such that a normative reference could choose to refer only to those stable sections?

2. 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.

3. 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)?

1. 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)
2. 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)
3. 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)?

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

Schedule

What are the agreed milestones for the W3C specification?

1. What opportunities will be missed if the transition must be postponed due to questions about a normative reference?
2. What would be the costs of delaying the transition?

Licensing

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

What are the licensing terms of the referenced documents?

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

Appendix I : Stability Evaluation of HTML and DOM Living Standards

The guidelines in section 2 are evaluated for references from W3C specifications to the WHATWG HTML and DOM Living Standards as follows:

• The factors listed in sections 2.1 and 2.2 are deemed to have been met.
• The factors in sections 2.3, 2.4, and 2.5 will be deemed to have been met for specific features when implementation experience has been demonstrated per W3C Process section 6.2.4 for each referenced feature.

For HTML Recommendations produced jointly by WHATWG and W3C, the DOM Living Standard is normatively referenceable.

For DOM Recommendations produced jointly by WHATWG and W3C, the HTML Living Standard is normatively referenceable.