Collapsed 7.4.1a and 7.4.1b so there is just Working Draft as a status, and not "Heartbeat WD". Also changed the SVG diagram to match.
authorcharles
Wed, 18 Sep 2013 17:48:49 -0400
changeset 21 b491807959c9
parent 20 2571dd7597b3
child 22 e5acd8dbabbb
Collapsed 7.4.1a and 7.4.1b so there is just Working Draft as a status, and not "Heartbeat WD". Also changed the SVG diagram to match.
ISSUE-40
tr.html
--- a/tr.html	Wed Sep 18 17:26:32 2013 -0400
+++ b/tr.html	Wed Sep 18 17:48:49 2013 -0400
@@ -1,17 +1,17 @@
 <!DOCTYPE html>
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="content-type">
    <title>A Rec-track Process Draft Proposal</title>
    <link href="http://www.w3.org/StyleSheets/TR/base.css" 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="https://www.w3.org/StyleSheets/TR/W3C-ED" rel="stylesheet">
    <!--[if lt IE 9]><script src='undefined://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]-->
  </head>
  <body>
    <div class="head">
      <p> <a href="http://www.w3.org/"><img alt="W3C" src="http://www.w3.org/Icons/w3c_home"
            height="48"
            width="72"></a>
      </p>
      <h1 class="title" id="title">Recommendation Track Process, draft proposal</h1>
      <h2 id="w3c-working-draft-20-september-2012"><abbr title="World Wide Web Consortium"></abbr>Editors'
-        Draft 22 July 2013</h2>
      <dl>
        <!--dt>Latest published version:</dt>
        <dd><a href="http://www.w3.org/TR/HTML-longdesc">http://www.w3.org/TR/HTML-longdesc</a></dd-->
        <dt>Latest editor's draft:</dt>
        <dd> <a href="https://dvcs.w3.org/hg/AB/raw-file/default/tr.html">https://dvcs.w3.org/hg/AB/raw-file/default/tr.html</a></dd>
        <dt>Editor:</dt>
        <dd><a href="mailto:[email protected]">Charles (McCathie) Nevile</a>,
          <a href="http://www.yandex.ru">Яндекс</a>—<a href="http://yandex.com">Yandex</a></dd>
      </dl>
      <p class="copyright"> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>
        © 2013 <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup>
        (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>,
        <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
        <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>),
+        Draft 18 September 2013</h2>
      <dl>
        <!--dt>Latest published version:</dt>
        <dd><a href="http://www.w3.org/TR/HTML-longdesc">http://www.w3.org/TR/HTML-longdesc</a></dd-->
        <dt>Latest editor's draft:</dt>
        <dd> <a href="https://dvcs.w3.org/hg/AB/raw-file/default/tr.html">https://dvcs.w3.org/hg/AB/raw-file/default/tr.html</a></dd>
        <dt>Editor:</dt>
        <dd><a href="mailto:[email protected]">Charles (McCathie) Nevile</a>,
          <a href="http://www.yandex.ru">Яндекс</a>—<a href="http://yandex.com">Yandex</a></dd>
      </dl>
      <p class="copyright"> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>
        © 2013 <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup>
        (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>,
        <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
        <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>),
         All Rights Reserved. <abbr title="World Wide Web Consortium">W3C</abbr>
        <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
        <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>,
        <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document
           use</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-software">software
           licensing</a> rules apply. </p>
      <hr> </div>
    <div class="noprint">
      <div class="navbar">
        <p>This is a revised draft proposal to replace the <a href="http://www.w3.org/2005/10/Process-20051014/tr.html">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 on 22 July 2013. This document is an editor's draft for the
          Advisory Board but does not yet fully reflect consensus. </p>
        <p>An earlier version was first proposed to the W3C Advisory Board on 13
          May 2013 as a possible replacement for the <a href="http://www.w3.org/2005/10/Process-20051014/tr.html">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 on 17-18 September 2013. This document is an editor's draft for
          the Advisory Board but does not yet fully reflect consensus. </p>
        <p>An earlier version was first proposed to the W3C Advisory Board on 13
          May 2013 as a possible replacement for the <a href="http://www.w3.org/2005/10/Process-20051014/tr.html">current
             chapter 7 of the W3C process document</a>, and a <a href="http://yadi.sk/d/Zikwkr385JG8f">subsequent
             version</a> was <a href="http://lists.w3.org/Archives/Public/public-w3process/2013May/0023.html">proposed</a>
          to the <a href="http://www.w3.org/community/w3process/">W3C Process
            Community Group</a> on 29 May 2013 by Charles Nevile &lt;<a href="mailto:[email protected]">[email protected]</a>
          for discussion. The Advisory Board has agreed to make all editor's
          drafts 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="http://www.w3.org/2005/10/Process-20051014/processdoc.html#GAProcess">existing
-            process for such changes</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, Tantek
          Çelik, Ian Hickson, Ian Jacobs, Ralph Swick, Anne van Kesteren, and
          many people I have forgotten to acknowledge for suggestions, comments
          and discussions the helped me sort out my thinking, and to Ora Lassila
          for 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="http://www.w3.org/community/w3process/">W3C
