W3C Technical Reports | Guide | Manual of Style

Publication Rules

This is the checklist used by the W3C Webmaster for maintaining the W3C technical reports index. Editors and Team contacts should consult the W3C Manual of Style 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.

These are the formal publication rules; if you'd like to discuss spec production informally among your peers, and to get the latest tips and techniques, try the spec-prod mailing list (archive).

Contents:


1. Rules

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.

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.

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

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

The Webmaster must have confirmation from the Team contact that the status section includes the following information:

  1. The document maturity level (Note, Working Draft, Candidate Recommendation, Proposed Recommendation, or Recommendation).
  2. An email address allowing public and Member comments. The mailing list must be archived, and the list must have been created before the document is published.
  3. The name of the W3C Activity that produced the document linked to the Activity statement.
  4. A link to the list of W3C technical reports: "A list of current W3C Recommendations and other technical reports can be found at http://www.w3.org/TR"
  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.)
  6. If a Working Draft in Last Call, Candidate Recommendation, or a Proposed Recommendation, the deadline for review, taking the form DD Month YYYY.
  7. If a Working Draft, whether the document is in "Last Call" and the deadline for comments (e.g., "This document is in the Last Call review period, which ends on 5 June 2002.")
  8. If a Candidate Recommendation, Proposed Recommendation, or Recommendation, a link to the interoperability or implementation report
  9. When a Recommendation is revised, the relationship between the original document, including its date, and the revised version.
  10. 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 and the publication date.

The status section may also include:

  1. If a Recommendation, a link to an errata page; see suggestions on errata page structure in the manual of style.
  2. If a Recommendation, a link to a translations page; see suggestions on translations in the manual of style.

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

1.4. Do all XML namespaces follow established conventions?

The Webmaster must have confirmation from the Team contact that all XML namespaces created by the publication of the document follow the W3C XML namespace conventions (announced to the Chairs 26 October 1999).

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

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 the specification

  1. Normative versions of a specification 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 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 specification. In practice, the Comm Team will not read each alternative to verify that this is the case. If there 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 the specification 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 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" />
  3. 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. 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. 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.

  8. 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, a link to a translations page. For example:

    See also <a href="http://www.w3.org..."><strong>translations</strong></a>.

    See suggestions on translations in the manual of style.

  10. 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/"><acronym lang="fr" title="Institut National de Recherche en Informatique et Automatique">INRIA</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-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/"><acronym xml:lang="fr" lang="fr" title="Institut National de Recherche en Informatique et Automatique">INRIA</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-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>

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


2. Tools


3. Roles

Webmaster
a function performed by the W3C Communications Team; as of April 2001, Henri Fallon 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. 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:

Previous Versions of PubRules:

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.


Janet Daly, W3C Communications Lead, 3 April 2000
with contributions from Ian Jacobs, Dan Connolly, Chris Lilley, Hugo Haas, Dominique Hazaël-Massieux et. al.
Created 3 Feb 2000.
$Id: 20020925-pubrules.html,v 1.1 2018/01/25 15:47:16 plehegar Exp $