Movatterモバイル変換


[0]ホーム

URL:


[next chapter]  [previous chapter]  [contents]


On 1 August 2014, W3C began atransition away from this document; see thecurrent W3C Process Document.

W3C Process Document

7W3C Recommendation Track Process

The Recommendation Track process is the set of steps and requirementsfollowed by W3CWorking Groups tostandardize Web technology. The processes followed by a Working Group to managespecifications and guidelines -- called technical reports in this section --include:

The W3C Recommendation Track process is designed to maximizeconsensus about the content of atechnical report, to ensure high technical and editorial quality, and to earnendorsement by W3C and the broader community. See also the licensing goals forW3C Recommendations insection 2of theW3C PatentPolicy [PUB33].

The following sections describe:

Maturity levels are described first, followed by the steps on theRecommendation Track and the requirements for each step.

7.1Recommendation TrackProcess Maturity Levels

The maturity level of a published technical report indicates its place inthe Recommendation Track process. The maturity levels "Working Draft" and"Working Group Note" represent the possibleinitial states of a technical report in theRecommendation Track process. The maturity levels "Recommendation", "WorkingGroup Note", and "Rescinded Recommendation" represent the possibleend states.

7.1.1 Maturity Levels When Advancing a TechnicalReport Towards Recommendation

Working Draft (WD)
A Working Draft is a document that W3C has published for review by thecommunity, including W3C Members, the public, and other technicalorganizations.
Candidate Recommendation (CR)
A Candidate Recommendation is a document that W3C believes has been widelyreviewed and satisfies the Working Group's technical requirements. W3Cpublishes a Candidate Recommendation to gather implementation experience.
Proposed Recommendation (PR)
A Proposed Recommendation is a mature technical report that, after widereview for technical soundness and implementability, W3C has sent to the W3CAdvisory Committee for final endorsement.
W3C Recommendation (REC)
A W3C Recommendation is a specification or set of guidelines that, afterextensive consensus-building, has received the endorsement of W3C Members andthe Director. W3C recommends the wide deployment of its Recommendations.Note: W3C Recommendations are similar to the standardspublished by other organizations.

7.1.2 Maturity Level When Ending Work on a TechnicalReport

Working Group Note
A Working Group Note is published by a chartered Working Group to indicatethat work has ended on a particular topic. A Working GroupMAY publish a Working Group Note with or without itsprior publication as a Working Draft. W3CMAY alsopublish "Interest Group Notes" and "Coordination Group Notes" for similarpublications by those types ofgroups.Interest Groups and Coordination Groups do not create technical reports thatadvance toward Recommendation.
Note: To avoid confusion in the developer community andthe media about which documents represent the output of chartered groups andwhich documents are input to W3C Activities (Member Submissions andTeam Submissions), W3C plans tostop using the unqualified maturity level "Note."

7.1.3 Maturity Level When Editing aRecommendation

Proposed EditedRecommendation
A Proposed Edited Recommendation is a Recommendation published forcommunity review ofchanges, some of whichmay affect conformance. When there is consensus about the changes, the documentis published as a Recommendation.

7.1.4 Maturity Levels When Rescinding aRecommendation

Rescinded Recommendation
A Rescinded Recommendation is an entire Recommendation that W3C no longerendorses.

7.2General Requirements forAdvancement

For a Call for Implementations up to and including publication as aRecommendation, the Working GroupMUST:

  1. Record the group's decision to request advancement.
  2. Indicate whether the document has been modified substantively since theprevious step. Asubstantive change (whether deletion, inclusion,or other modification) is one where someone could reasonably expect that makingthe change would invalidate an individual's review or implementationexperience. Other changes (e.g., clarifications, bug fixes, editorial repairs,and minor error corrections) areminorchanges. A Working GroupMUST document changes(both substantive and minor) between steps.
  3. Report which, if any, of the Working Group's requirements for this documenthave changed since the previous step.
  4. Report any changes in dependencies with other groups.
  5. Show evidence of wide review.
  6. Formally address all issuesraised about the document since the previous step. In practice, once a WorkingGroup wishes to advance to Candidate Recommendation or beyond, the Directorexpects positive documentation that issues have been formally addressed (e.g.,in an issues list that shows their disposition). For earlier stages on theRecommendation Track, less formal documentation generally suffices (e.g.,evidence in an archived mailing list).
  7. Report anyformalobjections.

