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.
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.
Who produced the document?
What is the stability of the referenced document as a whole?
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?
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".
What is the stability of the referenced part(s)?
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?
For example, the name of the
Document interface in DOM4 is also in the DOM Level 3 Core Recommendation.
What is the nature of the dependency on the referenced part(s)?
For example, if the referenced document changes:
What is the status of the implementation of the referenced part(s)?
What are the agreed milestones for the W3C specification?
W3C seeks to issue Recommendations that can be implemented on a Royalty-Free basis.
What are the licensing terms of the referenced documents?
Note: The experimental normative references checker can be used to identify which references are or should be normative in your document.
The guidelines in section 2 are evaluated for references from W3C specifications to the WHATWG HTML and DOM Living Standards as follows:
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.
|2023-10-23||Move document to GitHub. Update to current, 2023 Process.|
|2020-10-30||Update W3C Recommendation track citation to the current W3C Process. Update Patent Policy reference to the current version and correct a fragment id. Clarify the intent regarding backwards compatibility in the Stability section introduction.|
|2019-06-14||Correct a mailto: reference. Update W3C Recommendation track citation to the 2019 version. Add Appendix I.|
|2018-04-17||Update W3C Recommendation track citation to the 2018 version, note that the checker is experimental|
|2018-02-07||Added a note about the normative reference checker|
|2014-09-11||Update W3C Recommendation track citation to the 2014 version|
|2015-04-06||Added a second example in 2.2.1, and an example in 2.2.2 and in 2.3.1|
|2013-10-18||Distributed to the W3C Advisory Committee and Chairs for comment on 18 October 2013.|
Feedback is to @w3c/tilt and is welcome on GitHub