[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 publish 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: * title * status, i.e. one of WD|CR|PR|REC|NOTE * date, i.e. title page date * author/editors * shortname * identifer of previous version, if any The shortname determines the identifier of the latest version in a series of documents as http://www.w3.org/TR/shortname. The identifer 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. 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/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, but 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.: * 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 (Note, public WD, CR, PR, REC). Explicit authorization from the Director is required by chapter 6 of the Process Document: + Is the requested status... 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 sufficient (i.e. required) 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 technical reports start life as either a NOTE or WD. yes: This is an update to an existing entry in the tech reports index. + Is the requested status... NOTE Explicit authorization from The Director is not required, but someone from the W3C management team (e.g. the relevant Domain Leader and/or the Communications Team Lead) 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 (e.g. the relevant Domain Leader and/or the Communications Team Lead) 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, or REC Carefully coordinate with The Director via the Communications Team Lead to synchronize with the relevant announcement to the W3C membership. For information about publications process and requirements based on document type, editors and staff contacts should consult: * How to Organize a Last Call Review * How to Organize a Candidate Recommendation Review * Starting Member review of a Proposed Recommendation * @@How to Organize a Recommendation in development@@ 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/split technical report like a first publication, but that is not how it has been handled in the past. 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 Apr 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: For a Candidate Recommendation: For a Proposed Recommendation: For a Recommendation: For a Note: Regarding the document head, editors/team contacts see guidelines on technical reports structure, including templates etc. In particular: 1. The following markup at the beginning of the head of the document:
2. The W3C logo must appear and must be referenced as follows: W3C 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 using four digits.

W3C status dd mmmm yyyy

for example

W3C Working Draft 03 March 2000

5. Version information is present in this order: o This version http://www.w3.org/TR/YYYY/status-shortname-YYYYMMDD (alternative representations for this version may appear) o Latest version http://www.w3.org/TR/shortname o Previous version (unless first public draft). 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):

Copyright ©2001 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

8. The following markup at the end of the head of the document:
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 spec) Roles Webmaster a function performed by the W3C communications team; as of March 2000, Hugo Haas 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's 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 publish 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: * Chapter 6 of the Process Document on W3C Technical Reports ---------------------------------------------------------------------------- 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.2 $ of $Date: 2001/01/25 21:23:09 $ by $Author: plehegar $