The following information is important to the decision to advance atechnical report and thereforeMUST bepublicly available:

7.3Reviews and ReviewResponsibilities

Experience shows that the following help build consensus around technicalreports:

  1. Frequent publication (see theWorking Group "Heartbeat"requirement).
  2. Early review, to find errors quickly and decrease the chances of divergingtechnologies.
  3. Wide review, including from other groups in and outside of W3C.

A document receives review from the moment it is first published. Startingwith the First Public Working Draft until the start of a ProposedRecommendation review, a Working GroupMUSTformally addressanysubstantive review comment about a technical report andSHOULD do so in a timely manner. The DirectorMUST formally address any substantive issue raised byAdvisory Committee representatives during Proposed Recommendation, ProposedEdited Recommendation, and Proposed Rescinded Recommendation review periods.The Working GroupMUST communicate to the Director(usually through the Team Contact) any substantive issues raised duringProposed Recommendation, Proposed Edited Recommendation, and Proposed RescindedRecommendation review periods by parties other than Advisory Committeerepresentatives.

ReviewersSHOULD NOT send substantive technicalreviews late on the Recommendation track. ReviewersSHOULD NOT expect that a Working Group will readily makesubstantive changes to a mature document. Themore evidence a Working Group can show of wide review, the less weightsubstantive comments will carry when provided late on the Recommendation Track.Worthy ideasSHOULD BE recorded even when notincorporated into a mature document.

The Working GroupMUST be able to show evidenceof having attempted to respond to and satisfy reviewers. ReviewersMAY register aformal objection any time theyare dissatisfied with how a Working Group has handled an issue.

A Working GroupSHOULD negotiate reviewschedules with other groups expected to review a document, including relevantliaisons.

There are two formal review periods with fixed durations when advancing toRecommendation: after a Last Call announcement and after a Call for Review of aProposed Recommendation. Out of consideration for the Working Group, reviewersSHOULD send their comments early in a reviewperiod. A Working GroupSHOULD NOT start a newreview before the scheduled end of an ongoing review (e.g., do not start a newLast Call review before the scheduled end of an ongoing Last Call review).

Ordinarily, reviewersSHOULD NOT raisesubstantive technical issues about a technical report after the end of a LastCall review period. However, this does occur, and as stated above, a WorkingGroup's requirement to formally address those issues extends until the end of aProposed Recommendation review period. However, to allow the Working Group tomake progress on a technical report, the Working GroupMAY decline to make substantive changes to addressissues raised between the end of a Last Call review period and publication of aRecommendation. A reviewerMAY register aformal objection.

Advisory Committee representativesSHOULD NOT(butMAY) raise new substantive technical issuesduring a Proposed Recommendation review period. The DirectorMAY respond to the reviewer after the close of theProposed Recommendation review period.Note: It may benecessary tochange confidentialitylevel when conveying issues raised by Advisory Committee representatives tothe Working Group.

During review by the Members, the Working GroupSHOULD alsoformally address informed and relevantissues raised outside the Advisory Committee (e.g., by the public or anotherW3C Working Group), and report them to the Director in a timely fashion.

When a Working Group receives a substantive issue after the end of ProposedRecommendation review period, the Working GroupMUST respond to the reviewer butMAY decline toformally address the issue. In thiscase, the Working GroupMAY consider the issue aspart of trackingerrata.

7.4Advancing a Technical Report toRecommendation

W3C follows these steps when advancing a technical report toRecommendation.

  1. Publication of the First Public Working Draft.
  2. Last Call announcement
  3. Call for Implementations.Note: TheDirectorMAY permit the Working Group to skip thisstep if the entrance criteria for the next step have already beensatisfied.
  4. Call for Review of a Proposed Recommendation.
  5. Publication as a Recommendation.