+            process for such changes</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, Ian
          Hickson, Ian Jacobs, Ralph Swick, Anne van Kesteren, and many people I
          have forgotten to acknowledge for suggestions, comments and
          discussions the helped me sort out my thinking, and to Ora Lassila for
          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="http://www.w3.org/community/w3process/">W3C
             Process Community Group</a>. Issues related to this proposal are
          tracked in that group's issue tracker using the product "<a href="https://www.w3.org/community/w3process/track/products/1">Document
-            Lifecycle (chapter 7)</a>"</p>
        Major changes:
        <ul>
          <li>Last Call and Candidate Recommendation have been collapsed
            together. Some of the requirements are therefore enforced earlier in
            the process.</li>
          <li>Proposed Recommendation is no longer a separate step. Advisory
            Committee review now begins at the same time as Last Call Candidate
            recommendation, and ends 4 weeks after the Working group has
            provisional approval for a Request to publish as a W3C
            Recommendation.</li>
          <li>The director is required to address AC review comments <strong>publicly</strong>,
            2 weeks <em>before</em> publication of a Recommendation.</li>
          <li>The chapter is about half the size it was. </li>
          <li>And it is in HTML5</li>
        </ul>
        <p>Editorially, I have tried to rationalize requirements, and clarify
          who is responsible for meeting them. I have also actively removed
          advice and general statements to keep this version short.</p>
      </div>
    </div>
    <h2>7 <a name="Reports" id="Reports">W3C Technical Report Development
        Process</a></h2>
    <p>The W3C technical report development process is the set of steps and
      requirements followed by W3C <a href="http://www.w3.org/2005/10/Process-20051014/groups#GroupsWG">Working
+            Lifecycle (chapter 7)</a>"</p>
        Major changes:
        <ul>
          <li>Last Call and Candidate Recommendation have been collapsed
            together. Some of the requirements are therefore enforced earlier in
            the process.</li>
          <li>Proposed Recommendation is no longer a separate step. Advisory
            Committee review now begins at the same time as Last Call Candidate
            recommendation, and ends 4 weeks after the Working group has
            provisional approval for a Request to publish as a W3C
            Recommendation.</li>
          <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>
        </ul>
        <p>Editorially, I have tried to rationalize requirements, and clarify
          who is responsible for meeting them. I have also actively removed
          advice and general statements to keep this version short.</p>
        <p>Note that I have generally not renumbered sections that are deleted
          or moved, which explains why some items are not sequentially numbered.</p>
      </div>
    </div>
    <h2>7 <a name="Reports" id="Reports">W3C Technical Report Development
        Process</a></h2>
    <p>The W3C technical report development process is the set of steps and
      requirements followed by W3C <a href="http://www.w3.org/2005/10/Process-20051014/groups#GroupsWG">Working
         Groups</a> to standardize Web technology. The W3C technical report
      development process is designed to </p>
    <ul>
      <li>support multiple specification development methodologies</li>
      <li>maximize <a href="http://www.w3.org/2005/10/Process-20051014/policies.html#def-consensus"
          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>
    </ul>
    <p>See also the licensing goals for W3C Recommendations in <a href="http://www.w3.org/Consortium/Patent-Policy#sec-Licensing">section
         2</a> of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C
        Patent Policy</a> [<a href="http://www.w3.org/2005/10/Process-20051014/refs.html#ref-patentpolicy">PUB33</a>].
