Publication Rules

This document explains what requirements document editors must satisfy to publish a document on the Recommendation Track or a Member Submission. The W3C Webmaster also uses this checklist to maintain the W3C technical reports index, the Member Submissions index, and the Team Submissions index.

Exceptions to these requirements MAY be authorized by the W3C Head of Communications.

For information about process requirements (how to request a transition, how to request publication, etc.), see How to Organize a Recommendation Track Transition. If you would like to discuss technical report production informally among your peers and get the latest tips and techniques, try the spec-prod mailing list (archive). Document Contacts should consult the W3C Manual of Style for guidance on additional publication topics and conventions.

Document requirements

The Document Contact MUST verify that the requirements in this section have been satisfied before requesting publication. How to Organize a Recommendation Track Transition explains the remainder of the publication process. The publication requirements are:

1. The "Status of This Document" section is novel and complete
2. All XML namespaces follow established conventions
3. There are no broken links, internal to the document or otherwise
4. Normative versions are clearly identified
5. Format requirements are satisfied
6. Accessibility requirements are satisfied
7. Document head is consistent with W3C conventions

1. The "Status of This Document" section is novel and complete

The status section MUST satisfy the requirements listed in the following subsections. The Team maintains the status section of a document.

• 1.1 All Technical Reports
• 1.2 Recommendation track documents
• 1.3 Working Drafts
• 1.4 Candidate Recommendations
• 1.5 Proposed Recommendations and Proposed Edited Recommendations
• 1.6 Recommendations and Rescinded Recommendations
• 1.7 Working, Interest, and Coordination Group Notes
• 1.8 Member and Team Submissions

1.1 All Technical Reports

These requirements apply to the status section of all Technical Reports.

1. It MUST include the maturity level.
2. All dates MUST have the form DD Month YYYY. A leading zero in the day is OPTIONAL, however.

1.2 Recommendation track documents

These requirements apply to the status section of all Recommendation Track Documents.

1. It MUST include the name of the W3C group that produced the document. The name MUST be a link to a public page for the group.
2. It MUST include the name of the W3C Activity that produced the document. The name MUST be a link to either the Activity home page or the Activity statement.
3. It MUST include the name of a mailing list for comments that is publicly archived.
4. It MUST begin with the following boilerplate text:

   <p><em> This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/">W3C technical reports index</a> at http://www.w3.org/TR/.</em></p>

5. It MUST include at least one customized paragraph. This section SHOULD include the title page date of the document. These paragraphs SHOULD explain the publication context, including rationale and relationships to other work. See examples in the Manual of Style.
6. If the document is not a Recommendation, the status section MUST set expectations about the stability of the document. The RECOMMENDED text is:

   Publication as a Working Draft [Candidate Recommendation, Proposed Recommendation, Working Group Note, Proposed Edited Recommendation, Rescinded Recommendation] does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

7. It MUST include a link to changes since the previous draft (e.g., a list of changes or a diff document or both).

1.2.1 Patent Policy Requirements

These requirements apply to the status section of all Recommendation Track Documents expected to become a Recommendation or Rescinded Recommendation.

1. It MUST indicate under which patent policy the document has been produced:
   • For documents produced under the 5 February 2004 W3C Patent Policy, indicate this policy by date.
   • For document produced under the CPP as amended by the transition procedure, indicate "24 January 2002 CPP as amended by the W3C Patent Policy Transition Procedure"
2. It MUST include the following information regarding patent disclosures:
   1. a link to a public page that lists patent disclosures (details in the Guide), even if there are no known disclosures at the time of publication. (Suggestion: adding rel="disclosure" helps the pubrules checker find this link.) The status section MUST NOT indicate the number of known disclosures at the time of publication.
   2. a link to a public page with instructions on how to carry out a disclosure (generally the same page as the list of disclosures). If the document has been developed under the 5 February 2004 W3C Patent Policy, and if the document is a Working Draft published before the exclusion deadline, the status section MUST also link to public instructions for exclusions (generally near the disclosure instructions).
   3. If the document was developed under the 5 February 2004 W3C Patent Policy, the status section MUST include what the Patent Policy calls a Disclosure Request. The Disclosure Request MUST conform to the requirements of the W3C Patent Policy (5 February 2004 version), in particular section 6.3. The RECOMMENDED text is the last sentence of the first example paragraph below.

Here is a sample paragraph for a document produced under the W3C Patent Policy:

