Publication Rules

This version has been superseded. See the latest version.

This version

http://www.w3.org/2003/12/01-pubrules

Latest version

http://www.w3.org/Guide/pubrules

This document explains the requirements for documents on the Recommendation Track.

1. Document requirements
2. Glossary
3. About this Document

For information about process requirements (how to request a transition, how to request publication, etc.), see How to Organize a Recommendation Track Transition.

Nearby: Recommendation Track documents | W3C Recommendation Track Process | How to Organize a Recommendation Track Transition | Member Submissions | Team Submissions | W3C Editors' Home Page | Manual of Style

Status of this Document

This document is being prepared as part of the Patent Policy implementation. It is being revised along with How to Organize a Rec Track Transition the Process Document, for review by the Team and Advisory Board.

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.

Start here

This is the checklist used by the W3C Webmaster for maintaining:

1. the W3C technical reports index
2. the Member Submissions index
3. the Team Submissions index

These are the formal publication rules. 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 detailed guidance.

Nearby tools: Pubrules Checker | Sample Recommendation cover page | TR document template

1. Document requirements

The following requirements apply to the document itself. They are divided up into requirements that the Webmaster must verify before publishing, and those that the Document Contact must verify. Please consult the Manual of Style for more suggestions about document structure.

1.1 Requirements that the Webmaster must verify

The Webmaster MUST verify that these requirements have been satisfied in order to be able to publish. This implies that the Document Contact MUST also ensure that these have been satisfied.

1. The Webmaster MUST verify that the document satisfies status section requirements.
2. The Webmaster MUST verify that the document satisfies namespaces requirements.
3. The Webmaster MUST verify that the document has no broken links to resources at w3.org.
4. The Webmaster MUST verify that the document is valid.
5. The Webmaster MUST verify that the head of the document satisfies W3C Technical Report style requirements.

In particular:

• For all Last Call Working Drafts, Proposed Recommendations, and Proposed Edited Recommendations, the Webmaster MUST verify that the status section includes the end date of the review period.
• For all Candidate Recommendations, the Webmaster MUST verify that the status section includes both of the following:
  1. A minimal duration (before which the group will not request the next transition).
  2. An estimated date by which time the Working Group expects to have sufficient implementation experience.

1.2 Requirements that the Document Contact must verify

The Document Contact MUST ensure that the follow requirements have been satisfied. By virtue of sending a publication request, the Document Contact asserts that these requirements have been sastified. Unless the Webmaster is required to verify an assertion, the Webmaster MUST NOT refuse to publish even if the assertion proves false.

For some of the subsections below, we RECOMMEND that the Document Contact include information in the request to publish to help others confirm the assertion, if necessary.

1.2.1 Is the "Status of This Document" section novel and complete?

The status section MUST satisfy the requirements listed in the following subsections.

The Team maintains the status section of a document.

Note: 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. Please refer to the Manual of Style for more suggestions on status sections.

1.2.1.1 For all technical reports, the status section must satisfy these requirements

1. It MUST include the maturity level.
2. All dates MUST have the form DD Month YYYY.

1.2.1.2 For all Recommendation track documents, the status section must satisfy these requirements

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.
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).
8. It MUST include a link to a public patent disclosure page, even if there are no known disclosures at the time of publication. See the SMIL 2.0 Patent disclosure page as an example. (Suggestion: adding rel="disclosure" or calling the disclosures file "Disclosures.html" helps the pubrules checker find this link.) The status section MUST NOT indicate the number of known disclosures at the time of publication.
9. The status section MUST indicate under which patent policy the document has been produced. For all groups and all Recommendation track documents, however, the status section MUST include a disclosure request that conforms to the requirements of the W3C Patent Policy (20 May 2003 version). The RECOMMENDED text is:

   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-20030520.html#sec-Disclosure">section 6 of the W3C Patent Policy</a>.

1.2.1.3 For all Working Drafts, the status section should satisfy these requirements

1. It SHOULD indicate how much consensus there is within W3C for the Working Draft (e.g., no consensus or consensus among the Working Group participants.
2. It SHOULD indicate whether the Working Group expects to advance this Working Draft to Recommendation.

1.2.1.4 For all First Public Working Drafts, the status section must satisfy these requirements

1. It MUST indicate that this is a First Public Working Draft.
2. It MUST refer to section 4 of the W3C Patent Policy. The RECOMMENDED text is:

   Per <a href="http://www.w3.org/Consortium/Patent-Policy-20030520.html#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.

An exclusion reference draft should indicate its relation to the First Public Working Draft and should reiterate the time remaining for exclusions.

1.2.1.5 For all Last Call Working Drafts, the status section must satisfy these requirements

1. It MUST indicate that this is a Last Call Working Draft.

1.2.1.6 For all Candidate Recommendations, the status section must satisfy these requirements

1. It MUST include a link to a preliminary interoperability or implementation report, or a statement that no such report exists.

1.2.1.7 For all Proposed Recommendations, the status section must satisfy these requirements

1. It MUST include a link to an interoperability or implementation report.
2. 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.2.1.8 For all Recommendations, the status section must satisfy these requirements

1. It MUST 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 only an editorial revision).

