Pubrules/Rules

From W3C Wiki

Document Requirements

The Document Contact MUST verify that the requirements in this section (listed in "document order") have been satisfied before requesting publication. How to Organize a Recommendation Track Transition explains the remainder of the publication process.

See the [http:/www.w3.org/wiki/#sample-template sample below] that has been generated by the [http:/www.w3.org/wiki/#checker parameters you have chosen] in the form at the top of this document, summarized here:

1. Normative Document Representation

  1. OK normativeVersionTest 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.
  2. OK valideHTMLTest recursive All normative representations MUST validate as one of the following: HTML 4.x, or some version of XHTML or XHTML+RDFa that is a W3C Recommendation. HTML5 is also permitted with the following limitations:
    • HTML5 is not yet permitted for Recommendations.
    • Inline markup for SVG 1.1 or MathML 2.0 is permitted but only with a (fallback) alternative.
    • If the HTML5 validator issues content warnings, the publication request must include rationale why the warning is not problematic.Note: Please consider how your content will render in browsers that do not support HTML5.
  3. NOT_OK Visual styles SHOULD NOT vary significantly among normative alternatives.

Note: Serving two representations 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 Communications Team learns of substantive discrepancies between normative alternatives, the W3C Head of Communications may request that the author no longer serve the alternative as normative.

2. Document Metadata

  1. OK goodStylesheetTest recursive Each document MUST include the following absolute URI to identify a style sheet for this maturity level: [cssuri when doc:wd-tr] http://www.w3.org/StyleSheets/TR/W3C-WD[cssuri when doc:cr-tr] http://www.w3.org/StyleSheets/TR/W3C-CR[cssuri when doc:pr-tr] http://www.w3.org/StyleSheets/TR/W3C-PR[cssuri when doc:rec-tr] http://www.w3.org/StyleSheets/TR/W3C-REC[cssuri when doc:per-tr] http://www.w3.org/StyleSheets/TR/W3C-PER[cssuri when doc:rescind-tr] http://www.w3.org/StyleSheets/TR/W3C-RSCND[cssuri when doc:wg-note-tr|fpwg-note-tr] http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE[cssuri when doc:ig-note-tr|fpig-note-tr] http://www.w3.org/StyleSheets/TR/W3C-IG-NOTE[cssuri when doc:cg-note-tr] http://www.w3.org/StyleSheets/TR/W3C-CG-NOTE[cssuri when doc:mem-subm] http://www.w3.org/StyleSheets/TR/W3C-Member-SUBM[cssuri when doc:team-subm] http://www.w3.org/StyleSheets/TR/W3C-Team-SUBM[cssuri when doc:xgr] http://www.w3.org/StyleSheets/TR/W3C-XGRInclude this source code:
    <link rel="stylesheet" type="text/css" href="[cssuri when doc:wd-tr] http://www.w3.org/StyleSheets/TR/W3C-WD[cssuri when doc:cr-tr] http://www.w3.org/StyleSheets/TR/W3C-CR[cssuri when doc:pr-tr] http://www.w3.org/StyleSheets/TR/W3C-PR[cssuri when doc:rec-tr] http://www.w3.org/StyleSheets/TR/W3C-REC[cssuri when doc:per-tr] http://www.w3.org/StyleSheets/TR/W3C-PER[cssuri when doc:rescind-tr] http://www.w3.org/StyleSheets/TR/W3C-RSCND[cssuri when doc:wg-note-tr|fpwg-note-tr] http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE[cssuri when doc:ig-note-tr|fpig-note-tr] http://www.w3.org/StyleSheets/TR/W3C-IG-NOTE[cssuri when doc:cg-note-tr] http://www.w3.org/StyleSheets/TR/W3C-CG-NOTE[cssuri when doc:mem-subm] http://www.w3.org/StyleSheets/TR/W3C-Member-SUBM[cssuri when doc:team-subm] http://www.w3.org/StyleSheets/TR/W3C-Team-SUBM[cssuri when doc:xgr] http://www.w3.org/StyleSheets/TR/W3C-XGR"/>
  2. OK BUT imperfectely checked: lastStylesheetTest 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.

See also Style Guidelines for Group-Internal Drafts.

3. Front Matter

  1. OK, but could be modified based on metadata gathering needs. divClassHeadTest 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.

Guideline: be nice to readers by not overloading the top of the document.

Logos

  1. OK logoTest The document MUST include a link to the W3C logo identified below. The URI used to identify the logo MUST be absolute.
  2. OK [submlogo when doc:mem-subm] logoTest In addition to the W3C logo, use this logo:
  3. OK [submlogo when doc:team-subm] logoTest In addition to the W3C logo, use this logo:
  4. OK [xgrlogo when doc:xgr] logoTest In addition to the W3C logo, use this logo:

Title, Date, Maturity Level

  1. OK titleTest The document's title MUST be in the title element and in an h1 element.
  2. OK Technical report version information, i.e., version and edition numbers.
    1. [rec-in-place when doc:rec-tr] If a Recommendation modified in place, see the Comm Team's policy regarding in-place modification of W3C Technical Reports, otherwise
    2. See the (non-normative) Version Management in W3C Technical Reports for more information
  3. OK dateTitleH2Test The document's status and date MUST be in an h2 element as follows (see also [http:/www.w3.org/wiki/#date date syntax]): <h2>W3C STATUS 14 August YYYY</h2>
    [rec-new-edition when doc:rec-tr] 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. For example: <h2>W3C Recommendation 7 April 2004,
edited in place 19 August2004</h2>

Document Identifiers

  1. OK docIDFormat 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.
  2. OK docIDOrder Document identifier information MUST be present in this order:
    • This version URI.
    • Latest version URI(s). [versioninfoxref when doc:tr] See also the (non-normative) Version Management in W3C Technical Reports for information about "latest version" URI and version management.
    • [prevversionuri when doc:ord-wd-tr|lc-wd-tr|cr-tr|pr-tr|per-tr|rec-tr|wg-note-tr|ig-note-tr|cg-note-tr] Previous version URI
    • [prevversionuri when doc:rescind-tr] "Rescinds this Recommendation" URI[prevversionuri when doc:fpwd-wd-tr|fpwdlc-wd-tr|fpwg-note-tr] Note: Because this is a first draft, there SHOULD NOT be a Previous version URI. Use the status section to identify the relationship(s) to previous work (e.g., previous Recommendations). In some cases (e.g., mere change of short name or when a monolithic specification has been split into multiple parts) a Previous version URI MAY appear. Ask the Comm Team if you have questions.
  3. OK docIDThisVersion The syntax of a "This Version" URI [thisverreq when doc:tr|subm] MUST [thisverreq when doc:xgr] SHOULD be [thisversionsyntax when doc:tr] <http://www.w3.org/TR/YYYY/WDCRPRPERRECNOTERSCND-shortname-YYYYMMDD/>. [thisversionsyntax when doc:mem-subm] <http://www.w3.org/Submission/YYYY/SUBM-shortname-YYYYMMDD/>. [thisversionsyntax when doc:team-subm] <http://www.w3.org/TeamSubmission/YYYY/SUBM-shortname-YYYYMMDD/>. [thisversionsyntax when doc:xgr] <http://www.w3.org/2005/Incubator/xgname/XGR-shortname-YYYYMMDD/>.
  4. OK docIDLatestVersion The syntax of a "Latest Version" URI [latverreq when doc:tr|mem-subm] MUST [latverreq when doc:xgr] SHOULD be [latestversionsyntax when doc:tr] <http://www.w3.org/TR/shortname/>. [latestversionsyntax when doc:mem-subm] <http://www.w3.org/Submission/shortname/>. [latestversionsyntax when doc:xgr] <http://www.w3.org/2005/Incubator/xgname/XGR-shortname/>.
  5. OK docIDDate The title page date and the date at the end of the "This Version" URI MUST match.

Editor/Author Information

  1. EDITOR->UUID? editorSectionTest The editors'/authors' names MUST be listed. 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 [longgroupauthors when doc:tr] (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.
[erratainfo when doc:rec-tr]

Errata Information

  1. OK errataTest Immediately after the editors/authors' names, there MUST be a link to an errata document 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>The order of the a and strong elements MAY be reversed. See also suggestions on errata page structure in the Manual of Style. Note: Do not put the errata document in TR space as the expectation is that we will not modify document in TR space after publication; see the policy for in-place modification of W3C Technical Reports.

Links to non-normative document representations

  1. NOT_OK 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="STATUS-shortname-20020101.html">single HTML file</a>, <a href="STATUS-shortname-20020101.tgz">gzipped tar file of HTML</a>.</p> <a href="shortname-20020101.html">single HTML file</a>, <a href="shortname-20020101.tgz">gzipped tar file of HTML</a>.</p>
[translationinfo when doc:rec-tr]

Translation Information

  1. OK translationTest There MUST be a link to a translations page. The RECOMMENDED markup is: <p>See also <a href=" http://www.w3.org/2003/03/Translations/byTechnology?technology=shortname"> <strong>translations</strong></a>.</p>See suggestions on translations in the manual of style.

Copyright Information

  1. OK [copyinfo when doc:tr|team-subm|xgr] copyrightTest The copyright MUST use the following markup (fill in with the appropriate year, years, or year range). The abbr element MAY be used in place of acronym.
    Copyright © YYYY W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
  2. OK [copyinfo when doc:mem-subm] W3CDocNoticeTest The document must include a link to the W3C document notice. The copyright may be held by the Submitters.
  3. OK hrAfterCopyrightTest A horizontal rule (hr) MUST follow the copyright.

4. Document Abstract

  1. OK abstractTest There MUST be an abstract, labeled with an h2 element with content "Abstract" that follows the hr element.

5. Document Status Section

  1. OK sotdTest 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.
  2. EITHER ENFORCE IT OR REMOVE IT: [boilerplate-provision when doc:tr|subm] boilerplateTRDocTest 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 http://www.w3.org/TR/.

  3. [boilerplate-provision when doc:mem-subm] boilerplateMemberSubmTest It MUST include this boilerplate text (with links to the published Submission and Team Comment):

    By publishing this document, W3C acknowledges that the Submitting Members have made a formal Submission request to W3C for discussion. Publication of this document by W3C indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it. This document is not the product of a chartered W3C group, but is published as potential input to the W3C Process. A W3C Team Comment has been published in conjunction with this Member Submission. Publication of acknowledged Member Submissions at the W3C site is one of the benefits of W3C Membership. Please consult the requirements associated with Member Submissions of section 3.3 of the W3C Patent Policy. Please consult the complete list of acknowledged W3C Member Submissions.

  4. [boilerplate-provision when doc:xgr] boilerplateTRDocTest 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 Final Incubator Group Reports is available. See also the W3C technical reports index at http://www.w3.org/TR/.

  5. [teamsubmlink when doc:team-subm] teamSubmLinkTest It MUST include a link to the page listing all Team Submissions.
  6. NOT OK. ONLY A SHOULD FOR THE STATUS. datesFormatTest All dates MUST have the form DD Month YYYY. A leading zero in the day is OPTIONAL.
  7. OK [doctype when doc:fpwd-wd-tr|fpwdlc-wd-tr] FPWDTest It MUST indicate that this is a First Public Working Draft.
  8. OK [doctype when doc:lc-wd-tr|fpwdlc-wd-tr] LCTest It MUST indicate that this is a Last Call Working Draft.
  9. OK [groupname when doc:tr] WGLinkTest It MUST include the name of the W3C group that produced the document. The name MUST be a link to a public page for the group.
  10. OK [groupname when doc:xgr] XGLinkTest It MUST include the name of the W3C Incubator Group that produced the document. The name MUST be a link to a public page for the group.
  11. OK [mailinglistname when doc:tr] mailingListNameTest It MUST include the name of a mailing list for comments that has a public archive.
  12. OK [mailinglistarchive when doc:tr] mailingListLinkTest It MUST include a link to the public archive of that mailing list.
  13. OK [accomments when doc:pr-tr|per-tr] ACRepFeedbackEmailTest It also MUST provide information to Advisory Committee Representatives about how to send their review comments (e.g., a link to a WBS review form)
  14. OK [mailinglistname when doc:team-subm] commentsMailingListTest It MUST include the name of a mailing list for comments.
  15. OK [reviewend when doc:fpwdlc-wd-tr|lc-wd-tr] reviewEndDateLCTest It MUST include the end date of the Last Call review period.
  16. OK [reviewend when doc:pr-tr|per-tr] reviewEndDatePRTest It MUST include the end date of the review period.
  17. OK [reviewend when doc:cr-tr] reviewEndDateCRTest It MUST include a minimal duration (before which the group will not request the next transition). The duration MUST be expressed as an estimated date.
  18. OK [reviewend when doc:cr-tr] It SHOULD include an estimated date by which time the Working Group expects to have sufficient implementation experience.
  19. OK [interopreport when doc:cr-tr] implReportTest It MUST include a link to a preliminary interoperability or implementation report, or a statement that no such report exists.
  20. OK [interopreport when doc:pr-tr|per-tr] implReportTest It MUST include either:
    • a link to an interoperability or implementation report if the Director used such a report as part of the decision to advance the specification, or
    • a statement that the Director's decision did not involve such a report.
  21. OK [interopreport when doc:rec-tr prevrec:none|cppother|precppother|other] implReportTest It SHOULD include either:
    • a link to an interoperability or implementation report if the Director used such a report as part of the decision to advance the specification, or
    • a statement that the Director's decision did not involve such a report.
  22. OK, check for the string "feature at risk" [featuresatrisk when doc:cr-tr] featAtRiskTest It MUST identify any "features at risk" declared by the Working Group (as defined in section 7.4.3 of the W3C Process Document).
  23. [skipcr when doc:pr-tr] 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).
  24. [relationtoprevrecs when doc:rec-tr prevrec:editorial|cppeditorial|cppother|precppother|other] recRelationTest It 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 an editorial revision) and MUST link to the most recent Recommendation (if any) having the same major revision number. The document thus links to two important resources: the previous edition of the Recommendation via the status section, and the previous draft (the Proposed [Edited] Recommendation) via the "Previous version" link.
  25. NOT OK. SHOULD instead. [relationtoprevrecs when doc:rescind-tr] It MUST indicate that it rescinds a Recommendation and MUST link to the most recent Recommendation (if any) having the same major revision number.
  26. NOT OK. SHOULD instead. [relationtoprevrecs when doc:wd-tr|cr-tr|pr-tr|per-tr prevrec:editorial|cppeditorial|cppother|precppother|other] A STATUS that revises a previously published Recommendation with the same major revision number SHOULD link to the most recent Recommendation with that major revision number. [prevrecexample when prevrec:other|cppother|precppother] Example: The version 2.5 Working Draft is published after the 2.1 Second Edition Recommendation and links to it as the most recent 2.x Recommendation available at time of publication. [prevrecexample when prevrec:editorial|cppeditorial] Example: The version 2.1 Working Draft (Second Edition) is published after the 2.1 Recommendation and links to it as the most recent 2.x Recommendation available at time of publication.
  27. NOT OK. SHOULD instead. [publicationrationale when doc:rescind-tr] rescindDecisionTest It MUST include or link to rationale for the decision to rescind the Recommendation.
  28. OK. [publicationrationale when doc:note-tr] If the document was published due to a W3C decision to stop work on this material, the status section SHOULD include that rationale.
  29. [resindfwd when doc:rescind-tr] It SHOULD direct readers to alternative technologies.
  30. [noteendorsement when doc:note-tr] 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.
  31. NOT OK. SHOULD instead. [custompara when doc:tr] customParagraphTest 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.
  32. CHECK WITH IAN. [linktochanges when doc:ord-wd-tr|lc-wd-tr|wg-note-tr|ig-note-tr|cg-note-tr|cr-tr|pr-tr|per-tr|rec-tr] changesListTest It [changeinfo when doc:ord-wd-tr|lc-wd-tr|wg-note-tr|ig-note-tr|cg-note-tr] SHOULD [changeinfo when doc:cr-tr|pr-tr|per-tr|rec-tr] MUST include a link to changes since the previous draft (e.g., a list of changes or a diff document or both; see the online HTML diff tool). [changeinfo when doc:pr-tr|per-tr] The group MUST indicate which changes may affect conformance.
  33. OK [stability when doc:wd-tr|cr-tr|pr-tr|per-tr|note-tr] stabilityTest It MUST set expectations about the (in)stability of the document. The RECOMMENDED text [notestability when doc:note-tr] (see also ideas for status sections regarding the stability of group notes) is:

    Publication as[article when doc:wd-tr|cr-tr|pr-tr|per-tr|wg-note-tr|fpwg-note-tr|cg-note-tr] a[article when doc:ig-note-tr|fpig-note-tr] an STATUS 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.

  34. OK [stability when doc:rec-tr] stabilityTest It MUST set expectations about the stability of the document. The RECOMMENDED text is:

    This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

  35. OK [stability when doc:xgr] stabilityTest It MUST set expectations about the stability of the document. The RECOMMENDED text is:

    Publication of this document by W3C as part of the W3C Incubator Activity indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it. Participation in Incubator Groups and publication of Incubator Group Reports at the W3C site are benefits of W3C Membership.

  36. OK [patpolreqs when doc:wd-tr|cr-tr|pr-tr|per-tr|rec-tr|wg-note-tr|fpwg-note-tr patpol:w3c|cpp] patPolReqTest It MUST include this text related to patent policy requirements (with suitable links inserted; see guidelines for linking to disclosure pages):

    [patpoltype when patpol:w3c prevrec:editorial|other|none|doesnotapply] This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. [patpoltype when doc:wd-tr|cr-tr|pr-tr|wg-note-tr|fpwg-note-tr patpol:w3c prevrec:cppeditorial|cppother|precppother] This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. [patpoltype when doc:per-tr|rec-tr patpol:w3c prevrec:cppeditorial|cppother|precppother] This document is governed by the 24 January 2002 CPP as amended by the W3C Patent Policy Transition Procedure. [patpoltype when patpol:cpp] This document is governed by the 24 January 2002 CPP as amended by the W3C Patent Policy Transition Procedure. [notgoingtorec when doc:wd-tr|cr-tr|pr-tr|per-tr rectrack:no patpol:w3c] The group does not expect this document to become a W3C Recommendation. [informativeonly when normative:no patpol:w3c] This document is informative only. W3C maintains a [http:/www.w3.org/wiki/@@URI to IPP status or other page@@ public list of any patent disclosures] made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. [disclosureobligation when doc:wd-tr|cr-tr|pr-tr|per-tr|note-tr] An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

    Note: Contact the Communications Team for suitable adaptations in the case where a document has been published jointly by more than one group. In the adaptation, be sure that the text for informative-only specs or specs not going to Rec is the same as the standard text.
  37. OK [patpolreqs when doc:ig-note-tr|fpig-note-tr|cg-note-tr] patPolReqTest 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 [http:/www.w3.org/wiki/@@URI to disclosure section of charter@@ charter].

  38. CHECK WITH IAN: [patpolreqs when doc:wd-tr|cr-tr|pr-tr|per-tr|rec-tr|wg-note-tr|fpwg-note-tr patpol:none] Note: Please contact the Communications Team for information about what text to include related to patent policy requirements.
  39. [patpolreqs when doc:xgr] Note: Incubator Groups have as a goal to produce work that can be implemented on a Royalty Free basis, as defined in the W3C Patent Policy. Please contact the Communications Team for information about what text to include related to patent policy requirements. Sample text for XGs where Participants have made no statements:

    Incubator Groups have as a goal to produce work that can be implemented on a Royalty Free basis, as defined in the W3C Patent Policy. Participants in this Incubator Group have made no statements about whether they will offer licenses according to the licensing requirements of the W3C Patent Policy for portions of this Incubator Group Report that are subsequently incorporated in a W3C Recommendation.

  40. NOT OK. SHOULD NOT instead. [nonbdisclosures when doc:tr] knownDisclosureNumberTest It MUST NOT indicate the number of known disclosures at the time of publication.