-      </p>
    <p>
      <svg xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg"
        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">
          <polygon points="-4,5 -4,-58 397,-58 397,5 -4,5" stroke="white" fill="white"></polygon>
          <g class="node" id="node1">
            <ellipse ry="18" rx="35.9954" cy="-18" cx="36" stroke="black" fill="none"></ellipse>
            <text font-size="14.00" font-family="Times,serif" y="-14.3" x="36" text-anchor="middle">FPWD</text>
          </g>
          <g class="node" id="node2">
            <ellipse ry="18" rx="38.1938" cy="-18" cx="147" stroke="black" fill="none"></ellipse>
            <text font-size="14.00" font-family="Times,serif" y="-14.3" x="147"
              text-anchor="middle">HBWD</text>
          </g>
          <g class="edge" id="edge1">
            <path d="M71.788,-18C80.2068,-18 89.3509,-18 98.251,-18" 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="node3">
            <ellipse ry="18" rx="37.8943" cy="-18" cx="260" stroke="black" fill="none"></ellipse>
            <text font-size="14.00" font-family="Times,serif" y="-14.3" x="260"
              text-anchor="middle">LCCR</text>
          </g>
          <g class="edge" id="edge3">
            <path d="M183.121,-11.6719C193.029,-11.2434 203.944,-11.1413 214.332,-11.3656"
              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.487,-24.3013C214.621,-24.7432 203.717,-24.8587 193.308,-24.6478"
              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>
            <text font-size="14.00" font-family="Times,serif" y="-14.3" x="363"
              text-anchor="middle">REC</text>
          </g>
          <g class="edge" id="edge6">
            <path d="M297.749,-18C306.33,-18 315.485,-18 324.114,-18" 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>
    <h3>Table of Contents</h3>
    <ul id="mozToc">
      <!--mozToc h3 1 h4 2 h5 3 h6 4-->
      <li><a href="#mozTocId357269">General requirements for Technical Reports</a></li>
      <li><a href="#mozTocId185794">7.1 Maturity Levels</a></li>
      <li><a href="#mozTocId310665">7.2 General Requirements for Advancement on
          the Recommendation Track</a>
        <ul>
          <li><a href="#mozTocId303350">7.2.1 (from 7.6.2) Changes to a
              Specification</a></li>
          <li><a href="#mozTocId828599">7.2.2 Wide Review</a></li>
        </ul>
      </li>
      <li><a href="#mozTocId89649">7.3 Reviews and Review Responsibilities</a></li>
      <li><a href="#mozTocId510412">7.4 Advancing a Technical Report to
          Recommendation</a>
        <ul>
          <li><a href="#mozTocId403357">7.4.1.a First Public Working Draft</a></li>
          <li><a href="#mozTocId918390">7.4.1.b "Heartbeat" Working Draft</a></li>
          <li><a href="#mozTocId200837">7.4.2 Last Call Candidate Recommendation</a></li>
          <li><a href="#mozTocId840424">7.4.5 Publication of a W3C
              Recommendation</a>
            <ul>
              <li><a href="#mozTocId978114">Publishing a Last Call Candidate
                  Recommendation as a W3C Recommendation</a></li>
              <li><a href="#mozTocId128164">Publishing an Edited Recommendation
                  (See also Modifying a Recommendation below)</a></li>
              <li><a href="#mozTocId889945">For all W3C Recommendations</a></li>
            </ul>
          </li>
        </ul>
      </li>
      <li><a href="#mozTocId763911">7.5 Publishing a Working Group or Interest
          Group Note</a></li>
      <li><a href="#mozTocId924165">7.6 Modifying a W3C Recommendation</a>
        <ul>
          <li><a href="#mozTocId436763">7.6.1 Errata Management</a></li>
        </ul>
      </li>
      <li><a href="#mozTocId203654">7.7 Rescinding a W3C Recommendation</a></li>
      <li><a href="#mozTocId957988">Good practices</a></li>
    </ul>
    <h3>General requirements for Technical Reports</h3>
    <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="http://www.w3.org/TR/">index