This document was produced under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C Patent Policy</a>. The Working Group maintains a <a rel="disclosure" href="....">public list of patent disclosures</a> relevant to this document; that page also includes instructions for disclosing [and excluding] a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the W3C Patent Policy</a>.

Here is a sample paragraph for a document produced under the Current Patent Practice Note:

This document was produced under the <a href="http://www.w3.org/TR/2002/NOTE-patent-practice-20020124">24 January 2002 CPP</a> as amended by the <a href="http://www.w3.org/2004/02/05-pp-transition">W3C Patent Policy Transition Procedure</a>. The Working Group maintains a <a rel="disclosure" href="....">public list of patent disclosures</a> relevant to this document; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the W3C Patent Policy</a>.

1.3 Working Drafts

These requirements apply to the status section of all Working Drafts.

1. It SHOULD indicate whether the Working Group expects to advance this Working Draft to Recommendation.

1.3.1 First Public Working Drafts

These requirements apply to the status section of all First Public Working Drafts.

1. It MUST indicate that this is a First Public Working Draft.
2. If expected to advance to Recommendation and if developed under the 5 February 2004 W3C Patent Policy, it MUST refer to section 4 of that policy. The RECOMMENDED text is:

   Per <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exclusion">section 4 of the W3C Patent Policy</a>, Working Group participants have 150 days from the title page date of this document to exclude essential claims from the W3C RF licensing requirements with respect to this document series. Exclusions are with respect to the exclusion reference document, defined by the W3C Patent Policy to be the latest version of a document in this series that is published no later than 90 days after the title page date of this document.

1.3.2 Last Call Working Drafts

These requirements apply to the status section of all Last Call Working Drafts.

1. It MUST indicate that this is a Last Call Working Draft.
2. It MUST include the end date of the review period.

1.4 Candidate Recommendations

These requirements apply to the status section of all Candidate Recommendations.

1. It include a link to a preliminary interoperability or implementation report, or a statement that no such report exists.
2. It MUST include a minimal duration (before which the group will not request the next transition). The duration MUST be expressed as an estimated date.
3. It SHOULD include an estimated date by which time the Working Group expects to have sufficient implementation experience.
4. It SHOULD identify any "features at risk" declared by the Working Group (as defined in section 7.4.3 of the W3C Process Document).

1.5 Proposed Recommendations and Proposed Edited Recommendations

These requirements apply to the status section of all Proposed Recommendations and Proposed Edited Recommendations.

1. It MUST include the end date of the review period.
2. It MUST include or link to the list of changes that may affect conformance.
3. It MUST include a link to an interoperability or implementation report. If a Proposed Edited Recommendation, the report(s) MAY be limited in scope to changes since the Recommendation.

These requirements apply to the status section of all Proposed Recommendations.

1. If the previous version of this document was not a Candidate Recommendation, the status section SHOULD include rationale for the Director's decision to skip CR (e.g., there was already sufficient implementation experience).

1.6 Recommendations and Rescinded Recommendations

These requirements apply to the status section of all Recommendations.

1. If the Recommendation is more than an editorial revision, it SHOULD include a link to an interoperability or implementation report.
2. It MUST indicate its relationship to previous related Recommendations (e.g., an indication that a Recommendation supersedes, obsoletes, or subsumes another, or that a Recommendation is an editorial revision).

These requirements apply to the status section of all Rescinded Recommendations.

1. It MUST include or link to rationale for the decision to rescind the Recommendation.
2. It SHOULD direct readers to alternative technologies.

1.7 Working, Interest, and Coordination Group Notes

These requirements apply to the status section of all Working, Interest, and Coordination Group Notes.

1. It SHOULD indicate the level of endorsement within the group for the material, set expectations that the group has completed work on the topics covered by the document, and set expectations about the group's commitment to respond to comments about the document.
2. If the document was published due to a W3C decision to stop work on this material, the status section SHOULD include that rationale.

1.8 Member and Team Submissions

These requirements apply to the status section of all Member and Team Submissions.

1. It MUST include a link to the page listing all Member Submissions or Team Submissions.
2. For Team Submissions, it MUST include the name of a mailing list for comments.
3. For Member Submissions, it MUST include this boilerplate text:

   By publishing this document, W3C acknowledges that [Submitting Members] have made a formal submission to W3C for discussion. Publication of this document by W3C indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it. This document is not the product of a chartered W3C group, but is published as potential input to the <a href="/Consortium/Process">W3C Process</a>. Publication of acknowledged Member Submissions at the W3C site is one of the benefits of <a href="/Consortium/Prospectus/Joining">W3C Membership</a>. Please consult the requirements associated with Member Submissions of <a href="http://www.w3.org/Consortium/Patent-Policy-20030520.html#sec-submissions">section 3.3 of the W3C Patent Policy</a>. Please consult the complete <a href="/Submission">list of acknowledged W3C Member Submissions</a>.

