| Member Guide

Nearby: Recommendation Track documents | Member Submissions | Team Submissions | Manual of Style

Publication Rules

Note: As of 10 March 2004, this document is superseded by the 2 February 2004 Pubrules. Editors are encouraged to move to the newer pubrules sooner if possible.

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'd like to discuss technical report production informally among your peers, and get the latest tips and techniques, try the spec-prod mailing list (archive). Editors and Team contacts should consult the W3C Manual of Style for detailed guidance.

Where to send publication requests

Ordinary Working Draft publication requests should be sent to webreq@w3.org (archive) and w3t-comm@w3.org (archive). If you want a Member-visible archive of your request and its disposition, you may copy w3c-archive.

For other document maturity levels, information about what to include in a publication request and where to send the request is available in How to Organize a Recommendation Track Transition.

For information about requesting publication of a Member Submission, consult How to make or withdraw a Member Submission request. The Director approves requests from the Team to publish a Team Submission.

Terminology

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

Recommendation Track (Rec Track) document

One of: 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.

Contents

• 1. Rules
  • 1.1. Has the title page date come to pass?
  • 1.2. Is this publication authorized?
  • 1.3. Is the "Status of This Document" section novel and complete?
  • 1.4. Do all XML namespaces follow established conventions?
  • 1.5. Are there any broken links, internal to the document or otherwise?
  • 1.6. Is the document consistent with W3C technical reports style?
  • 1.7. Is the head of the document consistent with W3C technical reports style?
• 2. Tools (pubrules checker, templates, sample Recommendation)
• 3. Roles (Webmaster, Team Contact, etc.)
• 4. About This Document

1. Rules

The Webmaster starts by examining the publication request to find the information that will be used to update the technical reports index, the Member Submissions index, or the Team Submissions index.

• title
• maturity level label, i.e. one of:
  • To Recommendation: WD|CR|PR|REC
  • Working Group Note: NOTE
  • Proposed Edited Recommendation: PER
  • Rescinded Recommendation: RSCND
  • Member and Team Submissions: SUBM
• date, i.e. title page date
• author/editors
• shortname
• identifier of previous version, if any.

For Recommendation track documents, the shortname determines the identifier of the latest version in a series of documents as http://www.w3.org/TR/shortname. The identifier of the particular publication is determined by the shortname, the status, and the date: http://www.w3.org/TR/YYYY/status-shortname-YYYYMMDD.

Member and Team Submission URIs are constructed similarly, but those documents are not published under http://www.w3.org/TR/.

Upon receiving a request to publish a technical report, the Webmaster shall make a best effort to check these constraints and, provided they are met, publish the document by linking it from the appropriate index and updating the latest version to agree with this version.

If any constraint is not met, the Webmaster shall decline the publication request, detailing which of the following constraints were not met. See below regarding exceptions to this policy.

1.1. Has the title page date come to pass?

Find the date for the title page from the publication request. It must not be in the future; if it is, don't publish it yet. If it's too far in the past then abort and try to get a document with a newer title page date. The editor must not change the document after the title page date.

Note to Editors and Team contacts: If you want to synchronize document's title page date with the actual date the document becomes available in the tech reports index (or with anything else), the editor must negotiate the date with the Communications Team to ensure their schedule permits. Five days advance notice is appreciated; more notice is even better, and experience shows that less than five days is risky.

1.2. Is this publication authorized?

The form of authorization required varies with the status of the document.

1.2.1 For Recommendation track documents

Is there a previous version?

no:

This is the first publication in this series, i.e. the first appearance of this title on the tech reports index within a particular status. Explicit authorization from the Director is required by chapter 7 of the Process Document:

• Is the maturity level label:

  Note

  written record of Director's approval of the title, and shortname (in addition to Team contact's confirmation of the approval "Status of This Document" text) is necessary and sufficient authorization.

  WD

  written record of Director's approval of the title, and shortname (in addition to Team contact's confirmation of the approval "Status of This Document" text) is required; the status section must include a link to the relevant Activity statement to show evidence of W3C resources dedicated to the maintenance of this document.

  other

  Abort. All W3C Recommendation track document s start life as either a Note or Working Draft.

yes:

This is an update to an existing entry in the tech reports index.

• Is the maturity level label:

  Note

  Explicit authorization from the Director is not required, but someone from the W3C management team (usually the the relevant Domain Leader) should be aware of the status of the document. Team contact's confirmation of the approval "Status of This Document" text is required.

  WD

  Explicit authorization from the Director is not required, but someone from the W3C management team (usually the the relevant Domain Leader) should be aware of the status of the document. A link to the relevant Activity statement is required to show evidence of W3C resources dedicated to the maintenance of this document. Team contact's confirmation of the approval of the "Status of This Document" text is required.

  CR|PR|REC|PER|RSCND

  Explicit authorization from the Director is required. Refer to How to Organize a Recommendation Track Transition for requirements related to a request to advance for one of these maturity levels. See the Comm Team's policy regarding in-place modification of W3C Technical Reports.

For more information about publications process and requirements based on document type, editors and Team contacts should consult How to Organize a Recommendation Track Transition.

Note: in the past, shortnames have been changed between versions, and documents have been split and merged between versions. A conservative approach is to treat a merged or split document like a first publication.

1.2.2 For Member and Team Submissions

Publication of any Member or Team Submission, even for minor revisions, requires explicit authorization from the Director.

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

The Webmaster must have confirmation from the contact for this document (e.g., Team contact) that the status section of the document includes the following information. All information is required unless indicated as "Optional."

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.

1.3.1 All technical reports