6. Table of Contents

  1. [toc when doc:wd-tr|cr-tr|pr-tr|per-tr|rec-tr|note-tr|subm|xgr] tocTest There SHOULD be a table of contents after the status section, labeled with an h2 element with content "Table of Contents".

7. Document Body

  1. OK headingWithoutIDTest 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 element of the heading element (where the heading element is the first child of the div), a descendant of the heading element, or an a immediately preceding the heading element.
  2. OK brokenLinkTest The document MUST NOT have any broken internal links or broken links to other resources at w3.org. The document SHOULD NOT have any other broken links.
  3. OK cssValideTest recursive The document MUST NOT have any style sheet errors.
  4. OK namespacesTest recursive All proposed XML namespaces created by the publication of the document MUST follow URIs for W3C Namespaces.
  5. NOT OK. SHOULD instead. wcagTest The document(s) MUST conform to the Web Content Accessibility Guidelines 2.0, Level AA. Note: You may wish to consult the customizable quick reference to Web Content Accessibility Guidelines 2.0.

8. Compound Documents

  1. OK. compoundFilesLocationTest If the document is compound (i.e., if it consists of more than one file), all the files MUST be under a directory [compound when doc:tr|subm] [compoundpath when doc:tr] /TR[compoundpath when doc:mem-subm] /Submission[compoundpath when doc:team-subm] /TeamSubmission/YYYY/WDCRPRPERRECNOTERSCNDSUBM-shortname-YYYYMMDD/ [compound when doc:xgr] /2005/Incubator/xgname/XGR-shortname-YYYYMMDD/
  2. OK. compoundOverviewTestThe main page SHOULD be called Overview.html.
  3. OK. compoundTestAll other files MUST be reachable by links from the document.