In general, Working Groups embark on this journey with the intent ofpublishing one or more Recommendations. However, W3CMAYend work on a technical reportat any time, orMAY require a Working Group toconductfurther work, possibly repeating one ormore steps.

Between publication of the First Public Working Draft and Last Callannouncement, a Working Group publishes revisions that generally includesubstantive changes. Between any two steps after a Last Call announcement, theWorking GroupMAY publish a new draft of thetechnical report at the same maturity level provided there are nosubstantive changes since the earlier step.

The TeamMUST notify theAdvisory Committee and other W3C groups of arevision to a Candidate Recommendation or Proposed Recommendation.

These steps of the Recommendation Track process can take considerable time,so participants are encouraged to read thetips on getting to Recommendationfaster [PUB27].

Refer to"How to Organize a RecommendationTrack Transition" in theMemberguide for practical information about preparing for the reviews andannouncements of the various steps.

7.4.1First Public Working Draft

Document maturity level:Working Draft.

Announcement: The DirectorMUST announce thefirst Working Draft publication to other W3C groups and to the public.

Purpose: The publication of the First Public Working Draft is a signal tothe community to begin reviewing the document. Seesection4.1 of the W3C Patent Policy [PUB33] for information about the policyimplications of the First Public Working Draft.

Entrance criteria: The ChairMUST record thegroup's decision to request advancement. Since this is the first time that adocument with this short name appears in the Technical Reports index, Directorapproval isREQUIRED for the transition.

Ongoing work: After publication of the First Public Working Draft, theWorking Group generally revises the technical report (see theWorking Group "Heartbeat" Requirement)in accordance with its charter.

In order to make Working Drafts available to a wide audience early in theirdevelopment, the requirements for publication of a Working Draft are limited toan agreement by a chartered Working Group to publish the technical report andsatisfaction of the Team'sPublication Rules [PUB31]. Consensus is not a prerequisite forapproval to publish; the Working GroupMAY requestpublication of a Working Draft even if it is unstable and does not meet allWorking Group requirements.

Working GroupsSHOULD encourage early and widereview of the technical report, within and outside of W3C, especially fromother Working Groups with dependencies on the technical report. AdvisoryCommittee representativesSHOULD encourage reviewwithin their organizations as early as First Public Working Draft, i.e., beforeaLast Call announcement andwell before aCall for Review of a Proposed Recommendation.

The Working GroupSHOULD be responsive to andfacilitate ongoing review by addressing issues in a timely manner and clearlyindicating changes between drafts (e.g., by providing "diffs" and summaries ofsubstantive changes).

Possible next steps:

7.4.2Last Call Announcement

Document maturity level:Working Draft.

Announcement: The Working GroupMUST announcethe Last Call to other W3C groups and to the public. A Last Call announcementMUST:

  1. specify the deadline for review comments;
  2. identify known dependencies and solicit review from all dependent WorkingGroups;
  3. solicit public review.

Purpose: A Working Group's Last Call announcement is a signal that:

In general, a Last Call announcement is also a signal that the Working Groupis planning to advance the technical report to later maturity levels.

A Working GroupSHOULD work with other groupsprior to a Last Call announcement to reduce the risk of surprise at LastCall.

Ideally, after a Last Call announcement, a Working Group receives onlyindications of support for the document, with no proposals for substantivechange. In practice, Last Call announcements generate comments that sometimesresult in substantive changes to a document. A Working GroupSHOULD NOT assume that it has finished its work byvirtue of issuing a Last Call announcement.

Entrance criteria: Before announcing a Last Call, the Working GroupMUST do all of the following:

  1. Record the group's decision to request advancement.
  2. Fulfill the relevant requirements of the Working Group charter and those ofany accompanying requirements documents, or report which relevant requirementshave not been fulfilled.
  3. Indicate which dependencies with other groups the Working Group believes ithas satisfied, and report which dependencies have not been satisfied.

Duration of the review: The announcement begins a review period thatSHOULD last at leastthreeweeks butMAY last longer if the technicalreport is complex or has significant external dependencies.

Ongoing work: During the review period, the Working Group solicits andresponds to comments from the Team, the Members, other W3C groups, and thepublic.