+      </p>
    <p>
      <svg xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg"
        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="node2">
            <ellipse ry="18" rx="38.1938" cy="-18" cx="147" stroke="black" fill="none"></ellipse>
            <text font-size="14.00" font-family="Times,serif" y="-14.3" x="147"
              text-anchor="middle">WD</text>
          </g>
          <g class="edge" id="edge1">
            <path d="M71.788,-18C80.2068,-18 89.3509,-18 98.251,-18" 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="node3">
            <ellipse ry="18" rx="37.8943" cy="-18" cx="260" stroke="black" fill="none"></ellipse>
            <text font-size="14.00" font-family="Times,serif" y="-14.3" x="260"
              text-anchor="middle">LCCR</text>
          </g>
          <g class="edge" id="edge3">
            <path d="M183.121,-11.6719C193.029,-11.2434 203.944,-11.1413 214.332,-11.3656"
              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.487,-24.3013C214.621,-24.7432 203.717,-24.8587 193.308,-24.6478"
              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>
            <text font-size="14.00" font-family="Times,serif" y="-14.3" x="363"
              text-anchor="middle">REC</text>
          </g>
          <g class="edge" id="edge6">
            <path d="M297.749,-18C306.33,-18 315.485,-18 324.114,-18" 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>
    <h3>Table of Contents</h3>
    <ul id="mozToc">
      <!--mozToc h3 1 h4 2 h5 3 h6 4-->
      <li><a href="#mozTocId951868">General requirements for Technical Reports</a></li>
      <li><a href="#mozTocId233783">7.1 Maturity Levels</a></li>
      <li><a href="#mozTocId44043">7.2 General Requirements for Advancement on
          the Recommendation Track</a>
        <ul>
          <li><a href="#mozTocId52529">7.2.2 Wide Review</a></li>
          <li><a href="#mozTocId864535">7.2.3 Implementation Experience</a></li>
        </ul>
      </li>
      <li><a href="#mozTocId157737">7.3 Reviews and Review Responsibilities</a></li>
      <li><a href="#mozTocId302600">7.4 Advancing a Technical Report to
          Recommendation</a>
        <ul>
          <li><a href="#mozTocId226623">7.4.1.a First Public Working Draft</a></li>
          <li><a href="#mozTocId442082">7.4.1.b "Heartbeat" Working Draft</a></li>
          <li><a href="#mozTocId583091">7.4.2 Last Call Candidate Recommendation</a></li>
          <li><a href="#mozTocId255357">7.4.5 Publication of a W3C
              Recommendation</a>
            <ul>
              <li><a href="#mozTocId783340">Publishing a Last Call Candidate
                  Recommendation as a W3C Recommendation</a></li>
              <li><a href="#mozTocId17935">Publishing an Edited Recommendation
                  (See also Modifying a Recommendation below)</a></li>
              <li><a href="#mozTocId706375">For all W3C Recommendations</a></li>
            </ul>
          </li>
        </ul>
      </li>
      <li><a href="#mozTocId995044">7.5 Publishing a Working Group or Interest
          Group Note</a></li>
      <li><a href="#mozTocId968883">7.6 Modifying a W3C Recommendation</a>
        <ul>
          <li><a href="#mozTocId784400">7.6.1 Errata Management</a></li>
          <li><a href="#mozTocId12613">7.6.2 Classes of Changes to a
              Recommendation</a></li>
        </ul>
      </li>
      <li><a href="#mozTocId618407">7.7 Rescinding a W3C Recommendation</a></li>
      <li><a href="#mozTocId577828">Good practices</a></li>
    </ul>
    <h3>General requirements for Technical Reports</h3>
    <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="http://www.w3.org/TR/">index
         of W3C technical reports</a> [<a href="http://www.w3.org/2005/10/Process-20051014/refs.html#ref-doc-list">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> <span class="from">(was in
        7.8)</span> clearly indicate its <a href="#maturity-levels">maturity
        level</a>, and <em id="DocumentStatus" class="rfc2119">must</em> <span
        class="from">(was
         in 7.8.1)</span> include a section about the status of the document. The
      status section</p>
    <ul>
      <li><em class="rfc2119 changed">must</em> <span class="from">(was should
          in 7.8.1)</span> state who developed the specification, </li>
      <li><em class="rfc2119 changed">must</em> <span class="from">(was should
          in 7.8.1)</span> 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
        W3C,</li>
      <li><em class="rfc2119">should</em> <span class="from">(was in 7.8.1)</span>
        include expectations about next steps, and</li>
      <li><em class="rfc2119">should</em> <span class="from">(was in 7.8.1)</span>
        explain or link to an explanation of significant changes from the
        previous version.</li>
    </ul>
    <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> <span class="from">(was
         in 7.8)</span> 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> <span class="from">(was
@@ -24,20 +24,19 @@
           Objections</a>.</li>
      <li><em class="rfc2119 changed">should</em> <span class="from">(was must
          for CR+ in 7.2)</span> report which, if any, of the Working Group's
        requirements for this document have changed since the previous step.</li>
      <li><em class="rfc2119 changed">should</em> <span class="from">(was must
          for CR+ in 7.2)</span> report any changes in dependencies with other
        groups.</li>
      <li class="new"><em class="rfc2119">should</em> document known
        implementation.</li>
    </ul>
    <h4>7.2.2 <a id="wide-review">Wide Review</a></h4>
    <p>The requirements for wide review 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,
      particularly in light of the listed dependencies, and how the Working
      Group has solicited and responded to review. In particular, the Director
      is likely to consider the record of requests to and responses from groups
      identified as dependencies in the charter, as well as seeking evidence of
      clear communication to the general public about appropriate times and
      which content to review. </p>
    <p>As an example, inviting review of new or significantly revised sections
      published in Heartbeat 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 Last Call 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.3 Implementation Experience</h4>
    <p>Implementation experience is required to show that a specification is
      sufficiently clear, complete, and relevant to market needs 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 adequate implementation
      experience the Director will consider (though not be limited to):</p>
    <ul>
      <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
        specification?</li>
      <li>are implementations publicly deployed?</li>
      <li>is there implementation experience at all levels of the
        specification's ecosystem (creation, consuming, publishing…)?</li>
    </ul>
    <h3>7.3 <a name="doc-reviews" id="doc-reviews">Reviews and Review
        Responsibilities</a></h3>
    <p>A document is available for review from the moment it is first published.
      Working Groups <em class="rfc2119">should</em> <a href="http://www.w3.org/2005/10/Process-20051014/policies.html#formal-address">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 <span class="from">(was
      should)</span> are often reluctant to make <a href="#substantive-change">substantive
       changes</a> to a mature document, <span class="new">particularly if this
      would cause significant compatibility problems due to existing
      implementation</span>. Worthy ideas <em class="rfc2119">should</em> be
    recorded even when not incorporated into a mature document.
    <h3>7.4 <a name="rec-advance" id="rec-advance">Advancing a Technical Report
        to Recommendation</a></h3>
    <p>W3C follows these steps when advancing a technical report to
      Recommendation.</p>
    <ol>
      <li><a href="#first-wd">Publication of the First Public Working Draft</a>,</li>
      <li><a href="#hb-wd">Publication of zero or more "Heartbeat" Public
          Working Drafts</a>.</li>
      <li><a href="#last-call">Publication of a Last Call Candidate
          Recommendation</a>.</li>
      <li><a href="#rec-publication">Publication as a Recommendation</a>.</li>
    </ol>
    <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> refuse permission 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>
      <span class="from">(was in 7.4.6)</span> inform the <a href="http://www.w3.org/2005/10/Process-20051014/organization.html#AC">Advisory
-        Committee</a> and group Chairs when a technical report has been refused
      permission to advance in maturity level and returned to a Working Group
      for further work.</p>
    <h4>7.4.1.a <a name="first-wd" id="first-wd">First Public Working Draft</a>
    </h4>
    <p>To publish a First Public Working draft, in addition to the general
      requirements for advancement a Working Group</p>
    <ul>
      <li> <em class="rfc2119">should</em> document the extent of consensus on
        the content, and outstanding issues on which the Working Group does not
        have consensus.</li>
      <li> <em class="rfc2119">may</em> request publication of a Working Draft
        even if it is unstable and does not meet all Working Group requirements.</li>
    </ul>
    <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> This publication triggers a patent disclosure request, as per <a href="http://www.w3.org/Consortium/Patent-Policy#sec-disclosure-requests">section
+        Committee</a> and group Chairs when a technical report has been refused
      permission to advance in maturity level and returned to a Working Group
      for further work.</p>
    <h4>7.4.1.a <a name="first-wd" id="first-wd">Working Draft</a> </h4>
    <p>To publish the First Public Working Draft of a document, in addition to
      meeting the <a href="#transition-reqs">general requirements for
        advancement</a> a Working Group</p>
    <ul>
      <li> <em class="rfc2119">should</em> document the extent of consensus on
        the content, and outstanding issues on which the Working Group does not
        have consensus.</li>
      <li> <em class="rfc2119">may</em> request publication of a Working Draft
        even if it is unstable and does not meet all Working Group requirements.</li>
    </ul>
    <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 patent disclosure
      request, as per <a href="http://www.w3.org/Consortium/Patent-Policy#sec-disclosure-requests">section
         6.3</a> of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C
        Patent Policy</a> [<a href="http://www.w3.org/2005/10/Process-20051014/refs.html#ref-patentpolicy">PUB33</a>].
       See also <a href="http://www.w3.org/Consortium/Patent-Policy/#sec-exclusion-with">section
 4.1
-        of the W3C Patent Policy</a> [<a href="http://www.w3.org/2005/10/Process-20051014/refs.html#ref-patentpolicy">PUB33</a>]
      for information about the policy implications of the First Public Working
      Draft. </p>
    <p>Possible next steps:</p>
    <ul>
      <li><a href="#hb-wd">"Heartbeat" Working Draft</a></li>
      <li><a href="#last-call">Last Call - Candidate recommendation</a>.</li>
      <li><a href="#tr-end">Working Group Note</a></li>
    </ul>
    <h4>7.4.1.b <a name="hb-wd" id="hb-wd">"Heartbeat" Working Draft</a></h4>
    <p class="new">A working group <em class="rfc2119">should</em> publish a
      "Heartbeat" Public Working Draft every 6 months, or when there have been
      significant changes to the document that would benefit from review from
      beyond the Working Group<em class="rfc2119"></em>.<span class="from">(was
        must in @@ch4?)</span> </p>
    <p>A Heartbeat Working Draft is not an advancement in maturity level. To
      publish a Heartbeat Working draft, a Working Group <span class="from">(copied
-        since this is not a new maturity level)</span> </p>
    <ul>
      <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
        step.</li>
      <li><em class="rfc2119">should</em> report any changes in dependencies
        with other groups.</li>
      <li><em class="rfc2119">should</em> document the extent of consensus on
        the content, and outstanding issues on which the Working Group does not
        have consensus.</li>
      <li><em class="rfc2119">may</em> request publication of a Working Draft
        even if it is unstable and does not meet all Working Group requirements.</li>
    </ul>
    <p>Possible next steps:</p>
    <ul>
      <li><a href="#hb-wd">"Heartbeat" Working Draft</a></li>
      <li><a href="#last-call">Last Call - Candidate recommendation</a>.</li>
      <li><a href="#tr-end">Working Group Note</a></li>
    </ul>
    <h4>7.4.2 <a name="last-call" id="last-call">Last Call Candidate
        Recommendation </a></h4>
    <p>To publish a Last Call Candidate recommendation, in addition to the
      general requirements for advancement a Working Group</p>
    <ul>
      <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 class="new"><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 changed">must</em> <span class="from">(was should)</span>
        be at least four weeks after publication, <span class="new">and <em class="rfc2119">should</em>
          be longer for complex documents.</span></li>
      <li class="new">If the document has previously been published as a Last
        Call Candidate Recommendation, <em class="rfc2119">must</em> document
        the changes since the previous Last Call Candidate Recommendation. </li>
      <li class="changed"><em class="rfc2119">must</em> show that the
        specification has received <a href="#wide-review">wide review</a>.</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 Last Call Candidate Recommendation.</li>
    </ul>
    <p>The Director <em class="rfc2119">must</em> announce the publication of a
      Last Call Candidate Recommendation to other W3C groups and to the public.
    </p>
    <p> This publication triggers a patent disclosure request, as per <a href="http://www.w3.org/Consortium/Patent-Policy#sec-disclosure-requests">section
+        of the W3C Patent Policy</a> [<a href="http://www.w3.org/2005/10/Process-20051014/refs.html#ref-patentpolicy">PUB33</a>]
      for information about the policy implications of the First Public Working
      Draft. </p>
    <p class="new">A working group <em class="rfc2119">should</em> publish a
      Working Draft to the W3C Technical Reports page every 6 months, or sooner
      when there have been significant changes to the document that would
      benefit from review from beyond the Working Group<em class="rfc2119"></em>.<span
        class="from">(was
+        must in @@ch4?)</span> </p>
    <p>To publish a Working draft, a Working Group <span class="from">(copied
        since this is not a new maturity level)</span> </p>
    <ul>
      <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
        step.</li>
      <li><em class="rfc2119">should</em> report any changes in dependencies
        with other groups.</li>
      <li><em class="rfc2119">should</em> document the extent of consensus on
        the content, and outstanding issues on which the Working Group does not
        have consensus.</li>
      <li><em class="rfc2119">may</em> request publication of a Working Draft
        even if it is unstable and does not meet all Working Group requirements.</li>
    </ul>
    <p>Possible next steps:</p>
    <ul>
      <li><a href="#hb-wd">"Heartbeat" Working Draft</a></li>
      <li><a href="#last-call">Last Call - Candidate recommendation</a>.</li>
      <li><a href="#tr-end">Working Group Note</a></li>
    </ul>
    <h4>7.4.2 <a name="last-call" id="last-call">Last Call Candidate
        Recommendation </a></h4>
    <p>To publish a Last Call Candidate recommendation, in addition to meeting
      the <a href="#transition-reqs">general requirements for advancement</a> a
      Working Group</p>
    <ul>
      <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 class="new"><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 changed">must</em> <span class="from">(was should)</span>
        be at least four weeks after publication, <span class="new">and <em class="rfc2119">should</em>
          be longer for complex documents.</span></li>
      <li class="new">If the document has previously been published as a Last
        Call Candidate Recommendation, <em class="rfc2119">must</em> document
        the changes since the previous Last Call Candidate Recommendation. </li>
      <li class="changed"><em class="rfc2119">must</em> show that the
        specification has received <a href="#wide-review">wide review</a>.</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 Last Call Candidate Recommendation.</li>
    </ul>
    <p>The Director <em class="rfc2119">must</em> announce the publication of a
      Last Call Candidate Recommendation to other W3C groups and to the public.
    </p>
    <p> This publication triggers a patent disclosure request, as per <a href="http://www.w3.org/Consortium/Patent-Policy#sec-disclosure-requests">section
         6.3</a> of the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C
        Patent Policy</a> [<a href="http://www.w3.org/2005/10/Process-20051014/refs.html#ref-patentpolicy">PUB33</a>].
       See also <a href="http://www.w3.org/Consortium/Patent-Policy/#sec-exclusion-with">section
 4.1
         of the W3C Patent Policy</a> [<a href="http://www.w3.org/2005/10/Process-20051014/refs.html#ref-patentpolicy">PUB33</a>]
      for information about the policy implications of the Candidate
      Recommendation. </p>
    <p>Possible next steps:</p>
    <ul>
      <li>Return to <a href="#hb-wd">Heartbeat Working Draft</a></li>
      <li>Return to <a href="#last-call">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>
    </ul>
    <p class="new">If there are any <a href="#substantive-change">substantive
        changes</a> made to a Last Call 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 Last Call Candidate
      Recommendation before the Working Group can request Recommendation status.</p>
    <p> <a href="http://www.w3.org/2005/10/Process-20051014/organization.html#AC">Advisory
         Committee</a> representatives <em class="rfc2119">may</em> <a href="http://www.w3.org/2005/10/Process-20051014/acreview.html#ACAppeal">appeal</a>
      the decision to advance the technical report.</p>
    <h4>7.4.5 <a name="rec-publication" id="rec-publication">Publication of a
        W3C Recommendation</a></h4>
    <h5><a name="lcrec-publication" id="lcrec-publication">Publishing a Last
        Call Candidate Recommendation as a W3C Recommendation</a></h5>
    <p>To publish a Last Call Candidate Recommendation as a W3C Recommendation,
      a Working Group</p>
    <ul>
      <li class="new"><em class="rfc2119">must</em> republish the document,
        identifying it as the basis of a Request for Recommendation.</li>
      <li><span class="changed"><em class="rfc2119">must</em> show adequate <a
            href="#implementation-experience">implementation
-            experience</a>. </span><span class="from">(said preferably should
          be two interoperable implementations...)</span> <span class="issue">This
-          requirement is liable to change. It is tracked in <a href="https://www.w3.org/community/w3process/track/issues/26">ISSUE-26</a>
          and <a href="https://www.w3.org/community/w3process/track/issues/27">ISSUE-27</a></span></li>
      <li><em class="rfc2119">must</em> show that the document has received <a
          href="#wide-review">wide
+            experience</a>.</span><span class="from">(said preferably should be
          two interoperable implementations...)</span></li>
      <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
        Last Call Candidate Recommendation review period have been formally
        addressed.</li>
      <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 <span class="from">(was in 7.3)</span></li>
      <li class="new"><em class="rfc2119">must</em> document how the testing and
        implementation requirements identified as part of the transition to Last
        Call Candidate Recommendation have been met.</li>
      <li class="new"><em class="rfc2119">must</em> identify where errata are
        tracked.</li>
      <li class="new"><em class="rfc2119">should</em> document known
        implementation.</li>
      <li><em class="rfc2119">may</em> remove features identified in the Last
        Call Candidate Recommendation document as "at risk" without repeating
        the transition to Last Call Candidate Recommendation. <span class="from">(was
           in 7.4.3)</span> </li>
    </ul>
    <p>The Director <em class="rfc2119">must</em> announce the provisional
      approval of a Request for publication of a W3C Recommendation to the <a href="http://www.w3.org/2005/10/Process-20051014/organization.html#AC">Advisory
         Committee</a>. <span class="new">The Director<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 Last Call
        Candidate Recommendation on which is it based. [editor's note - this is
        to allow for the patent policy exclusion period to expire]</span></p>
    <h5 id="rec-edited">Publishing an Edited Recommendation (See also <a href="#rec-modify">Modifying
@@ -51,7 +50,9 @@
         a Working Group</a> W3C <em class="rfc2119 changed">must </em><span class="from">(was
         should ...)</span> 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 <span class="changed">the Working
        Group <em class="rfc2119">should</em></span> <span class="from">(...
        but didn't say who should do this)</span> publish the document as a
      Working Group Note. </p>
    <p>In order to publish a Note a Working Group or Interest Group: <span class="from">(copied
         since notes are excluded from the requirements to move to a new maturity
        level)</span></p>
    <ul>
      <li><em class="rfc2119">must</em> record the group's decision to request
        advancement.</li>
      <li><em class="rfc2119">should</em> public documentation of significant
        changes to the technical report since the previous publication.</li>
    </ul>
    <p>Possible next steps:</p>
    <ul>
      <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, <span class="new">at the maturity level
          the specification had before publication as a Note</span></li>
    </ul>
    <p>A document published as a Working Group Note does not imply any licensing
      requirements, unless work is resumed and it is subsequently published as a
      W3C Recommendation. See also the <a href="http://www.w3.org/Consortium/Patent-Policy">W3C
-        Patent Policy</a> [<a href="http://www.w3.org/2005/10/Process-20051014/refs.html#ref-patentpolicy">PUB33</a>].</p>
    <h3>7.6 <a name="rec-modify" id="rec-modify">Modifying a W3C Recommendation</a></h3>
    <p>The following sections discuss the management of errors and the process
      for making normative changes to a Recommendation.</p>
    <h4>7.6.1 <a name="errata" id="errata">Errata Management</a></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 software.</p>
    <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="http://www.w3.org/Guide/pubrules">Publication Rules</a>.</p>
    <p>A correction is first "proposed" by the Working Group. A correction
      becomes
      normative -- of equal status as the text in the published Recommendation
      --
      through one of the processes described below. An errata page <span class="rfc2119">MAY</span>
      include both proposed and normative corrections. The
      Working Group <span class="rfc2119">MUST</span> clearly identify which
      corrections are proposed and which are normative.</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 become normative,
      according
      to the Team's requirements. For instance, the Team might set up a mailing
      list
      per Recommendation where a Working Group reports changes to an errata
      page.</p>
    <h4>7.6.2 <a name="correction-classes" id="correction-classes">Classes of
        Changes to a Recommendation</a></h4>
    <p>This document distinguishes the following classes of changes to a
      Recommendation.</p>
    <dl>
      <dt>1. No changes to text content</dt>
      <dd>These changes include fixing broken links or invalid markup.</dd>
      <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 <span class="rfc2119">MAY</span> affect
        conformance,
        but add no new features</dt>
      <dd>These changes <span class="rfc2119">MAY</span> affect conformance to
        the
        Recommendation. A change that affects conformance is one that:
        <ol>
          <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>
        </ol>
      </dd>
      <dt>4. New features</dt>
    </dl>
    <p>The first two classes of change require no technical review of the
      proposed
      changes, although a Working Group <span class="rfc2119">MAY</span> issue
      a Call
      for Review. The modified Recommendation is published according to the
      Team's
      requirements, including <a href="http://www.w3.org/Guide/pubrules">Publication
        Rules</a> [<a href="refs.html#ref-pubrules">PUB31</a>].</p>
    <p>For the third class of change, W3C requires:</p>
    <ol>
      <li>Review by the community to ensure the technical soundness of proposed
        corrections.</li>
      <li>Timely publication of the edited Recommendation, with corrections
        incorporated.</li>
    </ol>
    <p>For the third class of change, the Working Group <span class="rfc2119">MUST</span>
      either:</p>
    <ol>
      <li>Request that the Director issue a <a href="#cfr-edited">Call for
          Review of
          an Edited Recommendation</a>, or</li>
      <li>Issue a <a href="#cfr-corrections">Call for Review of Proposed
          Corrections</a> that have not been incorporated into an edited draft
        (e.g.,
        those listed on an errata page). After this review, the Director <span
          class="rfc2119">MAY</span>
        announce that the proposed corrections are normative.</li>
    </ol>
    <p>While the second approach is designed so that a Working Group can
      establish
      normative corrections quickly, it does not obviate the need to incorporate
      changes into an edited version of the Recommendation. In particular, when
      corrections are numerous or complex, integrating them into a single
      document is
      important for interoperability; readers might otherwise interpret the
      corrections differently.</p>
    <p>For the fourth class of change (new features), W3C <span class="rfc2119">MUST</span>
      follow the full process of <a href="#rec-advance">advancing a technical
        report to Recommendation</a>.</p>
    <h3>7.7 <a name="rec-rescind" id="rec-rescind">Rescinding a W3C
        Recommendation</a></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="http://www.w3.org/Consortium/Patent-Policy">W3C
+        Patent Policy</a> [<a href="http://www.w3.org/2005/10/Process-20051014/refs.html#ref-patentpolicy">PUB33</a>].</p>
    <h3>7.6 <a name="rec-modify" id="rec-modify">Modifying a W3C Recommendation</a></h3>
    <p>The following sections discuss the management of errors and the process
      for making normative changes to a Recommendation.</p>
    <h4>7.6.1 <a name="errata" id="errata">Errata Management</a></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
      software.</p>
    <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="http://www.w3.org/Guide/pubrules">Publication
        Rules</a>.</p>
    <p>A correction is first "proposed" by the Working Group. A correction
      becomes normative -- of equal status as the text in the published
      Recommendation -- through one of the processes described below. An errata
      page <span class="rfc2119">MAY</span> include both proposed and normative
      corrections. The Working Group <span class="rfc2119">MUST</span> clearly
      identify which corrections are proposed and which are normative.</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
      become normative, according to the Team's requirements. For instance, the
      Team might set up a mailing list per Recommendation where a Working Group
      reports changes to an errata page.</p>
    <h4>7.6.2 <a name="correction-classes" id="correction-classes">Classes of
        Changes to a Recommendation</a></h4>
    <p>This document distinguishes the following classes of changes to a
      Recommendation.</p>
    <dl>
      <dt>1. No changes to text content</dt>
      <dd>These changes include fixing broken links or invalid markup.</dd>
      <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 <span class="rfc2119">MAY</span> affect
        conformance, but add no new features</dt>
      <dd>These changes <span class="rfc2119">MAY</span> affect conformance to
        the Recommendation. A change that affects conformance is one that:
        <ol>
          <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>
        </ol>
      </dd>
      <dt>4. New features</dt>
    </dl>
    <p>The first two classes of change require no technical review of the
      proposed changes, although a Working Group <span class="rfc2119">MAY</span>
      issue a Call for Review. The modified Recommendation is published
      according to the Team's requirements, including <a href="http://www.w3.org/Guide/pubrules">Publication
+        Rules</a> [<a href="refs.html#ref-pubrules">PUB31</a>].</p>
    <p>For the third class of change, W3C requires:</p>
    <ol>
      <li>Review by the community to ensure the technical soundness of proposed
        corrections.</li>
      <li>Timely publication of the edited Recommendation, with corrections
        incorporated.</li>
    </ol>
    <p>For the third class of change, the Working Group <span class="rfc2119">MUST</span>
      either:</p>
    <ol>
      <li>Request that the Director issue a <a href="#cfr-edited">Call for
          Review of an Edited Recommendation</a>, or</li>
      <li>Issue a <a href="#cfr-corrections">Call for Review of Proposed
          Corrections</a> that have not been incorporated into an edited draft
        (e.g., those listed on an errata page). After this review, the Director
        <span class="rfc2119">MAY</span> announce that the proposed corrections
        are normative.</li>
    </ol>
    <p>While the second approach is designed so that a Working Group can
      establish normative corrections quickly, it does not obviate the need to
      incorporate changes into an edited version of the Recommendation. In
      particular, when corrections are numerous or complex, integrating them
      into a single document is important for interoperability; readers might
      otherwise interpret the corrections differently.</p>
    <p>For the fourth class of change (new features), W3C <span class="rfc2119">MUST</span>
      follow the full process of <a href="#rec-advance">advancing a technical
        report to Recommendation</a>.</p>
    <h3>7.7 <a name="rec-rescind" id="rec-rescind">Rescinding a W3C
        Recommendation</a></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="http://www.w3.org/Consortium/Patent-Policy">W3C
         Patent Policy</a> [<a href="http://www.w3.org/2005/10/Process-20051014/refs.html#ref-patentpolicy">PUB33</a>]
      and in particular <a href="http://www.w3.org/Consortium/Patent-Policy#sec-Requirements">section
         5</a> (bullet 10) and <a href="http://www.w3.org/Consortium/Patent-Policy#sec-PAG-conclude">section
         7.5</a>. <span class="changed">A Working Group </span><span class="changed"><em
          class="rfc2119">may</em>
        request the director to rescind a Recommendation which was a
        deliverable, or the Director </span><span class="changed"><em class="rfc2119">may</em>
        directly propose to rescind a Recommendation. </span><span class="from">(was