Comparision of Alternatives

For accomments

doc:pr-tr | per-tr

ACRepFeedbackEmailTest It also MUST provide information to Advisory Committee Representatives about how to send their review comments (e.g., a link to a WBS review form)

For boilerplate-provision

doc:tr | subm

boilerplateTRDocTest 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 http://www.w3.org/TR/.

doc:mem-subm

boilerplateMemberSubmTest It MUST include this boilerplate text (with links to the published Submission and Team Comment):

By publishing this document, W3C acknowledges that the Submitting Members have made a formal Submission request to W3C for discussion. Publication of this document by W3C indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it. This document is not the product of a chartered W3C group, but is published as potential input to the W3C Process. A W3C Team Comment has been published in conjunction with this Member Submission. Publication of acknowledged Member Submissions at the W3C site is one of the benefits of W3C Membership. Please consult the requirements associated with Member Submissions of section 3.3 of the W3C Patent Policy. Please consult the complete list of acknowledged W3C Member Submissions.

doc:xgr

boilerplateTRDocTest 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 Final Incubator Group Reports is available. See also the W3C technical reports index at http://www.w3.org/TR/.

For compound

doc:tr | subm

/TR/Submission/TeamSubmission/YYYY/WDCRPRPERRECNOTERSCNDSUBM-shortname-YYYYMMDD/