2. All XML namespaces follow established conventions

All proposed XML namespaces created by the publication of the document MUST follow the W3C XML namespace conventions (announced to the Chairs 26 October 1999).

3. There are no broken links, internal to the document or otherwise

1. If the document is compound (i.e., if it consists of more than one file), all the files MUST be under a directory (whether in /TR/YYYY/ space or Submission space) named status-shortname-YYYYMMDD/. The main page SHOULD be called Overview.html. All other files MUST be reachable by links from the document.
2. The document MUST NOT have any broken internal links or broken links to other resources at w3.org. The document SHOULD NOT have any other broken links.

4. Normative versions are clearly identified

1. Normative versions of a Recommendation track document MUST be served at the "this version" URI. Alternatives will be made available through content negotiation.
2. Authors MAY provide non-normative alternatives (available at other URIs). See section 1.5 below for more information about links to these alternatives from the head of the document.

Note: Serving two formats at the "this version" URI is an assertion by W3C that the documents are equivalent for the purposes of conveying the requirements of the document. In practice, the Comm Team will not read each alternative to verify that this is the case. If the Communications Team learns of substantive discrepancies between normative alternatives, the W3C Head of Communications may request that the author no longer serve the alternative as normative.

5. Format requirements are satisfied

1. For reasons of backwards compatibility, at least one normative version of a document MUST validate as one of the following: HTML 2.0, HTML 3.2, HTML 4.x, or XHTML 1.0.
2. A normative alternative MUST use an XHTML-based format.

5.1 Style sheet requirements

1. The document MUST NOT have any style sheet errors.
2. Each document MUST include a link to the style sheet identified below that is appropriate for the document maturity level. The URI used to identify the style sheet MUST be absolute. Any internal style sheets are cascaded before this link; i.e., the internal style sheets MUST NOT override the W3C tech report styles.

   For a Working Draft:

   <link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-WD" />

   For a Candidate Recommendation:

   <link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-CR" />

   For a Proposed Recommendation:

   <link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-PR" />

   For a Recommendation:

   <link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-REC" />

   For a Proposed Edited Recommendation:

   <link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-PER" />

   For a Rescinded Recommendation:

   <link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-RSCND" />

   For a Working Group Note:

   <link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE" />

   For an Interest Group Note:

   <link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-IG-NOTE" />

   For a Coordination Group Note:

   <link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-CG-NOTE" />

   For a Member Submission:

   <link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-Member-SUBM" />

   For a Team Submission:

   <link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-Team-SUBM" />

3. Visual styles SHOULD NOT vary significantly among normative alternatives.

6. Accessibility requirements are satisfied

The document(s) MUST conform to the Web Content Accessibility Guidelines 1.0, Level A. The Document Contact MAY include a link to a completed WCAG 1.0 Checklist (5 May 1999 version) in the request to publish.

7. Document head is consistent with W3C conventions

The following information and markup MUST appear at the beginning of the body of the document, within <div class="head">. Editors SHOULD NOT include other information in this section.

1. Logo information:
   1. If a document on the Recommendation track, it MUST include a link to the W3C logo identified below. The URI used to identify the logo MUST be absolute.

      <a href="http://www.w3.org/">
           <img height="48" width="72" alt="W3C"
            src="http://www.w3.org/Icons/w3c_home" /></a>       

   2. If a Member or Team Submission, in addition to the W3C logo, use one of the following logos

      <a href="http://www.w3.org/Submission/">
           <img height="48" width="211" alt="W3C Member Submission"
            src="http://www.w3.org/Icons/member_subm" /></a>       

      <a href="http://www.w3.org/TeamSubmission/">
           <img height="48" width="211" alt="W3C Team Submission"
            src="http://www.w3.org/Icons/team_subm" /></a>       

