W3C Technical Reports | Guide

Publication Rules

This is the checklist used by the W3C Webmaster for maintaining the W3C technical reports index. Editors and Team contacts should consult How to Write a W3C Technical Report for detailed guidance. 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.

The Webmaster starts by examining the publication request to find the information that will be used to update the tech reports index:

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

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 tech reports index and updating the latest version to agree with this version.

The Webmaster has created a Pubrules Checker; we recommend that Working Groups use this tool to check their documents for conform to Publication Rules.

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

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.

2. Is this publication authorized?

The form of authorization required varies with the status of the document, etc.:

For information about publications process and requirements based on document type, editors and Team contacts should consult:

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

3. Is the Status of This Document section novel and complete? Do all XML namespaces follow established conventions?

The Webmaster must have confirmation from the Team contact that:

  1. The status section is novel and complete per the guidelines (per April 1999 Chairs meeting)

    In particular, the status section must contain a customized paragraph that has not been copied from another document. This section should include the title page date of the document.

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

4. Are there any broken links, internal to the document or otherwise?

  1. If the technical report is a compound document (i.e. if it consists of more than one file), all the files must be under a directory called TR/YYYY/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.

5. Is the document consistent with W3C Technical Reports style?

Regarding the document as a whole:

  1. The main page and all subordinate pages must conform to W3C HTML Recommendations. Use the W3C HTML/XML validator.

    (Alternative representations such as plain text, PostScript, etc. are optional.)

  2. The document must conform to the Web Content Accessibility Guidelines 1.0, Level A. Use the WCAG 1.0 Checklist (5 May 1999 version).
  3. The document must not have any style sheet errors. Use the CSS validator.
  4. There must be an absolute link to the appropriate technical report style sheet as follows. 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 Note:
    <link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-NOTE" />

Regarding the document head, editors and Team contacts please see guidelines on technical reports structure, including templates, sample, etc. In particular:

  1. The following markup at the beginning of the head of the document:
    <div class="head">
  2. The W3C logo must appear and must be referenced as follows:
    <a href="http://www.w3.org/">
         <img height="48" width="72" alt="W3C"
          src="http://www.w3.org/Icons/w3c_home" /></a>

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

  5. Version information is present in this order:
  6. The editors'/authors' names must be listed. Affiliations and email addresses are optional.
  7. 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-20000612#Copyright"> Copyright</a> &copy;2002 <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>&reg;</sup> (<a href="http://www.lcs.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>, <a href="http://www.inria.fr/"><abbr lang="fr" title="Institut National de Recherche en Informatique et Automatique">INRIA</abbr></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#W3C_Trademarks">trademark</a>, <a href="http://www.w3.org/Consortium/Legal/copyright-documents-19990405">document use</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-software-19980720">software licensing</a> rules apply.</p>

    For XHTML:

    <p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Copyright"> Copyright</a> &copy;2002 <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>&reg;</sup> (<a href="http://www.lcs.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>, <a href="http://www.inria.fr/"><abbr xml:lang="fr" lang="fr" title="Institut National de Recherche en Informatique et Automatique">INRIA</abbr></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#W3C_Trademarks">trademark</a>, <a href="http://www.w3.org/Consortium/Legal/copyright-documents-19990405">document use</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-software-19980720">software licensing</a> rules apply.</p>

  8. The following markup at the end of the head of the document:
    </div>
  9. A horizontal rule (hr) must follow the copyright.
  10. An abstract should briefly describe the document. The word "Abstract" must marked up with an h2 element.
  11. The status section must follow. The words "Status of this Document" are marked up with an h2 element.
  12. 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)

Roles

Webmaster
a function performed by the W3C Communications Team; as of November 2000, Dominique Hazaël-Massieux 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.

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.

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

Related:

Previous Versions of PubRules:

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

20020226: Modified to include link to the Pubrules Checker.


Janet Daly, W3C Communications Lead, 3 April 2000
with contributions from Ian Jacobs, Dan Connolly, Chris, Hugo, et. al.
Created 3 Feb 2000.
$Revision: 1.1 $ of $Date: 2018/01/25 15:47:16 $ by $Author: plehegar $