doc:xgr

/2005/Incubator/xgname/XGR-shortname-YYYYMMDD/

For copyinfo

doc:tr | team-subm | xgr

copyrightTest The copyright MUST use the following markup (fill in with the appropriate year, years, or year range). The abbr element MAY be used in place of acronym.

Copyright © YYYY W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

doc:mem-subm

W3CDocNoticeTest The document must include a link to the W3C document notice. The copyright may be held by the Submitters.

For custompara

doc:tr

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

For doctype

doc:fpwd-wd-tr | fpwdlc-wd-tr

FPWDTest It MUST indicate that this is a First Public Working Draft.

doc:lc-wd-tr | fpwdlc-wd-tr

LCTest It MUST indicate that this is a Last Call Working Draft.

For erratainfo

doc:rec-tr

Errata Information

  1. errataTest Immediately after the editors/authors' names, there MUST be a link to an errata document 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> The order of the a and strong elements MAY be reversed. See also suggestions on errata page structure in the Manual of Style. Note: Do not put the errata document in TR space as the expectation is that we will not modify document in TR space after publication; see the policy for in-place modification of W3C Technical Reports.

For featuresatrisk

doc:cr-tr

featAtRiskTest It MUST identify any "features at risk" declared by the Working Group (as defined in section 7.4.3 of the W3C Process Document).

