Member → The Art of Consensus →

About Publication Rules

This Guidebook is the collected wisdom of the W3C Group Chairs and other collaborators.

This Pubrules checker is now deprecated. Please use the new pubrules checker.

This document contains material to supplement (and shorten) the W3C Technical Report Publication Policy, including a glossary, some assumptions made in the pubrules checker, and more history and background. This document complements the version of pubrules identified by this URI: <http://www.w3.org/2005/07/pubrules>; please refer to the latest version of pubrules with this URI: <http://www.w3.org/Guide/pubrules>.

Exceptions to the requirements of the W3C Technical Report Publication Policy MAY be authorized by the Head of W3C Communications. Per announcement to the Chairs on 20 March 2001, the Communications Team will announce all substantive changes to this document to W3C Chairs. After any substantive change, editors will have a 30-day grace period (starting with the announcement of the change) before the change will be enforced by the Communications Team. During the 30-day period, editors may publish documents that conform to either the old or new pubrules.

The W3C Webmaster uses the W3C Technical Report Publication Policy maintain the W3C technical reports index, the Member Submissions index, the Team Submissions index, and the Incubator Group Final Report index.

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in RFC 2119.

Please refer to the latest version of the current document with this URI: <http://www.w3.org/Guide/pubrules-about>.

Issue management and changes

Please report issues or make change suggestions to public-pubrules-comments. You may cc another list (e.g., chairs, or spec-proc) to start a discussion with those communities at the same time. See also:

• group of people interested in pubrules development
• pubrules issue tracker
• public-pubrules-comments archive

Glossary

In this document, consistent with the W3C Process Document, the following terms are used:

Recommendation Track (Rec Track) document

Any document that the Working Group expects to become a W3C Recommendation; Recommendation Track documents have one of the following maturity levels: Working Draft, including First Public Working Drafts and Last Call Working Drafts (WD); Candidate Recommendation (CR); Proposed Recommendation (PR); or Proposed Edited Recommendation (PER).

W3C Technical Report

Any document that is either a Recommendation Track document or has one of the following maturity levels: Working Drafts not expected to become a W3C Recommendation, including First Public Working Drafts and Last Call Working Drafts (WD); Recommendation (REC); Rescinded Recommendation (RSCND); Working Group Note, Interest Group Note, and Coordination Group Note (NOTE).

Submission

Any document with any of the following maturity levels: Member Submission (SUBM), Team Submission (SUBM).

Delta Specification

A "delta specification," though difficult to characterize precisely, is one that looks like this: it defines a small set of features, incorporates normatively a large set of features for the same technology from another specification, and is intended to supersede that other specification. (Note: If a specification builds on a foundation AND extends that foundation, it may be in conflict with the TAG's advice regarding orthogonal specifications.)

In general, W3C prefers publishing "full" or "merged" specifications instead of delta specifications for several reasons. The first is that the W3C Patent Policy applies to text in a document and does not extend to "technology developed elsewhere and merely incorporated by reference" (see section 8.2 of the W3C Patent Policy). Thus, in many cases, publishing a full specification is likely to increase patent policy coverage. (We recognize that if the same Participants produce both the original and the delta specification, the point is moot.) Readability and avoiding inconsistencies (which one often discovers when merging two texts) are two other reasons to prefer "full" specifications. Please contact the W3C Communications Team if you have questions on delta specifications.

Some Assumptions Made by the Checker

The checker interface is designed to be as simple and therefore we have made some assumptions to help keep it simple:

1. If the document type is a CR, PR, or PER, then we assume the group expects the document to become a W3C Recommendation.
2. If the document is not going to become a W3C Recommendation, then we assume:
   • It contains no normative material.
   • It bears no special relation to a previous Recommendation (e.g., it does not obsolete or supersede a previous Recommendation).
3. The patent policy boilerplate text is designed to include some hooks for the patent policy, namely that a document is informative-only or not expected to become a Recommendation.

Note: There are some live links in the publication rules boilerplate text that are intentional placeholders; one gets an HTTP 404 when dereferencing them. The link checker will let editors know if these temporary placeholders have not been replaced with real links in target technical reports.

Identification of Status Section

A number of tests examine the status of the document section. In exchange for not requiring that the section be delimited in a standard fashion (e.g., with a div element), the calculation of what constitutes the status of the document is more complex and not reliable in all cases. Thus, some checker tests related to the status section may fail when the algorithm for determining the status section fails. For instance, if the status section begins inside a div element that closes before the end of the status text, the text outside the div is unlikely to be identified as being part of the status section.

Stability of Group Notes

Because groups use Notes in many different ways, their stability levels can differ widely. Please see the status section of a specific Note for the group's expectation of stability.

History of Pubrules

20160801: This pubrules is being replaced by the new pubrules checker.

20160301: Updated for the new TR style.

20150901: Updated for 01 September 2015 Process.

20150206: Removed "All Rights Reserved" per Document License update.

20140801: Updated for 1 August 2014 Process. The changes include (1) New rule to include identifying process in status section for publications after 2 September 2014 (2) Two small rule adjustments due to merge of LC and CR.

20140121: Errata text in Recommendations updated.

20120806: Allow section element for heading anchors (7.1: Every marked-up section and subsection of the document MUST have a target anchor).

20100712: Pubrules allows XHTML+RDFa for Recommendations.

20090930: WCAG 2.0 part of pubrules.

20080624: Pubrules allows XHTML+RDFa for non-Recommendations.

20060315: Version announced to Chairs 15 March 2006. Grace period prior to that began with released 31 January 2006 (after review by Chairs in September 2005 followed by checker updates). In addition to some updates to provisions, integrated checker and template.

20040202: Version released with 5 February 2004 Process Document. Reorganized, shorter and restyled.

20031201: Version sent for review with 24 Dec 2003 Process Document. See the list of changes since the previous draft.

20030630: Snapshot of pubrules prior to making Process Document operative on 1 July 2003.

20030108: Modified Copyright Statement (changing year to 2003, replacing INRIA with ERCIM, and using short names of all ipr notices).

20020925: Provided clarification on patent/intellectual property declaration, removing "counting" language.

20020424: Added explicit placements for errata and alternative formats; creation of patent/intellectual property declaration linked from Status; existing publicly archived mailing list linked in status

20020409: Added Tools section and changed links from How to Write a W3C Technical Report to Manual of Style.

This document arose from January 2000 discussion on the Chairs list, after considerable experience and discussion of (the now deprecated) How to Write a W3C Technical Report.

Note: Some status section requirements used to appear in the Process Document. The Advisory Board has recommended that they be included here as a convenience to editors. These requirements have undergone review by the Membership as part of reviews of the Process Document.