It is important to ensure the proper integration of a technical report inthe international community. Starting at this step in the Recommendationprocess, the technical reportSHOULD include astatement about how the technology relates to existing international standardsand to related work outside of W3C.

Possible next steps:

7.4.3Call for Implementations

Document maturity level:Candidate Recommendation.

Announcement: The DirectorMUST announce theCall for Implementations to theAdvisoryCommittee.

Purpose: At this step, W3C believes the technical report is stable andappropriate for implementation. The technical reportMAY still change based on implementation experience.

Entrance criteria: The Director calls for implementation when satisfied thatthe Working Group has fulfilled thegeneralrequirements for advancement.

The Working Group isNOT REQUIRED to show thata technical report has two independent and interoperable implementations aspart of a request to the Director to announce a Call for Implementations.However, the Working GroupSHOULD include a reportof present and expected implementations as part of the request.

In the Call for Implementations, the Working GroupMAY identify specific features of the technical reportas being "features at risk."General statements such as "We plan to remove any unimplemented feature" arenot acceptable; the Working GroupMUST preciselyidentify any features at risk. Thus, in response to a Call for Implementations,reviewers can indicate whether they wouldformally object to the removalof the identified features.

After gathering implementation experience, the Working GroupMAY remove features from the technical report that wereidentified as being "at risk" and request that the DirectorCallfor Review of a Proposed Recommendation. If the Working Group makes othersubstantive changes to the technical report,the DirectorMUST return it to the Working Groupforfurther work.

The request to the Director to advance a technical report to CandidateRecommendationMUST indicate whether the WorkingGroup expects to satisfy any Proposed Recommendation entrance criteria beyondthe default requirements (described below).

Advisory Committee representativesMAYappeal the decision to advance the technicalreport.

Duration of the implementation period: The announcementMUST indicate a minimal duration, before which theWorking GroupMUST NOT request aCall for Review of a Proposed Recommendation; this minimalduration is designed to allow time for comment. The announcementSHOULD also include the Working Group's estimate of thetime expected to gather sufficient implementation data.

Possible next steps:

7.4.4Call for Review of a ProposedRecommendation

Document maturity level:Proposed Recommendation.

Announcement: The DirectorMUST announce theCall for Review to theAdvisoryCommittee.

Purpose: At this step, W3C seeks endorsement of the stable technical report.The outcome of this review is taken as an indication of the organization'ssupport for the technical report.

Entrance criteria: The Director calls for review when satisfied that theWorking Group has:

  1. Fulfilled thegeneral requirements foradvancement;
  2. Shown that each feature of the technical report has been implemented.Preferably, the Working GroupSHOULD be able todemonstrate two interoperable implementations of each feature. If the Directorbelieves that immediate Advisory Committee review is critical to the success ofa technical report, the DirectorMAY accept toCall for Review of a Proposed Recommendation even without adequateimplementation experience;
  3. Satisfied any other announced entrance criteria (e.g., any included in therequest to advance to Candidate Recommendation, or announced at Last Call ifthe Working Group does not intend to issue a Call for Implementations).

Advisory Committee representativesMAYappeal the decision to advance the technicalreport.

Duration of the review: The announcement begins a review period thatMUST last at leastfourweeks.

Ongoing work: During the review period, the Working Group requestsendorsement and support from Members (e.g., testimonials as part of a pressrelease).

Possible next steps:

7.4.5Publication of a W3CRecommendation

Document maturity level:Recommendation.

Announcement: The DirectorMUST announce thepublication of a W3C Recommendation to theAdvisory Committee.

Purpose: W3C publishes Recommendations when it believes that the ideas inthe technical report are appropriate for widespread deployment and that theypromoteW3C's mission.

Entrance criteria: The Director publishes a W3C Recommendation whensatisfied that there is significant support for the technical report from theAdvisory Committee, the Team, W3C Working Groups, and the public. The decisionto advance a document to Recommendation is aW3C decision.

If there was anydissent during theMember review, Advisory Committee representativesMAYappeal thedecision to publish the Recommendation.