For groupname

doc:tr

WGLinkTest It MUST include the name of the W3C group that produced the document. The name MUST be a link to a public page for the group.

doc:xgr

XGLinkTest It MUST include the name of the W3C Incubator Group that produced the document. The name MUST be a link to a public page for the group.

For interopreport

doc:cr-tr

implReportTest It MUST include a link to a preliminary interoperability or implementation report, or a statement that no such report exists.

doc:pr-tr | per-tr

implReportTest It MUST include either:

  • a link to an interoperability or implementation report if the Director used such a report as part of the decision to advance the specification, or
  • a statement that the Director's decision did not involve such a report.

doc:rec-tr prevrec:none | cppother | precppother | other

implReportTest It SHOULD include either:

  • a link to an interoperability or implementation report if the Director used such a report as part of the decision to advance the specification, or
  • a statement that the Director's decision did not involve such a report.

For latestversionsyntax

doc:tr

<http://www.w3.org/TR/shortname/>.

doc:mem-subm

<http://www.w3.org/Submission/shortname/>.

doc:xgr

<http://www.w3.org/2005/Incubator/xgname/XGR-shortname/>.

For latverreq

doc:tr | mem-subm

MUST

doc:xgr

SHOULD

For linktochanges

doc:ord-wd-tr | lc-wd-tr | wg-note-tr | ig-note-tr | cg-note-tr | cr-tr | pr-tr | per-tr | rec-tr