1. The document maturity level.
2. All dates must have the form DD Month YYYY.
3. A status section containing all of the following:
   1. The following boilerplate:

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

   2. At least one customized paragraph that has not been copied from another document. This section should include the title page date of the document. Perhaps the most important information in any status section is the publication context, including rationale and relationships to other work.
   3. If it is not a Recommendation, a paragraph setting expectations about the stability of the document. We recommend:

      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.

Please refer to the Manual of Style for more suggestions on status sections.

1.3.2 All Recommendation track documents

1. The name of the W3C Activity that produced the document linked to the Activity statement.
2. A mailing list for public and Member comments. The mailing list must be archived, and the list must have been created before the document is published.
3. A link to the Recommendation track index; see the boilerplate text.
4. A link to changes since the previous transition (e.g., a list of changes or a diff document or both).
5. 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.) Do not indicate the number of known disclosures in the document status section.

1.3.3 Working Drafts

1. The status section must set expectations about the stability of the work (e.g., that it MAY be superseded, obsoleted, or dropped at any time, and that it should not be cited as other than a work in progress) and 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. If the Working Group does not expect to advance this Working Draft to Recommendation, the status section should say so.
3. If a Working Draft in Last Call:
   1. An indication of last call.
   2. The review end date.
   For example: "This document is in the Last Call review period, which ends on 5 June 2002."

1.3.4 Candidate Recommendations

1. Estimated date when WG expects to have sufficient implementation experience.
2. A link to a preliminary interoperability or implementation report.
3. Optional: A date or time interval no earlier than which the WG will request to advance to PR.

1.3.5 Proposed Recommendations

1. The review end date.
2. A link to an interoperability or implementation report.
3. 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.3.6 Recommendations

1. A link to an interoperability or implementation report.
2. The status section 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).
3. A link to an errata page; see suggestions on errata page structure in the manual of style.
4. A link to a translations page; see suggestions on translations in the manual of style.

1.3.7 Proposed Edited Recommendations

1. The status section must include or link to the list of changes that may affect conformance.

1.3.8 Rescinded Recommendations

1. The status section must include or link to rationale for the decision to rescind the Recommendation.
2. The status section should direct readers to alternative technologies.

1.3.9 Working (Interest, Coordination) Group Note

1. The status section 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.3.10 Member and Team Submissions

1. A link to the page listing all Member Submissions or Team Submissions.
2. For Team Submissions, a mailing list for comments. The mailing list must be archived, and the list must have been created before the document is published.
3. The status sections of these documents must explain why W3C has published them (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.4. Do all XML namespaces follow established conventions?

The Team contact must signal to the Webmaster that all proposed XML namespaces created by the publication of the document follow the W3C XML namespace conventions (announced to the Chairs 26 October 1999). The Webmaster confirms that the proposed namespaces conform to that policy.

1.5. 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 main page.
2. The document should have no broken links; it must not have any broken internal links and must not have any broken links to w3.org resources. Use the W3C Link Checker.

1.6. Is the document consistent with W3C technical reports requirements?

You may also consult the Manual of Style for more suggestions about document structure.

1.6.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 1.7 of pubrules 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 Comm Team learns of substantive discrepancies between normative alternatives, the Comm Team may request that the author no longer serve the alternative as normative.

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

Note: Validate your documents with the W3C HTML/XML validator. W3C serve HTML and XHTML 1.0 documents as 'text/html'.

1.6.3 Style sheet requirements

1. The document must not have any style sheet errors. Use the CSS validator.
2. There may either be an absolute link to the following TR style sheets or a relative link (not starting with ".." due to difference between this version and latest version locations) used with a server-side redirect.
3. 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" />

4. Visual styles should not vary significantly among normative alternatives.

1.6.4 Accessibility requirements

1. The document must conform to the Web Content Accessibility Guidelines 1.0, Level A. Use the WCAG 1.0 Checklist (5 May 1999 version).

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

The following requirements pertain to the document head:

1. The following markup at the beginning of the head of the document:

   <div class="head">

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

3. The document's title is in the title element and an h1 element.
4. 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.
5. 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.

6. Document identifier information is present in this order for Recommendation track documents:
   • This version http://www.w3.org/TR/YYYY/status-shortname-YYYYMMDD
     
   • Latest version http://www.w3.org/TR/shortname
   • Previous version (unless first public draft).
   For Member and Team Submissions, the only requirement is for 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.
7. 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.
8. If a Recommendation, immediately after the editors/authors' names, the link to an errata document must be 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.

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

10. If a Recommendation, a link to a translations page. Recommended:

    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.

11. 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;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>, <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; 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>, <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.
12. The following markup at the end of the head of the document:

    </div>

13. A horizontal rule (hr) must follow the copyright.
14. An abstract should briefly describe the document. The word "Abstract" must marked up with an h2 element.
15. The status section must follow. The words "Status of This Document" are marked up with an h2 element.
16. A table of contents should follow; whether it does or not, every heading must be marked up as a target anchor (e.g., section 12.2.3 Anchors with the id attribute of the HTML 4 specification)

Please consult the Manual of Style for suggestions about the document title.

2. Tools

• Pubrules Checker: use this tool to check your documents for conformance to Publication Rules.
• Sample Recommendation cover page
• TR document template

3. Roles

Webmaster

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

Director

TimBL or two members of the W3C Management team acting in his stead

Team Contact

Each Working Group has one. The corresponding Domain Lead can serve as Team contact if necessary. Each publication that is not by a Working Group (e.g., Submissions) has one. Consult the W3C Communications Team Lead if you're not sure who is the relevant Team contact.

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

Exceptions to these rules may be authorized by the Comm Team Lead or the Director.

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.

The key words must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this document are to be interpreted as described in RFC 2119.

Related:

• W3C Recommendation Track Process

Previous Versions of Pubrules:

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

20010719: Modified to reflect links to 20010719 version of Process Document.

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.