author charles
Thu, 12 Dec 2013 15:32:18 +0400
changeset 55 6bd6536dd075
parent 54 840ff6a43e74
child 56 18c78ed75463
permissions -rw-r--r--
Editorial changes related to Ian's review. See
Fixed the Table of Contents again
Generally using id= on elements, rather than a name=
<!DOCTYPE html>
    <meta content="text/html; charset=UTF-8" http-equiv="content-type">
    <title>A Rec-track Process Draft Proposal</title>
    <link href="" type="text/css" rel="stylesheet">
    <style type="text/css">
      .from {display:none }
     .about { margin-left: 3em; margin-right: 3em; font-size: .83em}
     table { margin-left: auto; margin-right: auto }
     .diagram { text-align: center; margin: 2.5em 0 }
      .issue { line-height: 125% ; border: dashed red 2px; background-color: yellow }
      .issue::before {content: "Issue: "}
      .issue::after {content: "@@"}
      .rfc2119 {font-variant:small-caps}
</style> <link href="prism.css" rel="stylesheet">
    <link href="" rel="stylesheet">
    <!--[if lt IE 9]><script src='undefined://'></script><![endif]-->
    <div class="head">
      <p> <a href=""><img alt="W3C" src=""
            height="48" width="72"></a> </p>
      <h1 class="title" id="title">Recommendation Track Process, post-"Last
        Call" draft proposal</h1>
      <h2 id="w3c-working-draft-20-september-2012"><abbr title="World Wide Web Consortium"></abbr>Editors'
        Draft 11 December 2013</h2>
        <dt>Current active version:</dt>
        <dd><a href=""></a></dd>
        <dt>Latest editor's draft:</dt>
        <dd> <a href=""></a></dd>
        <dd><a href="">Charles (McCathie) Nevile</a>,
          <a href="">Яндекс</a>—<a href="">Yandex</a></dd>
      <p class="copyright"> <a href="">Copyright</a>
        © 2013 <a href=""><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup>
        (<a href=""><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>,
        <a href=""><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
        <a href="">Keio</a>, <a href="">Beihang</a>),
        All Rights Reserved. <abbr title="World Wide Web Consortium">W3C</abbr>
        <a href="">liability</a>,
        <a href="">trademark</a>,
        <a href="">document
          use</a> and <a href="">software
          licensing</a> rules apply. </p>
      <hr> </div>
    <div class="noprint">
      <div class="navbar">
        <p>This is an intermediate revised draft proposal to replace the <a href="">current
            chapter 7 of the W3C process document</a> with a more effective W3C
          Specification life cycle following the meeting of the W3C Advisory
          Board's Chapter 7 Task Force on 2 December 2013. This document is the
          editor's draft for resolution of comments received on the "Last Call"
        <p>In this draft, there are some pointers and placeholders for changes
          expected in response to open issues, most particularly <a href="">ISSUE-59</a>.</p>
        <p>This introductory session (before the chapter title below) will be
          removed when this chapter is re-incorporated into the full process
          document, as per issues 60-64.</p>
        <p>An initial version was first proposed to the W3C Advisory Board on 13
          May 2013 as a possible replacement for the <a href="">current
            chapter 7 of the W3C process document</a>, and a <a href="">subsequent
            version</a> was <a href="">proposed</a>
          to the <a href="">W3C Process
            Community Group</a> on 29 May 2013 by Charles Nevile &lt;<a href=""></a>&gt;
          for discussion. Subsequent editor's drafts have been public, to enable
          broad input. However, following the existing process, the Advisory
          Board retains formal responsibility for decisions on what it proposes
          to the Advisory Committee, and the adoption of any change to the
          process will follow the <a href="">existing
            process for such changes</a>, subject to the resolution of <a href="">ISSUE-39</a>.</p>
        <p>I am grateful to the W3C Advisory Board, the W3C Process Community
          Group, Art Barstow, Robin Berjon, Wayne Carr, Marcos Cáceres, Elika
          Etimad, Fantasai, Ivan Herman, Ian Hickson, Ian Jacobs, Jeff Jaffe,
          Chris Lilley, Ralph Swick, Anne van Kesteren, Steve Zilles, and many
          people I have forgotten to acknowledge for suggestions, comments and
          discussions that helped me sort out my thinking, and to Ora Lassila
          for the original version of the image that illustrates the normal
          process of a W3C Recommendation-track document. </p>
        <p>Please send comments on this document to, or participate in, the <a
            href="">W3C Process Community
            Group</a>. Issues related to this proposal are recorded in that
          group's issue tracker using the product "<a href="">Document
            Lifecycle (chapter 7)</a>"</p>
        Major changes:
          <li>There is a requirement that Working groups <em class="rfc2119">should</em>
            document known implementation for all transitions</li>
          <li>New sections give some guidance on what is considered when
            assessing "<a href="#implementation-experience">adequate
              implementation experience</a>" and "<a href="#wide-review">wide
          <li>Last Call and Candidate Recommendation have been collapsed
            together. Some of the requirements are therefore enforced earlier in
            the process.</li>
          <li>There is a stronger emphasis (without creating new formal
            requirements) on getting review and testing implementation as early
            as possible. How to do this is left to Working Groups to determine.</li>
          <li>Proposed Recommendation is no longer a separate step. Advisory
            Committee review now begins at the same time as Candidate
            recommendation, and ends 4 weeks after the Working group has
            provisional approval for a Request to publish as a W3C
          <li>The Director is required to address AC review comments <strong>publicly</strong>,
            2 weeks <em>before</em> publication of a Recommendation.</li>
          <li>And it is in HTML5</li>
        <p>Editorially, I have tried to rationalize requirements and clarify who
          is responsible for meeting them. I have also removed advice and
          general statements to keep this version short.</p>
    <h2 id="Reports">7 W3C Technical Report Development Process</h2>
    <p>The W3C technical report development process is the set of steps and
      requirements followed by W3C <a href="">Working
        Groups</a> to standardize Web technology. The W3C technical report
      development process is designed to </p>
      <li>support multiple specification development methodologies</li>
      <li>maximize <a href=""
          rel="glossary" title="Definition of Consensus"><span class="dfn-instance">consensus</span></a>
        about the content of stable technical reports</li>
      <li>ensure high technical and editorial quality</li>
      <li>promote consistency among specifications</li>
      <li>facilitate royalty-free, interoperable implementations of Web
        Standards, and</li>
      <li>earn endorsement by W3C and the broader community.</li>
    <p>See also the licensing goals for W3C Recommendations in <a href="">section
        2</a> of the <a href="">W3C
        Patent Policy</a> [<a href="">PUB33</a>].
    <h3>Table of Contents</h3>
    <ul id="mozToc">
      <!--mozToc h3 1 h4 2 h5 3-->
      <li><a href="#rec-advance">7.1 W3C Technical Reports</a>
          <li><a href="#recs-and-notes">7.1.1 Recommendations and Notes</a></li>
          <li><a href="#maturity-levels">7.1.2 Maturity Levels</a></li>
      <li><a href="#requirements-and-definitions">7.2 General requirements and
          <li><a href="#general-requirements">7.2.1 General requirements for
              Technical Reports</a></li>
          <li><a href="#transition-reqs">7.2.2 Advancement on the Recommendation
              <li><a href="#substantive-change"> Substantive Change</a></li>
          <li><a href="#doc-reviews">7.2.3 Reviews and Review Responsibilities</a>
              <li><a href="#wide-review"> Wide Review</a></li>
          <li><a href="#implementation-experience">7.2.4 Implementation
      <li><a href="#working-draft">7.3 Working Draft</a>
          <li><a href="#first-wd">7.3.1 First Public Working Draft</a></li>
          <li><a href="#revised-wd">7.3.2 Revised Public Working Drafts</a></li>
      <li><a href="#candidate-rec">7.4 Candidate Recommendation</a>
          <li><a href="#revised-cr">7.4.1 Revised Candidate Recommendation</a></li>
      <li><a href="#rec-publication">7.5 W3C Recommendation</a>
          <li><a href="#for-all-recs">7.5.1 For all W3C Recommendations</a></li>
          <li><a href="#lcrec-publication">7.5.2 Publishing a Candidate
              Recommendation as a W3C Recommendation</a></li>
      <li><a href="#rec-modify">7.6 Modifying a W3C Recommendation</a>
          <li><a href="#errata">7.6.1 Errata Management</a></li>
          <li><a href="#correction-classes">7.6.2 Classes of Changes to a
          <li><a href="#revised-rec">7.6.3 Revising a Recommendation</a></li>
      <li><a href="#tr-end">7.7 Publishing a Working Group or Interest Group
      <li><a href="#good-practice">7.8 Rescinding a W3C Recommendation</a></li>
      <li><a href="#mozTocId806006">Further reading</a></li>
    <h3 id="rec-advance">7.1 W3C Technical Reports</h3>
    <h4 id="recs-and-notes">7.1.1 Recommendations and Notes</h4>
    <p>W3C follows these steps when advancing a technical report to
      <li><a href="#first-wd">Publication of the First Public Working Draft</a>,</li>
      <li><a href="#hb-wd">Publication of zero or more revised Public Working
      <li><a href="#last-call">Publication of a Candidate Recommendation</a>.</li>
      <li><a href="#rec-publication">Publication as a Recommendation</a>.</li>
      <li>Possibly, <a href="#rec-edited">Publication as an Edited
      <svg xlink="" xmlns=""
        viewBox="0.00 0.00 400.00 62.00" height="5em" width="36em">
        <g transform="scale(1 1) rotate(0) translate(4 58)" class="graph" id="graph0">
          <g class="node" id="wd">
            <ellipse ry="18" rx="38.1938" cy="-18" cx="147" stroke="black" fill="none"></ellipse>
            <a xlink:href="#RecsWD"><text font-size="14.00" font-family="Times,serif"
                y="-14.3" x="147" text-anchor="middle">WD</text></a> </g>
          <g class="edge" id="edge1">
            <a xlink:href="#first-wd"><text font-size="8.00" font-family="Times,serif"
                y="-20" x="66" text-anchor="left">First WD</text></a>
            <path d="M66,-18h32.25" stroke="black" fill="none"></path>
            <polygon points="98.5289,-21.5001 108.529,-18 98.5289,-14.5001 98.5289,-21.5001"
              stroke="black" fill="black"></polygon> </g>
          <g class="edge" id="edge2">
            <path d="M128.006,-33.916C123.052,-44.1504 129.383,-54 147,-54 158.561,-54 165.262,-49.7581 167.102,-43.9494"
              stroke="black" fill="none"></path>
            <polygon points="170.571,-43.471 165.994,-33.916 163.613,-44.24 170.571,-43.471"
              stroke="black" fill="black"></polygon> </g>
          <g class="node" id="lccr">
            <ellipse ry="18" rx="37.8943" cy="-18" cx="260" stroke="black" fill="none"></ellipse>
            <a xlink:href="#RecsCR"><text font-size="14.00" font-family="Times,serif"
                y="-14.3" x="260" text-anchor="middle">LCCR</text></a> </g>
          <g class="edge" id="lccr-repeat">
            <path d="M183.12,-11.67h30.5" stroke="black" fill="none"></path>
            <polygon points="214.378,-14.8689 224.487,-11.6987 214.607,-7.87265 214.378,-14.8689"
              stroke="black" fill="black"></polygon> </g>
          <g class="edge" id="edge4">
            <path d="M242.388,-33.916C237.793,-44.1504 243.664,-54 260,-54 270.72,-54 276.934,-49.7581 278.64,-43.9494"
              stroke="black" fill="none"></path>
            <polygon points="282.114,-43.5071 277.612,-33.916 275.15,-44.2208 282.114,-43.5071"
              stroke="black" fill="black"></polygon> </g>
          <g class="edge" id="edge5">
            <path d="M224.5,-24.5h-31.2" stroke="black" fill="none"></path>
            <polygon points="193.226,-21.1436 183.121,-24.3281 193.006,-28.1402 193.226,-21.1436"
              stroke="black" fill="black"></polygon> </g>
          <g class="node" id="node4">
            <ellipse ry="18" rx="28.6953" cy="-18" cx="363" stroke="black" fill="none"></ellipse>
            <a xlink:href="#RecsW3C"><text font-size="14.00" font-family="Times,serif"
                y="-14.3" x="363" text-anchor="middle">REC</text></a> </g>
          <g class="edge" id="edge6">
            <path d="M297.75,-18h26.5" stroke="black" fill="none"></path>
            <polygon points="324.306,-21.5001 334.306,-18 324.306,-14.5001 324.306,-21.5001"
              stroke="black" fill="black"></polygon> </g> </g> </svg> </p>
    <p>W3C <em class="rfc2119">may</em> <a href="#tr-end">end work on a
        technical report</a> at any time.</p>
    <p>The Director <em class="rfc2119">may</em> decline a request to advance
      in maturity level, requiring a Working Group to conduct further work, and
      <em class="rfc2119">may</em> require the specification to return to a
      lower <a href="#maturity-level">maturity level</a>. The Director <em class="rfc2119">must</em>
      inform the <a href="">Advisory
        Committee</a> and Working Group Chairs when a Working Group's request
      for a specification to advance in maturity level is declined and and the
      specification is returned to a Working Group for further work.</p>
    <p class="issue">Add a short explanation of Note track, and how documents
      can go from Rec-track to Note and back, to this section. <a href="">ISSUE-59</a></p>
    <h4 id="maturity-levels">7.1.2 Maturity Levels</h4>
      <dt id="RecsWD">Working Draft (WD)</dt>
      <dd>A Working Draft is a document that W3C has published for review by the
        community, including W3C Members, the public, and other technical
        organizations. Some, but not all, Working Drafts are meant to advance to
        Recommendation; see the <a href="#DocumentStatus">document status
          section</a> of a Working Draft for the group's expectations. Any
        Working Draft not, or no longer, intended to advance to Recommendation <em
          class="rfc2119">should</em> be published as a Working Group Note.
        Working Drafts do not necessarily represent a consensus of the Working
        Group, and do not imply any endorsement by W3C or its members beyond
        agreement to work on a general area of technology.</dd>
      <dt id="RecsCR">Candidate Recommendation (CR)</dt>
      <dd class="changed">A Candidate Recommendation is a document that
        Satisfies the Working Group's technical requirements, and has already
        received wide review. W3C publishes a Candidate Recommendation to
          <li>signal to the wider community that a final review should be done</li>
          <li>gather <a href="#implementation-experience">implementation
          <li>begin formal review by the Advisory Committee, who <em class="rfc2119">may</em>
            recommend that the document be published as a W3C Recommendation,
            returned to the Working Group for further work, or abandoned. </li>
      <dd class="new"><strong>Note:</strong> Candidate Recommendation is the
        state referred to in the <a href="">W3C
          Patent Policy</a> [<a href="">PUB33</a>]
        as "Last Call Working Draft"</dd>
      <dd><strong>Note:</strong> Candidate Recommendations will normally be
        accepted as Recommendations. Announcement of a different next step <em
          class="rfc2119">should</em> include the reasons why the change in
        expectations comes at so late a stage.</dd>
      <dt id="RecsW3C">W3C Recommendation (REC)</dt>
      <dd>A W3C Recommendation is a specification or set of guidelines or
        requirements that, after extensive consensus-building, has received the
        endorsement of W3C Members and the Director. W3C recommends the wide
        deployment of its Recommendations as standards for the Web.</dd>
      <dt id="WGNote">Working Group Note, Interest Group Note (NOTE) </dt>
      <dd>A Working Group Note or Interest Group Note is published by a
        chartered Working Group or Interest Group to provide a stable reference
        for a document that is not intended to be a specification requiring
        conformance, but is nevertheless useful. Examples include supporting
        documents such as Use case and Requirements documents, Design Principles
        that explain what the Working Group was trying to achieve with a
        specification, or 'Good Practices" documents. A Working Group <em class="rfc2119">may</em>
        also publish a specification as a Note if they stop work without
        producing a Recommendation. A Working Group or Interest Group <em class="rfc2119">may</em>
        publish a Note with or without its prior publication as a Working Draft.</dd>
      <dt id="RescindedRec">Rescinded Recommendation</dt>
      <dd>A Rescinded Recommendation is an entire Recommendation that W3C no
        longer endorses. See also clause 10 of the licensing requirements for
        W3C Recommendations in <a href="">section
          5</a> of the <a href="">W3C
          Patent Policy</a> [<a href="">PUB33</a>].</dd>
    <p>Working Groups and Interest Groups <em class="rfc2119">may</em> publish
      "Editor's drafts". Editor's drafts have no official standing whatsoever,
      and do not imply consensus of a Working Group or Interest Group, nor are
      their contents endorsed in any way by W3C or its members, except to the
      extent that such contents happen to be consistent with some other document
      which carries a higher level of endorsement.</p>
    <h3 id="requirements-and-definitions">7.2 General requirements and
    <h4 id="general-requirements">7.2.1 General requirements for Technical
    <p>Every document published as part of the technical report development
      process <em class="rfc2119 old">must</em> be a public document. The <a href="">index
        of W3C technical reports</a> [<a href="">PUB11</a>]
      is available at the W3C Web site. W3C will make every effort to make
      archival documents indefinitely available at their original address in
      their original form.</p>
    <p>Every document published as part of the technical report development
      process <em class="rfc2119 old">must</em> clearly indicate its <a href="#maturity-levels">maturity
        level</a>, and <em id="DocumentStatus" class="rfc2119">must</em>
      include information about the status of the document. This status
      <li><em class="rfc2119">must</em> be unique each time a specification is
        <em class="rfc2119"></em></li>
      <li><em class="rfc2119">must</em> state who developed the specification, </li>
      <li><em class="rfc2119">must</em> state how to send comments or file bugs,
        and where these are recorded, </li>
      <li> <em class="rfc2119">should</em> explain how the technology relates
        to existing international standards and related work inside or outside
      <li><em class="rfc2119">should</em> include expectations about next steps,
      <li><em class="rfc2119">should</em> explain or link to an explanation of
        significant changes from the previous version.</li>
    <p>Every Technical Report published as part of the Technical Report
      development process is edited by one or more editors appointed by a Group
      Chair. It is the responsibility of these editors to ensure that the
      decisions of the Group are correctly reflected in subsequent drafts of the
      technical report. An editor <em class="rfc2119">must</em> be a
      participant, as a Member representative, Team representative, or Invited
      Expert in the Group responsible for the document(s) they are editing. </p>
    <p>The Team is <em class="rfc2119">not required</em> to publish a Technical
      Report that does not conform to the Team's <a href="">Publication
        Rules</a> (e.g., for <a name="DocumentName" id="DocumentName">naming</a>,
      status information, style, and <a name="document-copyright" id="document-copyright">copyright
        requirements</a>). These rules are subject to change by the Team from
      time to time. The Team <em class="rfc2119">must</em> inform group Chairs
      and the Advisory Committee of any changes to these rules.</p>
    <p>The primary language for W3C Technical Reports is English. W3C encourages
      the translation of its Technical Reports. <a href="">Information
        about translations of W3C technical reports</a> [<a href="">PUB18</a>]
      is available at the W3C Web site.</p>
    <h4 id="transition-reqs">7.2.2 Advancement on the Recommendation Track</h4>
    <p>For <em>all</em> requests to advance a specification to a new maturity
      level other than Note the Working Group:</p>
      <li><em class="rfc2119">must</em> record the group's decision to request
      <li><em class="rfc2119">must </em> obtain Director approval.</li>
      <li><em class="rfc2119 ">must</em> provide public documentation of all <a
          href="#substantive-change">substantive changes</a> to the technical
        report since the previous publication. The community also appreciates
        public documentation of minor changes.</li>
      <li><em class="rfc2119">must</em> <a href="">formally
          address</a> all issues raised about the document since the previous
        maturity level.</li>
      <li><em class="rfc2119">must</em> provide public documentation of any <a
      <li><em class="rfc2119">should</em> report which, if any, of the Working
        Group's requirements for this document have changed since the previous
      <li><em class="rfc2119">should</em> report any changes in dependencies
        with other groups.</li>
      <li><em class="rfc2119">should</em> document known implementation.</li>
    <p>Because the requirements for First Public Working Drafts are fairly
      mechanical approval is normally fairly automatic, whereas for later stages
      there is generally a formal review meeting to ensure the requirements have
      been met before Director's approval is given.</p>
    <h5 id="substantive-change"> Substantive Change</h5>
    <p class="issue">This subsection will probably get merged into the later
      section on changes, as per <a href="">ISSUE-72</a></p>
    <p> A <dfn>substantive change</dfn> (whether deletion, inclusion, or other
      modification) is one where someone could reasonably expect that making the
      change would invalidate an individual's review or implementation
      experience. Other changes (e.g., clarifications, bug fixes, editorial
      repairs, and minor error corrections) are minor changes.</p>
    <h4 id="doc-reviews">7.2.3 Reviews and Review Responsibilities</h4>
    <p>A document is available for review from the moment it is first published.
      Working Groups <em class="rfc2119">should</em> <a href="">formally
        address</a> <em>any</em> substantive review comment about a technical
      report in a timely manner. </p>
    Reviewers <em class="rfc2119">should</em> send substantive technical
    reviews as early as possible. Working Groups are often reluctant to make <a
      href="#substantive-change">substantive changes</a> to a mature document,
    particularly if this would cause significant compatibility problems due to
    existing implementation. Working Groups <em class="rfc2119">should</em>
    record substantive or interesting proposals raised by reviews but not
    incorporated into a current specification.
    <h5> <a id="wide-review">Wide Review</a></h5>
    <p>The requirements for <dfn>wide review</dfn> are not precisely defined by
      the process. The objective is to ensure that the entire set of
      stakeholders of the Web community, including the general public, have had
      adequate notice of the progress of the Working Group and thereby an
      opportunity to comment on the specification. Before approving transitions,
      the Director will consider who has actually reviewed the document and
      provided comments, the record of requests to and responses from reviewers,
      especially groups identified as dependencies in the charter, and seek
      evidence of clear communication to the general public about appropriate
      times and which content to review. </p>
    <p>For example, inviting review of new or significantly revised sections
      published in Working Drafts, and tracking those comments and the Working
      Group's responses, is generally a good practice which would often be
      considered positive evidence of wide review. A recommended practice is
      making a specific announcement to other W3C Working Groups as well as the
      general public that a group proposes to enter Candidate Recommendation in
      e.g. approximately four weeks. By contrast a generic statement in a
      document requesting review at any time is likely not to be considered as
      sufficient evidence that the group has solicited wide review. </p>
    <p>A Working Group could present evidence that wide review has been
      received, irrespective of solicitation. But it is important to note that
      receiving many detailed reviews is not necessarily the same as wide
      review, since they may only represent comment from a small segment of the
      relevant stakeholder community.</p>
    <h4 id="implementation-experience">7.2.4 Implementation Experience</h4>
    <p>Implementation experience is required to show that a specification is
      sufficiently clear, complete, and relevant to market needs, to ensure that
      independent interoperable implementations of each feature of the
      specification will be realized. While no exhaustive list of requirements
      is provided here, when assessing that there is <dfn>adequate
        implementation experience</dfn> the Director will consider (though not
      be limited to):</p>
      <li>is each feature implemented, and how is this demonstrated; (for
        example, is there a test suite)?</li>
      <li>are there independent interoperable implementations?</li>
      <li>are there implementations created by other than the authors of the
      <li>are implementations publicly deployed?</li>
      <li>is there implementation experience at all levels of the
        specification's ecosystem (creation, consuming, publishing…)?</li>
    <p>Planning and accomplishing a demonstration of (interoperable)
      implementations can be very time consuming. Groups are often able to work
      more effectively if they plan how they will demonstrate interoperable
      implementations early in the development process; for example, they may
      wish to develop tests in concert with implementation efforts.</p>
    <h3 id="working-draft">7.3 Working Draft</h3>
    <p>A Public Working Draft is published on the W3C's Technical Reports page
      [TR] for review, and for simple historical reference. For all Public
      Working Drafts a Working Group</p>
      <li> <em class="rfc2119">should</em> document outstanding issues, and
        parts of the document on which the Working Group does not have
        consensus, and</li>
      <li> <em class="rfc2119">may</em> request publication of a Working Draft
        even if its content is considered unstable and does not meet all Working
        Group requirements.</li>
    <h4 id="first-wd">7.3.1 First Public Working Draft</h4>
    <p>To publish the First Public Working Draft of a document, a Working Group
      must meet the <a href="#transition-reqs">general requirements for
    <p>The Director <em class="rfc2119">must</em> announce the publication of a
      First Public Working Draft publication to other W3C groups and to the
      public. </p>
    <p>Publishing the First Public Working Draft triggers a Call for Exclusions,
      per <a href="">section
        4</a> of the <a href="">W3C
        Patent Policy</a> [<a href="">PUB33</a>].</p>
    <h4 id="revised-wd">7.3.2 Revised Public Working Drafts</h4>
    <p>A Working Group <em class="rfc2119">should</em> publish a Working Draft
      to the W3C Technical Reports page when there have been significant changes
      to the document that would benefit from review from beyond the Working
      Group<em class="rfc2119"></em>. </p>
    <p>If 6 months elapse without significant changes to a specification a
      Working Group <em class="rfc2119">should</em> publish a revised Working
      Draft, whose status section <em class="rfc2119">should</em> indicate
      reasons for the lack of change. </p>
    <p>To publish a revised Working draft, a Working Group </p>
      <li><em class="rfc2119">must</em> record the group's decision to request
        publication. Consensus is not required, as this is a procedural step,</li>
      <li><em class="rfc2119">must</em> provide public documentation of <a href="#substantive-change">substantive
          changes</a> to the technical report since the previous Working Draft,</li>
      <li><em class="rfc2119">should</em> provide public documentation of
        significant <a href="#editorial-change">editorial changes</a> to the
        technical report since the previous step,</li>
      <li><em class="rfc2119">should</em> report which, if any, of the Working
        Group's requirements for this document have changed since the previous
      <li><em class="rfc2119">should</em> report any changes in dependencies
        with other groups,</li>
    <p>Possible next steps:</p>
      <li><a href="#hb-wd">Revised Public Working Draft</a></li>
      <li><a href="#last-call">Candidate recommendation</a>.</li>
      <li><a href="#tr-end">Working Group Note</a></li>
    <h3 id="candidate-rec"><a name="last-call" id="last-call">7.4 Candidate
        Recommendation </a></h3>
    <p>To publish a Candidate recommendation, in addition to meeting the <a href="#transition-reqs">general
        requirements for advancement</a> a Working Group</p>
      <li><em class="rfc2119">must</em> show that the specification has met all
        Working Group requirements, or explain why the requirements have changed
        or been deferred,</li>
      <li><em class="rfc2119">must</em> document changes to dependencies during
        the development of the specification,</li>
      <li><em class="rfc2119">must</em> document how adequate <a href="#implementation-experience">
          implementation experience</a> will be demonstrated,</li>
      <li><em class="rfc2119">must</em> specify the deadline for comments, which
        <em class="rfc2119">must</em> be <strong>at least</strong> four weeks
        after publication, and <em class="rfc2119">should</em> be longer for
        complex documents,</li>
      <li>If the document has previously been published as a Candidate
        Recommendation, <em class="rfc2119">must</em> document the changes
        since the previous Candidate Recommendation, </li>
      <li><em class="rfc2119">must</em> show that the specification has received
        <a href="#wide-review">wide review</a>, and</li>
      <li><em class="rfc2119">may</em> identify features in the document that
        are considered "at risk". These features <em class="rfc2119">may</em>
        be removed before advancement to Recommendation without a requirement to
        publish a new Candidate Recommendation.</li>
    <p>The Director <em class="rfc2119">must</em> announce the publication of a
      Candidate Recommendation to other W3C groups and to the public. </p>
    <p> A Candidate Recommendation corresponds to a "Last Call Working Draft" as
      used in the <a href="">W3C
        Patent Policy</a> [<a href="">PUB33</a>].
      Publishing a Candidate Recommendation triggers a Call for Exclusions, per
      <a href="">section
        4</a> of the <a href="">W3C
        Patent Policy</a> [<a href="">PUB33</a>].</p>
    <p>Possible next steps:</p>
      <li>Return to <a href="#hb-wd">Working Draft</a></li>
      <li>Return to <a href="#last-call">Candidate Recommendation</a></li>
      <li><a href="#rec-publication">Request Recommendation status</a> (The
        expected next step)</li>
      <li><a href="#tr-end">Working Group Note</a></li>
    <p class="issue">Add an explanation of publishing a revised Candidate
      Recommendation. <a href="">ISSUE-59</a></p>
    <p>If there are any <a href="#substantive-change">substantive changes</a>
      made to a Candidate Recommendation other than to remove features
      explicitly identified as "at risk", the Working Group <em class="rfc2119">must</em>
      repeat the full process of publication as a Candidate Recommendation
      before the Working Group can request Recommendation status.</p>
    <p> <a href="">Advisory
        Committee</a> representatives <em class="rfc2119">may</em> <a href="">appeal</a>
      the decision to advance the technical report.</p>
    <h4 id="revised-cr">7.4.1 Revised Candidate Recommendation</h4>
    <h3 id="rec-publication">7.5 W3C Recommendation</h3>
    <p class="issue">A better explanation of how a document becomes a
      Recommendation is needed here.</p>
    <h4 id="for-all-recs"><a id="rec-requirements">7.5.1 For <strong>all</strong>
        W3C Recommendations</a></h4>
    <p>In addition to meeting the <a href="#transition-reqs">general
        requirements for advancement</a>,</p>
      <li>The Director <em class="rfc2119">must</em> announce the provisional
        approval of a Request for publication of a W3C Recommendation to the <a
      <li>The deadline for Advisory Committee review of the technical report <em
          class="rfc2119">must</em> be <strong>at least</strong> 28 days after
        the announcement of provisional approval to publish the Edited
        Recommendation as a W3C Recommendation,</li>
      <li>If there was any <a href=""
          rel="glossary" title="Definition of Dissent"><span class="dfn-instance">dissent</span></a>
        in Advisory Committee reviews, the Director <em class="rfc2119">must</em>
        publish the substantive content of the dissent to W3C and the general
        public, and <em class="rfc2119">must</em> <a href="">formally
          address</a> the comment at least 14 days before publication as a W3C
        Recommendation. In this case the <a href="">Advisory
          Committee</a> <em class="rfc2119">may</em> <a href="">appeal</a>
        the decision,</li>
      <li>The Director <em class="rfc2119">must</em> announce the publication
        of a W3C Recommendation to other W3C groups and to the public, and</li>
      <li>The "Status of the Document" <em class="rfc2119">must</em> reflect
        whether it is provisionally approved, or published as a W3C
    <h4 id="lcrec-publication">7.5.2 Publishing a Candidate Recommendation as a
      W3C Recommendation</h4>
    <p>To publish a Candidate Recommendation as a W3C Recommendation, a Working
      <li><em class="rfc2119">must</em> republish the document, identifying it
        as the basis of a Request for Recommendation,</li>
      <li><em class="rfc2119">must</em> show adequate <a href="#implementation-experience">implementation
      <li><em class="rfc2119">must</em> show that the document has received <a
          href="#wide-review">wide review,</a></li>
      <li><em class="rfc2119">must</em> show that all issues raised during the
        Candidate Recommendation review period have been <a href="">formally
      <li><em class="rfc2119">must </em>identify any substantive issues raised
        since the close of the review period by parties other than Advisory
        Committee representatives,</li>
      <li><em class="rfc2119">must</em> document how the testing and
        implementation requirements identified as part of the transition to
        Candidate Recommendation have been met,</li>
      <li><em class="rfc2119">must</em> identify where errata are tracked, and</li>
      <li><em class="rfc2119">may</em> remove features identified in the
        Candidate Recommendation document as "at risk" without repeating the
        transition to Candidate Recommendation.</li>
    <p>The Director</p>
      <li><span><em class="rfc2119">should not</em> provisionally approve a
          Request for publication of a W3C Recommendation less than 35 days
          after the publication of the Candidate Recommendation on which is it
          based [editor's note - this is to allow for the patent policy
          exclusion period to expire], and </span></li>
      <li><span><em class="rfc2119">may</em> provisionally approve a
          Recommendation with minimal implementation experience where there is a
          compelling reason to do so. In such a case, the Director <em class="rfc2119">should</em>
          explain the reasons for that decision. </span></li>
    <p>Possible next steps:</p>
      <li>A W3C Recommendation normally retains its status indefinitely. However
      <li><em class="rfc2119">may</em> be <a href="#rec-modify">republished as
          an Edited Recommendation</a>, or</li>
      <li><em class="rfc2119">may</em> be <a href="#rec-rescind">rescinded</a>.</li>
    <h3 id="rec-modify">7.6 Modifying a W3C Recommendation</h3>
    <p>The following sections discuss the management of errors and the process
      for making changes to a Recommendation.</p>
    <h4 id="errata">7.6.1 Errata Management</h4>
    <p>Tracking errors is an important part of a Working Group's ongoing care of
      a Recommendation; for this reason, the scope of a Working Group charter
      generally allows time for work after publication of a Recommendation. In
      this Process Document, the term "erratum" (plural "errata") refers to any
      class of mistake, from mere editorial to a serious error that may affect
      the conformance with the Recommendation by software or content (e.g.,
      content validity). <strong>Note:</strong> Before a document becomes a
      Recommendation, the W3C Process focuses on <a href="#substantive-change">substantive
        changes</a> (those related to prior reviews). After a document has been
      published as Recommendation, the W3C Process focuses on those changes to a
      technical report that might affect the conformance of content or deployed
    <p>Working Groups <span class="rfc2119">must</span> track errata on an
      "errata page." An errata page is a list of enumerated errors, possibly
      accompanied by corrections. Each Recommendation links to an errata page;
      see the Team's <a href="">Publication
    <p>A correction is first "proposed" by the Working Group. A correction
      becomes part of the Recommendation by the process described below.</p>
    <p>A Working Group <span class="rfc2119">should</span> keep their errata
      pages up-to-date, as errors are reported by readers and implementers. A
      Working Group <span class="rfc2119">must</span> report errata page
      changes to interested parties, notably when corrections are proposed or
      incorporated into an Edited Recommendation, according to the Team's
    <h4 id="correction-classes">7.6.2 Classes of Changes to a Recommendation</h4>
    <p>This document distinguishes the following classes of changes to a
      <dt>1. No changes to text content</dt>
      <dd>These changes include fixing broken links, style sheets or invalid
      <dt>2. Corrections that do not affect conformance</dt>
      <dd>Editorial changes or clarifications that do not change the technical
        content of the specification.</dd>
      <dt>3. Corrections that do not add new features</dt>
      <dd>These changes <span class="rfc2119">may</span> affect conformance to
        the Recommendation. A change that affects conformance is one that:
          <li>turns conforming data, processors, or other conforming agents into
            non-conforming agents, or</li>
          <li>turns non-conforming agents into conforming ones, or</li>
          <li>clears up an ambiguity or under-specified part of the
            specification in such a way that an agent whose conformance was once
            unclear becomes clearly conforming or non-conforming.</li>
      <dt>4. New features</dt>
    <p>The first two classes of change require no technical review of the
      proposed changes. A Working Group <span class="rfc2119">may</span>
      request republication of a Recommendation for these classes of change, or
      W3C <span class="rfc2119">may</span> republish a Recommendation with this
      class of change. The modified Recommendation is published according to the
      Team's requirements, including <a href="">Publication
        Rules</a> [<a href="refs.html#ref-pubrules">PUB31</a>] and the <a href="">Requirements
        for modification of W3C Technical Reports</a> [PUB@@].</p>
    <p>For the third class of change, a Working Group <span class="rfc2119">must</span>
      request publication of an <a href="#rec-edited">Edited Recommendation</a>.</p>
    <p>For the fourth class of change, which introduces a new feature or
      features, W3C <span class="rfc2119">must</span> follow the full process
      of <a href="#rec-advance">advancing a technical report to Recommendation</a>.</p>
    <h4 id="revised-rec">7.6.3 Revising a Recommendation</h4>
    <p>To publish an Edited Recommendation as a W3C Recommendation, in addition
      to meeting the <a href="#rec-requirements">requirements for all W3C
        Recommendations</a>, a Working Group</p>
      <li><em class="rfc2119">must</em> republish the document, identifying it
        as the basis of a Request for Recommendation,</li>
      <li><em class="rfc2119">must</em> show that the document has received <a
          href="#wide-review">wide review</a>, and </li>
      <li><em class="rfc2119">should</em> address all errata.</li>
    <h3 id="tr-end">7.7 Publishing a Working Group or Interest Group Note</h3>
    <p>Working Groups and Interest Groups publish material that is not a formal
      specification as Notes. This may include supporting documentation for a
      specification, such as requirements, use cases, good practices and the
    <p>Work on a technical report <em class="rfc2119">may</em> cease at any
      time. Work <em class="rfc2119 new">should</em> cease if W3C or a Working
      Group determines that it cannot productively carry the work any further.
      If the Director <a href="">closes
        a Working Group</a> W3C <em class="rfc2119">must </em> publish any
      unfinished specifications on the Recommendation track as Working Group
      Notes. If a Working group decides, or the Director requires, the Working
      Group to discontinue work on a technical report before completion, the
      Working Group <em class="rfc2119">should</em> publish the document as a
      Working Group Note. </p>
    <p>In order to publish a Note a Working Group or Interest Group: </p>
      <li><em class="rfc2119">must</em> record the group's decision to request
        publication as a Note, and</li>
      <li><em class="rfc2119">should</em> public documentation of significant
        changes to the technical report since the previous publication.</li>
    <p>Possible next steps:</p>
      <li>End state: A technical report <em class="rfc2119">may</em> remain a
        Working Group Note indefinitely</li>
      <li>A Working Group <em class="rfc2119">may</em> resume work on the
        technical report at any time, at the maturity level the specification
        had before publication as a Note</li>
    <p>The <a href="">W3C Patent
        Policy</a> [<a href="">PUB33</a>]
      does not specify any licensing requirements or commitments for Working
      Group Notes, only for W3C Recommendations.</p>
    <h3 id="rec-rescind">7.8 &gt;Rescinding a W3C Recommendation</h3>
    <p>W3C <em class="rfc2119">may</em> rescind a Recommendation, for example
      if the Recommendation contains many errors that conflict with a later
      version or if W3C discovers burdensome patent claims that affect
      implementers and cannot be resolved; see the <a href="">W3C
        Patent Policy</a> [<a href="">PUB33</a>]
      and in particular <a href="">section
        5</a> (bullet 10) and <a href="">section
        7.5</a>. A Working Group <em class="rfc2119">may</em> request the
      Director to rescind a Recommendation which was a deliverable, or the
      Director <em class="rfc2119">may</em> directly propose to rescind a
      Recommendation. </p>
    <p>W3C only rescinds entire specifications. To rescind some <em>part</em>
      of a Recommendation, W3C follows the process for <a href="#rec-modify">modifying
        a Recommendation</a>.</p>
    <p>Once W3C has published a Rescinded Recommendation, future W3C technical
      reports <em class="rfc2119">must not</em> include normative references to
      that technical report.</p>
    <p>To propose rescinding a W3C Recommendation, a Working Group or the
      <li><em class="rfc2119">must</em> publish rationale for rescinding the
      <li><em class="rfc2119">should</em> document known implementation.</li>
    <p>In addition a Working Group requesting to rescind</p>
      <li><em class="rfc2119">must</em> show that the request to rescind has
        received <a href="#wide-review">wide review</a></li>
      <li><em class="rfc2119">should</em> show that the request to rescind is
        based on public comment</li>
    <p>In addition the Director, if proposing to rescind</p>
      <li><em class="rfc2119">must</em> show that the request to rescind is
        based on public comment</li>
    <p>The Director <em class="rfc2119">must</em> announce the proposal to
      rescind a W3C Recommendation to other W3C groups, the public, and the <a
        Committee</a>. The announcement <em class="rfc2119">must</em>:</p>
      <li>indicate that this is a Proposal to Rescind a Recommendation</li>
      <li>specify the deadline for review comments, which <em class="rfc2119">must</em>
        be at least <span class="time-interval">four weeks after announcing</span>
        the proposal to rescind.</li>
      <li>identify known dependencies and solicit review from all dependent
        Working Groups;</li>
      <li>solicit public review.</li>
    <p>If there was any <a href=""
        rel="glossary" title="Definition of Dissent"><span class="dfn-instance">dissent</span></a>
      in Advisory Committee reviews, the Director <em class="rfc2119">must</em>
      publish the substantive content of the dissent to W3C <strong>and the
        public</strong>, and <em class="rfc2119">must</em> <a href="">formally
        address</a> the comment at least 14 days before publication as a
      Rescinded Recommendation. In this case the <a href="">Advisory
        Committee</a> <em class="rfc2119">may</em> <a href="#ACAppeal">appeal</a>
      the decision.</p>
    <h3 id="good-practice">Further reading</h3>
    <p>Refer to <a href="">"How to
        Organize a Recommendation Track Transition"</a> in the <a href="">Member
        guide</a> for practical information about preparing for the reviews and
      announcements of the various steps, and <a href="">tips
        on getting to Recommendation faster</a> [<a href="">PUB27</a>].</p>
    <div class="noprint">
      <div class="navbar"> <map name="navbar-bottom" title="Navigation Bar" id="navbar-bottom">
          <p>[<a accesskey="c" rel="Contents" href="#toc">contents</a>] </p>