changesListTest It SHOULD MUST include a link to changes since the previous draft (e.g., a list of changes or a diff document or both; see the online HTML diff tool). The group MUST indicate which changes may affect conformance.

For longgroupauthors

doc:tr

(e.g., the entire Working Group)

For mailinglistarchive

doc:tr

mailingListLinkTest It MUST include a link to the public archive of that mailing list.

For mailinglistname

doc:tr

mailingListNameTest It MUST include the name of a mailing list for comments that has a public archive.

doc:team-subm

commentsMailingListTest It MUST include the name of a mailing list for comments.

For nonbdisclosures

doc:tr

knownDisclosureNumberTest It MUST NOT indicate the number of known disclosures at the time of publication.

For noteendorsement

doc:note-tr

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.

For patpolreqs

doc:wd-tr | cr-tr | pr-tr | per-tr | rec-tr | wg-note-tr | fpwg-note-tr patpol:w3c | cpp

patPolReqTest It MUST include this text related to patent policy requirements (with suitable links inserted; see guidelines for linking to disclosure pages):

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. This document is governed by the 24 January 2002 CPP as amended by the W3C Patent Policy Transition Procedure. This document is governed by the 24 January 2002 CPP as amended by the W3C Patent Policy Transition Procedure. The group does not expect this document to become a W3C Recommendation. This document is informative only. W3C maintains a [http:/www.w3.org/wiki/@@URI to IPP status or other page@@ public list of any patent disclosures] made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Note: Contact the Communications Team for suitable adaptations in the case where a document has been published jointly by more than one group. In the adaptation, be sure that the text for informative-only specs or specs not going to Rec is the same as the standard text.