1.2.1.9 For all Proposed Edited Recommendations, the status section must satisfy these requirements

1. It MUST include or link to the list of changes that may affect conformance.

1.2.1.10 For all Rescinded Recommendations, the status section must satisfy these requirements

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

1.2.1.11 For all Working (Interest, Coordination) Group Notes, the status section should satisfy these requirements

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

1.2.1.12 For all Member and Team Submissions, the status section must satisfy these requirements

1. It MUST inclue 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. It MUST explain why W3C has published the document (result of ack'd Member Submission; decision to publish Team Submission), that these are not W3C Recommendation track documents, and that publication does not imply endorsement by W3C, and that publication does not imply that any further action will be taken by W3C.

1.2.2 Do 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).

1.2.3 Are there any 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.

The Document Contact MAY include a URI to the W3C Link Checker in the request to publish.

1.2.4 Is the document consistent with W3C technical reports requirements?

The Document Contact MAY include a link to the pubrules checker.

1.2.4.1 Normative versions of a Recommendation track document

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 5.2.5 for 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.

1.2.4.2 Format requirements

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.

The Document Contact MAY include a URI to the W3C HTML/XML validator in the request to publish.

1.2.4.3 Style sheet requirements

1. The document MUST NOT have any style sheet errors. The Document Contact MAY include a URI to the CSS validator in the request to publish.
2. Each document MUST include one of the following links, referring to it with either an absolute or relative URI refererence (with server-side redirect). The URI reference MUST NOT start with ".." due to the difference between this version and latest version URIs. 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.

1.2.4.4 Accessibility requirements

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.

1.2.5. Is the head of the document consistent with W3C technical reports style?

The following markup MUST appear at the beginning of the body of the document, within <div class="head">.

1. Logo information:
   1. If a document on the Recommendation track, the W3C logo MUST appear and MUST either be referenced with an absolute link or a relative link (not starting with ".." due to difference between this version and latest version locations) used with a server-side redirect. For an absolute link, use:

      <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="72" alt="W3C Member Submission"
            src="http://www.w3.org/Icons/member_subm" /></a>        

      <a href="http://www.w3.org/2003/06/TeamSubmission/">
           <img height="48" width="72" 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. Please consult the Manual of Style for suggestions about the document title.
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") and no change to the edition number.
   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") and no change to the minor revision number or edition number.
4. The document's status and date MUST be in an h2 element as follows. The date MUST be in Day Month Year order with the month spelled out in full and the year in four digits.

   <h2>W3C status dd Month yyyy</h2>
       

   for example:

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

   <h2>W3C Working Group Note 03 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.

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=REC-xml-names"><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 year or a year range).

      For HTML:

      <p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright"> Copyright</a> &#xa9;2003 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>&#xae;</sup> (<a href="http://www.lcs.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>, <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-software">software licensing</a> rules apply.</p>

      For XHTML:

      <p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright"> Copyright</a> &#xa9; 2003 <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>, <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-software">software licensing</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).

2. Glossary

2.1 Maturity levels

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

Recommendation Track (Rec Track) document

One of: First Public Working Draft (FPWD), Working Draft (WD), Candidate Recommendation (CR), Proposed Recommendation (PR), Recommendation (REC), Proposed Edited Recommendation (PER), Rescinded Recommendation (RSCND), or Working Group (or Interest Group or Coordination Group) Note (NOTE).

Technical report

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

2.2 Roles

Webmaster

a function performed by the W3C Communications Team. As of July 2003, Vivien Lacourba generally does this work, and Janet Daly, the W3C Head of Communications, provides management support.

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 the Team contact. Consult the W3C Head of Communications if you're not sure who is the relevant Team contact.

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

Per announcement to the Chairs on 20 Mar 2001, the Comm Team will announce all substantive changes to this document to the chairs@w3.org mailing list. [Change this to "the 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.

3.1 Previous Versions of Pubrules:

20020226: Modified to include link to the Pubrules Checker.

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

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

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

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

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