Possible next steps:

The DirectorMAY submit a W3C Recommendation toanother standards body for adoption and formal approval by that body.

7.4.6Returning a Document to aWorking Group for Further Work

A technical report is returned to a Working Group for further work in eitherof the following situations:

  1. The Working Group makessubstantivechanges to the technical report at any time after aLast Call announcement and prior toPublication as a Recommendation,except when the changes involve the removal offeatures at risk identified in aCall for Implementations. In the case of substantive changes,the Working GroupMUST republish the technicalreport as a Working Draft.
  2. The Director requires the Working Group to address important issues raisedduring a review or as the result of implementation experience. In this case,DirectorMAY request that the Working Grouprepublish the technical report as a Working Draft, even if the Working Grouphas not madesubstantive changes.

The DirectorMUST inform theAdvisory Committee and group Chairs when atechnical report has been returned to a Working Group for further work.

After republication as a Working Draft, the next forward step available tothe Working Group is aLast Call announcement. TheLast Call announcementMAY occur at the same timeas the publication of the Working Draft.

The DirectorMAY ask the Working Group torepublish a technical report as a Candidate Recommendation. At the same time aspublication, the Director issues aCall forImplementations.

7.5Ending Work on a Technical Report

Work on a technical reportMAY cease at anytime. When a Working Group completes its work on a technical report, itpublishes it either as a Recommendation or a Working Group Note. For example, aWorking Group might publish several Working Drafts of a requirements document,and then indicate that it no longer plans to work on the requirements documentby publishing a Working Group Note.

WorkMAY also cease because W3C determines thatit cannot productively carry the work any further. For instance, the Directormightclose a Working Group, theparticipants might lose interest in a technical report, or the ideas might besubsumed by another technical report. If W3C decides to discontinue work on atechnical report before completion, the technical reportSHOULD be published as a Working Group Note.

Possible next steps:

7.6Modifying a W3CRecommendation

W3C makes every effort to maintain its Recommendations (e.g., by trackingerrata, providing test-bed applications, and helping to create test suites) andto encourage widespread implementation. The following sections discuss themanagement of errors and the process for making normative changes to aRecommendation.

7.6.1Errata Management

Tracking errors is an important part of a Working Group's ongoing care of aRecommendation; for this reason, the scope of a Working Group charter generallyallows time for work after publication of a Recommendation. In this ProcessDocument, the term "erratum" (plural "errata") refers to any class of mistake,from mere editorial to a serious error that may affect the conformance with theRecommendation by software or content (e.g., content validity).Note: Before a document becomes a Recommendation, the W3CProcess focuses onsubstantive changes (thoserelated to prior reviews). After a document has been published asRecommendation, the W3C Process focuses on those changes to a technical reportthat might affect the conformance of content or deployed software.

Working GroupsMUST track errata on an "erratapage." An errata page is a list of enumerated errors, possibly accompanied bycorrections. Each Recommendation links to an errata page; see the Team'sPublication Rules.

A correction is first "proposed" by the Working Group. A correction becomesnormative -- of equal status as the text in the published Recommendation --through one of the processes described below. An errata pageMAY include both proposed and normative corrections. TheWorking GroupMUST clearly identify whichcorrections are proposed and which are normative.

A Working GroupSHOULD keep their errata pagesup-to-date, as errors are reported by readers and implementers. A Working GroupMUST report errata page changes to interestedparties, notably when corrections are proposed or become normative, accordingto the Team's requirements. For instance, the Team might set up a mailing listper Recommendation where a Working Group reports changes to an errata page.

7.6.2Classes ofChanges to a Recommendation

This document distinguishes the following classes of changes to aRecommendation.

1. No changes to text content
These changes include fixing broken links or invalid markup.
2. Corrections that do not affect conformance
Editorial changes or clarifications that do not change the technicalcontent of the specification.
3. Corrections thatMAY affect conformance,but add no new features
These changesMAY affect conformance to theRecommendation. A change that affects conformance is one that:
  1. turns conforming data, processors, or other conforming agents intonon-conforming agents, or
  2. turns non-conforming agents into conforming ones, or
  3. clears up an ambiguity or under-specified part of the specification in sucha way that an agent whose conformance was once unclear becomes clearlyconforming or non-conforming.