doc:ig-note-tr | fpig-note-tr | cg-note-tr

patPolReqTest 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 [http:/www.w3.org/wiki/@@URI to disclosure section of charter@@ charter].

doc:wd-tr | cr-tr | pr-tr | per-tr | rec-tr | wg-note-tr | fpwg-note-tr patpol:none

Note: Please contact the Communications Team for information about what text to include related to patent policy requirements.

doc:xgr

Note: Incubator Groups have as a goal to produce work that can be implemented on a Royalty Free basis, as defined in the W3C Patent Policy. Please contact the Communications Team for information about what text to include related to patent policy requirements. Sample text for XGs where Participants have made no statements:

Incubator Groups have as a goal to produce work that can be implemented on a Royalty Free basis, as defined in the W3C Patent Policy. Participants in this Incubator Group have made no statements about whether they will offer licenses according to the licensing requirements of the W3C Patent Policy for portions of this Incubator Group Report that are subsequently incorporated in a W3C Recommendation.

For prevversionuri

doc:ord-wd-tr | lc-wd-tr | cr-tr | pr-tr | per-tr | rec-tr | wg-note-tr | ig-note-tr | cg-note-tr

Previous version URI

doc:rescind-tr

"Rescinds this Recommendation" URI

doc:fpwd-wd-tr | fpwdlc-wd-tr | fpwg-note-tr

Note: Because this is a first draft, there SHOULD NOT be a Previous version URI. Use the status section to identify the relationship(s) to previous work (e.g., previous Recommendations). In some cases (e.g., mere change of short name or when a monolithic specification has been split into multiple parts) a Previous version URI MAY appear. Ask the Comm Team if you have questions.

For publicationrationale

doc:rescind-tr

rescindDecisionTest It MUST include or link to rationale for the decision to rescind the Recommendation.

doc:note-tr

If the document was published due to a W3C decision to stop work on this material, the status section SHOULD include that rationale.