2. The document's title MUST be in the title element and in an h1 element.
3. Technical report version information if there has been a previous Recommendation:
   1. If a Recommendation modified in place, see the Comm Team's policy regarding in-place modification of W3C Technical Reports.
   2. If a technical report with no changes that affect conformance to previous Recommendation then there MUST be a change to the edition number (e.g., "Second Edition") and no change to the revision number.
   3. If a technical report with changes that affect conformance to previous Recommendation but no new features, then there MUST be a change to the minor revision number (e.g., "Version 1.1").
   4. If a technical report with new features from previous Recommendation then there MUST be a change to the major revision number (e.g., "Version 2.0").
4. The document's status and date MUST be in an h2 element as follows.

   <h2>W3C status 14 August 2004</h2>
      

   Where the date follows the date syntax and status is one of: Working Draft, Candidate Recommendation, Proposed Recommendation, Proposed Edited Recommendation, Recommendation, Rescinded Recommendation,Working (or Interest or Coordination) Group Note, Team Submission, or Member Submission

   For example:

   <h2>W3C Working Draft 3 March 2000</h2>

   <h2>W3C Working Group Note 3 March 2000</h2>

   If this is a modified Recommendation that was modified in place or is a new edition, the document MUST include both the original publication date and the modification date. For example:

   <h2>W3C Recommendation 7 April 2004, edited in place 19 August
       2004</h2>

5. Document identifier information MUST be present in this order for Recommendation track documents:
   • This version URI
   • Latest version
   • Previous version (unless first public draft).
   Member and Team Submissions MUST include a "this version" link and the base URI MUST be different than http://www.w3.org/TR/. Member and Team Submissions SHOULD also include a latest version link.
6. The editors'/authors' names MUST be listed. Affiliations and email addresses are OPTIONAL ; email addresses are NOT RECOMMENDED. If the list of authors is very long (e.g., the entire Working Group), list the authors in the acknowledgments section, linked from the head of the document. Distinguish any contributors from authors in the acknowledgments section.
7. If a Recommendation, immediately after the editors/authors' names, there MUST be a link to an errata document made with the following markup:

   <p>Please refer to the <a href="http://www.w3.org/..."><strong>errata</strong></a> for this document, which may include some normative corrections.</p>

   See suggestions on errata page structure in the manual of style.

8. There MAY be links to any alternative (non-normative) formats or packages for the document. For instance:

   <p>This document is also available in these non-normative formats: <a href="WD-foo-20020101.html">single HTML file</a>, <a href="WD-foo-20020101.tgz">gzipped tar file of HTML</a>, and <a href="WD-foo-20020101.pdf">PDF</a>.</p>

9. If a Recommendation, there MUST be a link to a translations page. The RECOMMENDED markup is:

   See also <a href="http://www.w3.org/2003/03/Translations/byTechnology?technology=xhtml1"><strong>translations</strong></a>.

   See suggestions on translations in the manual of style.

10. Copyright
    • For a Recommendation track document or Team Submission, the copyright MUST use the following markup (fill in with the appropriate year, years, or year range).

      <p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright"> Copyright</a> &#xa9;2004 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>&#xae;</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p>

    • For a Member Submission, the document must include a link to the W3C document notice. The copyright may be held by the Submitters.

After this header information:

1. A horizontal rule (hr) MUST follow the copyright.
2. There MUST be an abstract, labeled with an h2 element with content "Abstract".
3. There MUST be a status section that follows the abstract, labeled with an h2 element with content "Status of this Document".
4. There SHOULD be a table of contents after the status section, labeled with an h2 element with content "Table of Contents".
5. Every heading in the document MUST have a target anchor (e.g., section 12.2.3 Anchors with the id attribute of the HTML 4 specification).

Glossary

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

Recommendation Track (Rec Track) document

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); Recommendation (REC); Proposed Edited Recommendation (PER); Rescinded Recommendation (RSCND); or Working Group, Interest Group, or Coordination Group Note (NOTE).

Technical report

One of: Member Submission (SUBM), Team Submission (SUBM), or a Recommendation Track Document.

Roles

Webmaster

a function performed by the W3C Communications Team.

Director

The W3C Director or authorized proxy (e.g., the COO).

Document Contact

For a Recommendation Track document, this is either the Team Contact of the group requesting publication, or the document editor. For Submissions, this is generally one of the Submitters. Consult the W3C Head of Communications if you are not sure who is the relevant Team contact.

About This Document

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

Many of these 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.

Per announcement to the Chairs on 20 Mar 2001, the Comm 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 Comm Team. During the 30-day period, editors may publish documents that conform to either the old or new pubrules.

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.

Previous Versions of Pubrules

This version of pubrules supersedes all previous versions. .

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.