4. New features
For new features, W3C follows the full process ofadvancing a technical report to Recommendation.

The first two classes of change require no technical review of the proposedchanges, although a Working GroupMAY issue a Callfor Review. The modified Recommendation is published according to the Team'srequirements, includingPublicationRules [PUB31].

For the third class of change, W3C requires:

  1. Review by the community to ensure the technical soundness of proposedcorrections.
  2. Timely publication of the edited Recommendation, with correctionsincorporated.

For the third class of change, the Working GroupMUST either:

  1. Request that the Director issue aCall for Review ofan Edited Recommendation, or
  2. Issue aCall for Review of ProposedCorrections that have not been incorporated into an edited draft (e.g.,those listed on an errata page). After this review, the DirectorMAY announce that the proposed corrections arenormative.

While the second approach is designed so that a Working Group can establishnormative corrections quickly, it does not obviate the need to incorporatechanges into an edited version of the Recommendation. In particular, whencorrections are numerous or complex, integrating them into a single document isimportant for interoperability; readers might otherwise interpret thecorrections differently.

7.6.3Call for Review of an EditedRecommendation

Document maturity level:Proposed EditedRecommendation.

Announcement: The DirectorMUST announce theCall for Review to other W3C groups, the public, and theAdvisory Committee. The announcementMUST clearly indicate that this is a proposal to edit aRecommendation andMUST:

  1. specify the deadline for review comments;
  2. identify known dependencies and solicit review from all dependent WorkingGroups;
  3. solicit public review.

Purpose: At this step, W3C seeks confirmation of proposed corrections to aRecommendation.

Entrance criteria: The Director calls for review when satisfied that, withrespect to changes to the document, the Working Group has fulfilled the sameentrance criteria as for aCall for Review of a ProposedRecommendation (e.g., the Working Group can show implementation experiencethat supports the changes). In the request to advance to this status, theWorking GroupMUST report any substantive issuesabout the technical report that have not been resolved.

Advisory Committee representativesMAYappeal the decision to advance the technicalreport.

Duration of the review: The announcement begins a formal Advisory Committeereview period thatMUST last at leastfour weeks.

Ongoing work: During the review period, the Working Group solicits andresponds to comments from the Team, the Members, other W3C groups, and thepublic.

Possible next steps:

7.6.4Call for Review ofProposed Corrections

Document maturity level: A Recommendation, plus a list of proposedcorrections. The Working GroupSHOULD also includea detailed description of how the Working Group plans to change the text of theRecommendation for each proposed correction.

Announcement: The Working GroupMUST announcethe Call for Review to other W3C groups, the public, and theAdvisory Committee. This is not a formalAdvisory Committee review. However, theannouncementMUST clearly indicate that this is aproposal to make normative corrections to the Recommendation andMUST:

  1. specify the deadline for review comments;
  2. identify known dependencies and solicit review from all dependent WorkingGroups;
  3. solicit public review.

Purpose: At this step, W3C seeks confirmation of proposed corrections to aRecommendation.

Entrance criteria: The Working Group calls for review when, with respect tochanges to the document, the group has fulfilled the same entrance criteria asfor aCall for Review of a Proposed Recommendation.

Duration of the review: The announcement begins a review period thatMUST last at leastfourweeks.

Ongoing work: Same as for aProposed EditedRecommendation.

If there are noformalobjections to the proposed corrections, W3C considers them normative. TheWorking GroupMUST report formal objections to theDirector, who assesses whether there is sufficient consensus to declare theproposed corrections to be normative.

Possible next steps:

7.7Rescinding a W3CRecommendation

At times, W3CMAY rescind an entireRecommendation, for instance when W3C learns of significant errors in theRecommendation, when the Recommendation becomes outdated, or if W3C discoversburdensome patent claims that affect implementers; see theW3C Patent Policy [PUB33] and in particularsection5 (bullet 10) andsection7.5.