For rec-in-place

doc:rec-tr

If a Recommendation modified in place, see the Comm Team's policy regarding in-place modification of W3C Technical Reports, otherwise

For rec-new-edition

doc:rec-tr

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. For example:

<h2>W3C Recommendation 7 April 2004,
    edited in place 19 August2004</h2>

For relationtoprevrecs

doc:rec-tr prevrec:editorial | cppeditorial | cppother | precppother | other

recRelationTest It 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 an editorial revision) and MUST link to the most recent Recommendation (if any) having the same major revision number. The document thus links to two important resources: the previous edition of the Recommendation via the status section, and the previous draft (the Proposed [Edited] Recommendation) via the "Previous version" link.

doc:rescind-tr

It MUST indicate that it rescinds a Recommendation and MUST link to the most recent Recommendation (if any) having the same major revision number.

doc:wd-tr | cr-tr | pr-tr | per-tr prevrec:editorial | cppeditorial | cppother | precppother | other

A STATUS that revises a previously published Recommendation with the same major revision number SHOULD link to the most recent Recommendation with that major revision number. Example: The version 2.5 Working Draft is published after the 2.1 Second Edition Recommendation and links to it as the most recent 2.x Recommendation available at time of publication. Example: The version 2.1 Working Draft (Second Edition) is published after the 2.1 Recommendation and links to it as the most recent 2.x Recommendation available at time of publication.

For resindfwd

doc:rescind-tr

It SHOULD direct readers to alternative technologies.

For reviewend

doc:fpwdlc-wd-tr | lc-wd-tr

reviewEndDateLCTest It MUST include the end date of the Last Call review period.

doc:pr-tr | per-tr

reviewEndDatePRTest It MUST include the end date of the review period.

doc:cr-tr

reviewEndDateCRTest It MUST include a minimal duration (before which the group will not request the next transition). The duration MUST be expressed as an estimated date.

doc:cr-tr

It SHOULD include an estimated date by which time the Working Group expects to have sufficient implementation experience.

For skipcr

doc:pr-tr

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

For stability

doc:wd-tr | cr-tr | pr-tr | per-tr | note-tr

stabilityTest 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 a an STATUS 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.

doc:rec-tr

stabilityTest It MUST set expectations about the stability of the document. The RECOMMENDED text is:

This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

doc:xgr

stabilityTest It MUST set expectations about the stability of the document. The RECOMMENDED text is:

Publication of this document by W3C as part of the W3C Incubator Activity indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it. Participation in Incubator Groups and publication of Incubator Group Reports at the W3C site are benefits of W3C Membership.

doc:mem-subm

logoTest In addition to the W3C logo, use this logo:

doc:team-subm

logoTest In addition to the W3C logo, use this logo:

For teamsubmlink

doc:team-subm

teamSubmLinkTest It MUST include a link to the page listing all Team Submissions.

For thisverreq

doc:tr | subm

MUST

doc:xgr

SHOULD

For thisversionsyntax

doc:tr

<http://www.w3.org/TR/YYYY/WDCRPRPERRECNOTERSCND-shortname-YYYYMMDD/>.

doc:mem-subm

<http://www.w3.org/Submission/YYYY/SUBM-shortname-YYYYMMDD/>.

doc:team-subm

<http://www.w3.org/TeamSubmission/YYYY/SUBM-shortname-YYYYMMDD/>.

doc:xgr

<http://www.w3.org/2005/Incubator/xgname/XGR-shortname-YYYYMMDD/>.

For toc

doc:wd-tr | cr-tr | pr-tr | per-tr | rec-tr | note-tr | subm | xgr

tocTest There SHOULD be a table of contents after the status section, labeled with an h2 element with content "Table of Contents".

For translationinfo

doc:rec-tr

Translation Information

  1. translationTest There MUST be a link to a translations page. The RECOMMENDED markup is:

<p>See also <a href=" http://www.w3.org/2003/03/Translations/byTechnology?technology=shortname"> <strong>translations</strong></a>.</p> See suggestions on translations in the manual of style.

For versioninfoxref

doc:tr

See also the (non-normative) Version Management in W3C Technical Reports for information about "latest version" URI and version management.

doc:xgr

logoTest In addition to the W3C logo, use this logo: