Logo for the Pubrules Checker Pubrules 5.6.0 — publication rules

About · Site map · Github · Help

↑ up to documentation

Publication rules for First Public Interest Group Note (“FPIG-NOTE”)

1. Normative Document Representation

  • § At least one normative representation must be available for requests that use the "This Version" URI. More than one normative representation may be delivered in response to such requests. A "This Version" URI must not be used to identify a non-normative representation.
  • § recursive All normative representations must validate as HTML5 with the following limitations:
    • Inline markup for MathML is permitted but should use a (fallback) alternative.
    • If the HTML5 validator issues content warnings, the publication request must include rationale why the warning is not problematic.
  • § Visual styles should not vary significantly among normative alternatives.

2. Document Metadata

  • § recursive Each document must include the following absolute URI to identify a style sheet for this maturity level: https://www.w3.org/StyleSheets/TR/2016/W3C-IG-NOTE

    Include this source code:
    <link rel="stylesheet" type="text/css" href="https://www.w3.org/StyleSheets/TR/2016/W3C-IG-NOTE"/>

  • § recursive Any internal style sheets must be cascaded before this link; i.e., the internal style sheets must not override the W3C tech report styles.
  • § recursive The viewport meta tag is required.

    Include this source code:
    <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">

  • § recursive The canonical link is required.

    Include this source code:
    <link rel="canonical" href="@@URL@@">

  • § The Working Group(s) id(s) must be listed in a data-deliverer attribute in the section "Status of This Document".

    Include this source code:
    <p data-deliverer="@@ID1@@ @@ID2@@,...">

3. Front Matter

  • § The front matter must appear at the beginning of the body of the document, within <div class="head">. There is one exception to that requirement: the hr element after the copyright may appear inside or after the div element. Editors should not include other information in this section.
  • § The document's title must be in the title element and in an h1 element. When calculating text equation, special transformations made to h1 are:
    1. Replace ':<br>' with ': '
    2. Replace '<br>' with ' - '
    3. Extract text from h1, and ignore HTML tags.
  • § Technical report version information, i.e., version and edition numbers.
    1. See the (non-normative) Version Management in W3C Technical Reports for more information.
  • § The document's status and date must be in an h2 element as follows (see also date syntax): 
    <h2>W3C Interest Group Note DD Month YYYY</h2>
  • § Document identifier information must be presented in a dl list, where each dt element marks up an identifier role ("This Version", "Latest Version", "Previous Version", etc.) and each dd element includes a link whose link text is the identifier.
  • § Document identifier information must be present in this order:
  • § The syntax of a “this version” URI must be https://www.w3.org/TR/YYYY/NOTE-shortname-YYYYMMDD/.
  • § The syntax of a “latest version” URI must be https://www.w3.org/TR/shortname/.
  • § The title page date and the date at the end of the "This Version" URI must match.
  • § The editors'/authors' names must be listed, with attribute data-editor-id="@@". Affiliations and email addresses are optional; email addresses are not recommended. If an editor/author is acknowledged in an earlier version of this document and the individual's affiliation has since changed, list the individual using the notation "<name>, <affiliation> (until DD Month YYYY)". If the list of authors is very long (e.g., the entire Working Group), identify the authors in the acknowledgments section, linked from the head of the document. Distinguish any contributors from authors in the acknowledgments section.
  • § Authors may provide links to alternative (non-normative) representations or packages for the document. For instance:

    <p>This document is also available in these non-normative formats: <a href="NOTE-shortname-20180101.html">single HTML file</a>, <a href="NOTE-shortname-20180101.tgz">gzipped tar file of HTML</a>.</p>

  • § It must include a public archived place to send comments to in the headers (<div class="head">) of the document. (GitHub repository issue links are expected to be of the form https://github.com/<USER_OR_ORG>/<REPO_NAME>/[issues|labels][/…].)
  • § A horizontal rule (hr) must follow the copyright.

5. Document Status Section

  • § There must be a status section that follows the abstract, labeled with an h2 element with content "Status of This Document". The Team maintains the status section of a document.
  • § It must begin with the following boilerplate text:

    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 W3C technical reports index at https://www.w3.org/TR/.

    Include this source code:
    <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="https://www.w3.org/TR/">W3C technical reports index</a> at https://www.w3.org/TR/.</em></p>
  • § All dates must have the form DD Month YYYY. A leading zero in the day is optional.
  • § If the document was published due to a W3C decision to stop work on this material, the status section should include that rationale.
  • § It should indicate the level of endorsement within the group for the material, set expectations that the group has completed work on the topics covered by the document, and set expectations about the group's commitment to respond to comments about the document.
  • § It must include at least one customized paragraph. This section should include the title page date (i.e., the one next to the maturity level at the top of the document). These paragraphs should explain the publication context, including rationale and relationships to other work. See examples and more discussion in the Manual of Style.
  • § It must set expectations about the (in)stability of the document. The recommended text (see also ideas for status sections regarding the stability of group notes) is:

    Publication as an Interest Group Note does not imply endorsement by the W3C Membership.

    Include this source code:
    <p>Publication as an Interest Group Note does not imply endorsement by the W3C Membership.</p>
  • § It must include following sentence in the "Status Of This Document":
    This is a draft document and may be updated, replaced or obsoleted by other documents at any time.
  • § It must include this text related to disclosure requirements (with a link to the disclosure section of the group charter).

    The disclosure obligations of the Participants of this group are described in the charter.

    Include this source code:
    <p>The disclosure obligations of the Participants of this group are described in the <a href="@@URI to disclosure section of charter@@">charter</a>. </p>
  • § It must not indicate the number of known disclosures at the time of publication.
  • § The document must include the following boilerplate text in the status section to identify the governing process:

    This document is governed by the 15 September 2020 W3C Process Document.

    Include this source code:
    <p>This document is governed by the <a id="w3c_process_revision" href="https://www.w3.org/2020/Process-20200915/">15 September 2020 W3C Process Document</a>. </p>
  • § There should be a table of contents after the status section, labeled with an h2 element with content "Table of Contents".
  • § The table of content must be inside a navigation element (nav).

    Include this source code:
    <nav id="toc"><h2>Table of Contents</h2>

7. Document Body

  • § recursive Every marked-up section and subsection of the document must have a target anchor. A section is identified by a heading element (h1-h6). The anchor may be specified using an id (or name if an a element is used) attribute on any of the following: the heading element itself, the parent div or section element of the heading element (where the heading element is the first child of the div or section), a descendant of the heading element, or an a immediately preceding the heading element.
  • § recursive The document must not have any style sheet errors.
  • § recursive All proposed XML namespaces created by the publication of the document must follow URIs for W3C Namespaces .
  • § The document(s) must conform to the Web Content Accessibility Guidelines 2.1, Level AA. Note: You may wish to consult the customizable quick reference to Web Content Accessibility Guidelines 2.1.
  • § The document must include the script fixup.js.

    Include this source code:
    <script src="//www.w3.org/scripts/TR/2016/fixup.js" type="application/javascript"></script>

8. Compound Documents

  • § If the document is compound (i.e., if it consists of more than one file), all the files must be under a directory /TR/YYYY/NOTE-shortname-YYYYMMDD/. Exceptions are resources under these paths:
    1. https://www.w3.org/StyleSheets/
    2. https://www.w3.org/scripts/
  • § The main page should be called Overview.html.
  • § All other files must be reachable by links from the document.