To deprecatepart of a Recommendation, W3C follows the process formodifying a Recommendation.

Once W3C has published a Rescinded Recommendation, future W3C technicalreportsMUST NOT include normative references tothat technical report.

7.7.1Proposalto Rescind a Recommendation

Document maturity level: Recommendation, plus separate rationale for theproposal to rescind.

Announcement: The DirectorMUST announce theProposal to Rescind a Recommendation to other W3C groups, the public, and theAdvisory Committee. The announcementMUST clearly indicate that this is a Proposal to Rescinda Recommendation andMUST:

  1. specify the deadline for review comments;
  2. identify known dependencies and solicit review from all dependent WorkingGroups;
  3. solicit public review.

Purpose: At this step, W3C seeks confirmation of a Proposal to Rescind aRecommendation.

Entrance criteria: The Director proposes that W3C rescind a Recommendationwhen satisfied that there is sufficient reason.

Advisory Committee representativesMAYappeal the Proposal to Rescind theRecommendation.

Duration of the review: The announcement begins a review period thatMUST last at leastfourweeks.

Ongoing work: During the review period, the Working Group solicits andresponds to comments from the Team, the Members, other W3C groups, and thepublic.

Possible next steps:

7.7.2Publication of a RescindedRecommendation

Document maturity level:RescindedRecommendation.

Announcement: The DirectorMUST announce thePublication of a Rescinded Recommendation to theAdvisory Committee.

Purpose: At this step, W3C indicates that it no longer endorses a previouslypublished Recommendation.

Entrance criteria: The Director publishes a Rescinded Recommendation whensatisfied that there is significant support from the Advisory Committee, theTeam, W3C Working Groups, and the public. The decision to advance a document toRescinded Recommendation is aW3Cdecision.

The TeamMAY publish one or more documents inorder to best communicate what has been rescinded and its relation to previousRecommendations (e.g., the publication can be as simple as a cover sheet thatrefers to a previously published Recommendation).

If there was anydissent in theProposed Rescinded Recommendation reviews, Advisory Committee representativesMAYappealthe decision to rescind the Recommendation.

Possible next step:

7.8General Informationabout Technical Reports

Every document published as part of the Recommendation Track processMUST be a public document. Theindex of W3C technical reports [PUB11] is available at the W3C Web site. W3Cwill make every effort to make archival documents indefinitely available attheir original address in their original form.

Every document published as part of the Recommendation Track processMUST clearly indicate itsmaturity level.

Every technical report published as part of the Recommendation Track processis edited by one or more editors appointed by a Working Group Chair. It is theresponsibility of these editors to ensure that the decisions of the group arecorrectly reflected in subsequent drafts of the technical report. An Editor forthe TAG or Advisory Board who is not an elected or appointed participant inthat groupMUST fulfill the same participationrequirements for that group, as a Member representative, Team representative,or Invited Expert. All other W3C EditorsMUST beparticipants in the group responsible for the document(s) they are editing.Note that an Editor isNOT REQUIRED to be a Teamrepresentative.

The Team isNOT REQUIRED to publish a technicalreport that does not conform to the Team'sPublication Rules (e.g., fornaming, style, andcopyright requirements).These rules are subject to change. The TeamMUSTinform group Chairs and the Advisory Board of any changes.

The Team reserves the right to reformat technical reports at any time so asto conform to changes in W3C practice (e.g., changes to technical report stylesor thedocument status section).

The primary language for W3C technical reports is English. W3C encouragesthe translation of its technical reports.Information about translationsof W3C technical reports [PUB18]is available at the W3C Web site.

7.8.1Document StatusSection

Each technical reportMUST include a sectionabout the status of the document. The status sectionSHOULD explain why W3C has published the technicalreport, expectations about next steps, who developed it, where to send commentsabout it, whether implementation experience is being sought, any significantchanges from the previous version, why work on the technical report has ceasedor been subsumed, and any other relevant information or rationale.

The Team'sPublication Rulesinclude status section requirements for each maturity level.


[next chapter]  [previous chapter]  [contents]


[8]ページ先頭

©2009-2025 Movatter.jp