On 1 August 2014, W3C began a transition away from this document; see the current W3C Process Document.
This document describes the processes that govern the operation of the World Wide Web Consortium (W3C) and the relationships between W3C Members, the W3C Team, and the general public. This version of the Process Document was made available to the Advisory Committee on 1 November 1999 and to the general public on 11 November 1999.
This document was initially prepared by the Process Working Group (WG) of the World Wide Web Consortium.
A list of changes to this document is available online.
This document is available in the following formats: a single HTML file, a PostScript file, a PDF file, a plain text file, a self-contained gzipped tar archive, or a self-contained zip archive.
W3C Members who have comments about this document should consult the Member guide for information about Process Document feedback. Comments from the Team should be sent to the appropriate Team mailing list. If you're not a Member, please refer to "About the W3C" at the W3C Web site for Membership information.
Copyright © 1999 W3C
(MIT,
INRIA,
Keio), All Rights Reserved. W3C
liability,
trademark,
document
use and
software
licensing rules apply.
Founded in 1994 to develop common protocols for the evolution of the World Wide Web, the World Wide Web Consortium (W3C) is an international association of industrial and service companies, research laboratories, educational institutions, and organizations of all sizes. All of these organizations share a compelling interest in the long term evolution and stability of the World Wide Web (Web).
W3C is a non-profit organization funded partly by commercial members. Its activities remain vendor neutral, however. W3C also receives the support of governments who consider the Web the platform of choice for a global information infrastructure.
W3C was originally established in collaboration with CERN, birthplace of the Web, with support from DARPA and the European Commission.
W3C's mission is to lead the evolution of the Web -- the universe of information accessible through networked computers.
W3C's long term goals are:
Integral to the W3C process is the notion of consensus. The W3C process requires those who are considering an issue to address all participants' views and objections and strive to resolve them. Consensus is established when substantial agreement has been reached by the participants. Substantial agreement means more than a simple majority, but not necessarily unanimity. While unanimity is preferred, it is not practical to require that Working Groups, for example, reach unanimity on all issues. In some circumstances, consensus is achieved when the minority no longer wishes to articulate its objections. When disagreement is strong, the opinions of the minority are recorded in appropriate documents alongside those of the majority.
Groups strive to reach consensus in order to provide a single solution acceptable to the market at large. If a group makes a decision that causes the market to fragment -- despite agreement by those participating in the decision -- the decision does not reflect a single market and therefore the group has failed to reach true consensus.
Please also refer to the discussion of Working Group consensus and votes.
All W3C technical reports and software are made available free of charge to the general public (refer to the W3C document notice [PUB18]). This policy comes from the core goal of W3C to keep the Web as one and is part of the Membership agreement. Moreover, to ensure that its results are acceptable to the general public and to promote trial implementations, W3C may call for public comments about working drafts and software releases.
W3C promotes an open working environment. Whenever possible, technical decisions should be made unencumbered by intellectual property right (IPR) claims. To this end, W3C discloses to the entire Membership all IPR claims made by Members. Members may disclose IPR claims at any time. Members disclose patent and other IPR claims by sending email to an archived mailing list that is readable by Members and the Team: patent-issues@w3.org. Members must disclose all IPR claims to this mailing list but they may also copy other recipients. For instance, they should copy the Activity Lead responsible for a particular technology to ensure that the IPR claims receive prompt consideration.
Advisory Committee representatives are responsible for facilitating communication with IPR contacts in their organization. When disclosing IPR claims, individuals should therefore copy their Advisory Committee representative.
Member disclosures of IPR claims about a particular subject should include the following language:
To the best of my knowledge, I believe my organization has/doesn't have IPR claims regarding [subject].
Members are encouraged to disclose their claims in detail whenever possible.
Announcements, important documents, and frequently visited Web pages should remind Members to disclose IPR claims. Important places of interaction include: Activity proposals and briefing packages, calls for participation in groups and their charters, the Member home page, Activity home pages, and Group home pages.
Invited experts are required to disclose IPR claims in the same manner as individuals from Member organizations.
There are three qualities an individual must possess in order to join the W3C Team or participate in a W3C Activity (e.g., act as a Chair, editor, etc.):
Advisory Committee representatives who nominate individuals for participation in W3C Activities are responsible for assessing and attesting to the qualities of participants from their organization.
Individuals participating in a W3C Activity (e.g., within a Working Group) represent not only their own ideas but also the interests of the companies or organizations with which they have relationships. As these companies and organizations are often Members of W3C, all participants in a W3C Activity should clearly disclose, as is customary, the financial interests and affiliations they have with W3C Members. These disclosures should be kept up-to-date as the individual's professional relationships and W3C Membership evolve.
The ability of an individual to fulfill a role within a group without risking a conflict of interests is clearly a function of the individual's affiliations. When these affiliations change, the role in question must be reassigned, possibly to the same individual, according to the process appropriate to the role.
When an individual accepts a role as Chair or editor, the Member organization that employs that individual recognizes that this work as unbiased officer of the Group is done as part of the individual's work for the Member.
W3C is built on several foundations:
Unless otherwise stated, all announcements, replies, confirmations, notifications, ballots, minutes, and other documents exchanged within W3C will be electronic (e.g., email, mailing lists, and the Web site).
As part of its mission to make the Web accessible to all, W3C seeks a diverse Membership from around the world. To meet the needs of a heterogeneous global population of Web users, W3C interacts with vendors of technology products and services, content providers, corporate users, research laboratories, standards bodies, and governments. By working together, W3C's member organizations (hereafter, "Members") reach consensus on specifications, thus encouraging stability in this rapidly evolving technology. W3C also maintains close ties with related organizations such as the IETF, notably for the development of specifications.
At all times, the list of current W3C Members [PUB8] may be found at the W3C Web site.
W3C Members enjoy the following benefits:
The conditions and procedures for joining W3C [PUB5] are described at the W3C Web site.
Companies and organizations may subscribe according to the Full Member agreement [PUB6] or the Affiliate Member agreement [PUB7].
In the case (described in paragraph 5g of the Full and Affiliate Member Agreements), where a Member organization is itself a consortium, user society, or otherwise has members or sponsors, the organization's paid staff and Advisory Committee representative will exercise all the rights and privileges of W3C Membership. In addition, the Advisory Committee representative may designate up to four (or more at the Director's discretion) unpaid agents from the organization who will exercise Membership. These agents shall disclose their employment affiliation when participating in W3C activities. The provisions for Related Members will apply. Furthermore, these agents are expected to represent the broad interests of the W3C Member organization and not the parochial interests of their employers.
W3C Membership is open to all entities (as described in "How to Join W3C" [PUB5]). In the interest of ensuring the integrity of the consensus process, W3C may limit the influence of related Members in some circumstances. As used herein, two Members are related if:
A subsidiary is an organization of which effective control and/or majority ownership rests with another, single organization.
Under any circumstance where restrictions apply to related Members, it is the responsibility of those Members to disclose the relationship.
All individuals may participate in W3C Activities via W3C's public mailing lists.
An individual may have access to Member-only information by:
Please also consult the section on individual participation criteria.
The W3C Team consists of a Chairman, a Director, and Staff.
The Chairman manages the general operation of the Consortium, chairs Advisory Committee and Advisory Board meetings, oversees the development of the W3C international structure (e.g., role of Hosts, creation of W3C Offices, etc.), coordinates liaisons with other standards bodies, and addresses legal and policy issues.
The Director is the lead architect for the technologies developed at the Consortium. The Director also approves Recommendations, Activity proposals, and charters; designates Group Chairs; and acknowledges Submission requests.
The Team manages W3C Activities and establishes the mechanisms and procedures for doing so; this document does not include the details of those mechanisms. The Team provides information to the Members (through email, at the Member Web site, etc.) and may be reached directly by Members through the appropriate Team contact.
As coordinators of W3C Activities, the Team has the following responsibilities:
To promote cooperation between the Members and the Team, Member organizations may send engineers - called "W3C Fellows" - to work with the Team at Host institutions.
The W3C Director's most visible role involves approving or rejecting proposals that have been reviewed by the Advisory Committee (Activity proposals, Proposed Recommendations) or the Team (Submission requests). A Director's decision implies that consensus has been reached by the Advisory Committee or the Team and accounts for comments collected during a review, projections as to whether W3C is likely to achieve market consensus, and personal experience.
Each Director's decision must be announced to the Advisory Committee through an appropriate mailing list.
For most of the procedures described in the Process Document, the Director's decision follows a review by the Advisory Committee. Time intervals between the end of an Advisory Committee review period and the Director's decision are not specified in this document. This is to ensure that the Director has take sufficient time to consider comments gathered during a review.
For those parts of the process when a Director's decision is not preceded by a review by the Advisory Committee (namely, charter or process modifications), the Advisory Committee may appeal the decision. If five percent (5%) or more of the representatives appeal, the proposals in question will be submitted to the Advisory Committee for review.
The W3C Team is currently located on three continents at three Host institutions:
W3C is not a legal entity. W3C contracts and details of Membership are established between each Member company and the Host institutions. Host institutions pledge that no Member will receive preferential treatment within W3C and that individual contracts will remain confidential.
Internal administrative details, including Team salaries, detailed budgeting, and other business decisions must be held in confidentiality between the Team and the Host institutions.
Each Host institution exercises all the rights and privileges of W3C Membership. The resident W3C Associate Chairman or Deputy Director will hold the office of Advisory Committee representative for the Host. The Advisory Committee representative from a Host will not normally respond to calls for review (to reduce the potential of a conflict of interest) but will respond to calls for participation (to coordinate participation by non-Team employees of the Host). At Advisory Committee meetings, this person will act as W3C Team, not an Advisory Committee representative.
The Advisory Committee has several roles within W3C:
The Advisory Committee consists of one representative from each Member organization. The Advisory Committee representative is the official link between the Member organization and the Team. Advisory Committee representatives have the following responsibilities:
Each Advisory Committee representative is named in the Membership Agreement when the organization joins W3C [PUB5]. When a Member organization wishes to change its Advisory Committee representative, the departing representative must notify the Director of the change by email. If the departing Advisory Committee representative cannot be contacted, the new representative shall be confirmed by a responsible officer of the Member organization.
At all times, the list of current Advisory Committee representatives [MEM1] is available at the Web site.
The Advisory Committee will make use of the following communication mechanisms:
The names of all Advisory Committee representatives will appear on both lists.
Information about Advisory Committee mailing lists [MEM2] may be found at the W3C Web site.
The Advisory Committee will hold face-to-face meetings approximately twice a year. These meetings will be geographically distributed to areas where there is a significant portion of the Membership. At each Advisory Committee meeting, the W3C Team will provide Member organizations with an update of key W3C information, including:
The date and location of each meeting shall be announced at least six months (and preferably one year) before the planned date. In general, only one representative from each Member organization attends each Advisory Committee meeting. In exceptional circumstances (e.g., a period of transition between representatives from an organization), the Member may petition the Director for permission to send a second representative.
At least eight weeks before an Advisory Committee meeting, a mailing list will be established (and Advisory Committee representatives notified) by which Advisory Committee representatives may suggest topics of discussion for the meeting. Suggestions must also be sent to the mailing list for internal Advisory Committee discussions. The agenda for the meeting will be prepared by the Team two weeks before the meeting. The agenda will incorporate Member suggestions, Team reports required by the W3C process, and other topics approved by the Director.
Advisory Committee meetings are chaired by the Chairman. Minutes of the meeting must be posted within two weeks after the meeting. These minutes will include the agenda, a summary of discussions, and any action items identified during the meeting.
Information about future and past meetings [MEM5] (schedules, minutes, etc.) may be found at all times at the W3C Web site.
From time to time, Advisory Committee representatives are asked to review proposals (Activity proposals, Proposed Recommendations, proposed process changes, etc.). Each review period begins with an announcement (the "call for review") from the Director to the Advisory Committee on the Advisory Committee mailing list. A ballot accompanies each call for review. The ballot must clearly indicate:
The review period ends on the date specified in the ballot (unless extended as described below).
Each unrelated Member organization is allowed one ballot, which must be returned by its Advisory Committee representative. Each group of related Members is also allowed one ballot, which must be returned by a single Advisory Committee representative chosen by the group. In the event that the Advisory Committee representative is unable to participate, another person in the organization may submit the ballot accompanied by a statement that the person is acting on behalf of the AC representative. The Advisory Committee representative must receive a copy of this ballot. If more than one ballot is received from a Member organization, the ballots are counted as one valid ballot if they agree, otherwise they are ignored and the Advisory Committee representative will be notified of the discrepancy.
Each ballot will ask the Advisory Committee representative to return the ballot completed with the following information:
The following types of comments are of particular interest to the Director:
These comments and statements are non-binding, but do help the Director reach a decision.
The Team will provide two channels for Advisory Committee review comments: one Member-visible and one Team-confidential. AC Representatives may send information to one or both channels. For example, they may choose to make their choice known to the Membership but to send implementation schedule or other confidential information to the Team only. Comments sent to the Member-visible channel during the review period will be archived and made available to the Members no later than one week after the end of the review period.
If any ballots express opposition to the proposal (opinions three and four above), the Director must inform the Advisory Committee within one week after the end of the review period. The Director's comments should explain the opposition while ensuring the appropriate level of confidentiality. For a two-week period thereafter, Advisory Committee representatives may request to change their ballots. If five percent (5%) or more of the representatives (or fewer at the discretion of the Director) request to change their ballots, the entire review process will start from scratch according to the same procedures.
After the review period and any re-balloting, the Director announces the outcome of the proposal to the Advisory Committee. The Director may:
Created in March 1998 to provide guidance on strategy, management, legal matters, process issues, and conflict resolution, the Advisory Board ensures that W3C remains responsive to the needs of the Members as well as entities outside of W3C (notably other standards bodies).
The Advisory Board exists to provide rapid feedback to the Team on issues that are vital to W3C's operation and cannot wait until the next Advisory Committee meeting for resolution. The dynamism of the Advisory Board also enhances the quality of life for Members as Advisory Committee representatives may bring important issues to the attention of the Advisory Board.
The Advisory Board is not a board of directors that determines W3C's Activities and direction; the Members and Team have this role.
Advisory Board representatives are not required to work for Member Organizations. While Advisory Board participants are expected to act with the interests of the Consortium in mind, they are not expected to act against the interests of their organizations while doing so. Participants are expected to devote at least one day per month to Advisory Board activities and to participate in Advisory Board mailing list discussions.
Participants are elected to serve on the Advisory Board for two years. Elections are staggered; each year, the Advisory Committee elects representatives for half of the seats on the Advisory Board.
The election process begins with a call for nominations sent by the Director to the Advisory Committee. The call must specify the number of available seats, the deadline for nominations, the mailing list where nominations must be sent, and any other relevant information. Nominations should be made with the consent of the nominee and should include a few informative paragraphs about the nominee.
Once the deadline for nominations has passed, the Director issues a call for votes that includes the names of all nominees, the number of available seats, the deadline for votes, the mailing list where votes must be sent, and any other relevant information.
Once the deadline for votes has passed, the Director announces the results to the Advisory Committee. The nominees with the most votes are elected to fill the available seats. The term of those elected begins with the announcement to the Advisory Committee.
The Advisory Board will use a mailing list for its communications.
The Advisory Board will hold one remote meeting monthly and one face-to-face meeting annually. Advisory Board meetings are chaired by the Chairman. Advisory Board representatives are also encouraged to attend Advisory Committee meetings.
The W3C Chairman and Director (and possibly other members of the Team) participate in Advisory Board meetings.
The Advisory Board will present a report at each Advisory Committee meeting.
A Communication Team, composed of W3C Staff, will be responsible for managing communication within W3C and between W3C and the general public. The goals of the Communication Team are the following:
Unless otherwise stated (e.g., in legal matters), electronic documents have primacy over paper documents. When legal notifications, contracts, and other forms of communication requiring hardcopy must be exchanged between the Team and a Member organization, they must be sent to the appropriate Advisory Committee representative via a guaranteed-delivery service. Billing information may be sent to the designated contact person for each Member organization.
The primary language for W3C is English.
The W3C World Wide Web server has the address http://www.w3.org/. All documents, archives, and updates must be published at this site. The Web site must be kept up-to-date by the Communication Team and all other contributors to the site. Because the Web site is the sole source of so much critical information, every reasonable means must be used to guarantee its availability at all times. W3C assumes that public information on the Web site has a worldwide audience.
The Communication Team will maintain a document registry on the Web site. This registry will archive all active and obsolete W3C Technical Reports.
The Web site will also provide references to pertinent sources of information (electronic or other). This will allow W3C Members and the Team to keep up-to-date on external activities, and will lend credibility to W3C's Web site as a trustworthy source of impartial and quality information about the Web.
In addition to other information, the following documents will be available on the public portion of the W3C Web site at all times:
A portion of the Web site, known as the Member Web site, will be reserved for access by authorized W3C Members, Team, and other authorized people only. Members have access to this information at all times.
The Communication Team will provide security mechanisms to protect information at this site and will ensure that Members have proper access.
All documents appearing on the Member Web site must be treated as confidential within W3C. W3C Members must agree to use reasonable efforts to maintain this confidentiality and not to release this information to the general public or press. Documents that require particularly confidential treatment must be marked as such. An Advisory Committee representative may extend access to Member-only information to those fellow employees considered by the representative to be appropriate recipients. All recipients are expected to respect the intended (limited) scope of Member-only information.
The Member Web site includes a help page [MEM6] to assist Members in finding information and appropriate contacts within the Team.
A portion of the Member Web site will be reserved for each W3C group. It is each group's responsibility to maintain its own group archives (minutes, milestones, etc.) at this space.
The W3C Team will maintain one mailing list (mentioned above) for all official communications to AC representatives.
The W3C Team will maintain one mailing list for sending general information to W3C Members (including Newsletters, News announcements, etc.). The email address of each Member organization's AC representative will be on this list.
For both lists, the Advisory Committee representative's email address should suffice. However, upon request from the Advisory Committee representative and subject to approval by the Communication Team, additional addresses for the Member organization may be added to each list. The Member company must agree that redistribution of W3C mailings will be for internal use only. Failure to contain distribution internally may result in suspension of additional email addresses until the W3C Team can be assured of appropriate distribution.
An Advisory Committee representative may ask the Director, at the Director's discretion, to forward an open letter to either list.
The Communication Team may also establish other mailing lists to facilitate communication within a group. Only members of the group and W3C Team may be listed in such a mailing list. Each group is responsible for maintaining archives of these mailing lists on its group space.
For interaction with the general public, the Communication Team maintains general mailing lists to which anyone may subscribe and send messages.
The list of available mailing lists [MEM2] may be found at the W3C Web site.
The Communication Team will establish a mechanism for confirming and releasing W3C information to the press and/or general public. Press releases and comments to the press and public are primarily issued at the discretion of the W3C Director, except for those processes explicitly defined in this document.
To promote the active and open participation of all Member organizations, the Communication Team will maintain a calendar [MEM3] of events that shows all official events scheduled by W3C. Consortium-wide events will be differentiated from group events on this calendar. Archives of the calendar will be maintained on the Member Web site, with links to conclusions, email archives, and minutes from scheduled events.
Members and the Team should notify the Communication Team of events and schedules that should appear on the calendar and of changes to the calendar. The Communication Team will also notify Members of upcoming events through one of the Member mailing lists.
The Communication Team will provide a weekly news service to the Members. The Newswire [MEM8] provides brief information about Activities, calls for review, calls for participation, notifications of upcoming events, Director's decisions, acknowledged Submission requests, and more. The Newsletter [MEM4] provides more in-depth coverage of publications and events.
This section of the document specifies the mechanisms by which W3C initiates Activities, forms groups, and organizes events.
When W3C decides to become involved in an area of Web technology or policy, it initiates an Activity in that area. An Activity means that W3C resources -- people, time, money, etc. -- are dedicated to work in that area. Generally, an Activity is carried out by one or more groups.
At all times, the list of Activities currently being pursued by W3C [PUB9] is available at the public Web site. For Members, the list of Activities and all groups pursuing them [MEM7] is also available. A technological or policy area not declared at the Web site is not part of a W3C Activity.
Each Activity has an Activity Lead, the Team member who coordinates the work carried out within the Activity.
An Activity is created as follows:
Activities are extended, renewed or otherwise modified by following the Activity creation process. The proposal should explain the nature and rationale of the modification (e.g., there is a substantial increase in resources, a significant change in scope, etc.). The new briefing package should include the most recent Activity statement for the old Activity and a reference to the briefing package of the old Activity.
The Team will establish mechanisms for publishing all documents related to an Activity (see the guidebook [MEM9] for details).
An Activity statement documents the progress and evolution of an Activity. Activity statements should describe the goals of the Activity, list delivered work, changing perspectives based on experience, future plans, etc. Each Activity statement must be revised at least before each ordinary Advisory Committee meeting.
An Activity closes normally when its briefing package expires. It may close prematurely in the following circumstances:
Each Activity is initially defined by an Activity briefing package. Members or the Team (generally working together) create a briefing package and submit it to the Director for approval according to mechanisms established by the Team.
If the briefing package is rejected, the Director must provide the submitter(s) with a justification for the rejection.
If the briefing package is approved, it must be amended by the submitter(s) to include a detailed W3C resource statement (administrative, technical, and financial). The Director may also request an indication of resource commitment on the part of the submitter(s).
A briefing package must include the following information:
Groups are created to carry out W3C Activities. The type of group created depends on the nature of its tasks. Each group is defined by a charter and managed by a Chair.
Every group must have one Chair to coordinate the group's tasks. The Chair is appointed (or reappointed) by the Director.
W3C designates a Team contact for every group. The Team contact acts as the interface between the Chair, Group Members, and the Team. The roles of the Team contact are described in [MEM10].
Every group must have a charter that describes the following:
A group's charter must be approved by the Director (according to mechanisms established by the Team) before the Director can create the group.
For all face-to-face meetings, the group Chair will announce the dates and location of the group's next meeting at least eight weeks before the meeting. Shorter notice for a meeting is allowed provided that there is unanimous consent from every person on the group mailing list.
At least two weeks before the meeting, all group participants will be notified of the meeting's agenda. Participants must confirm their attendance with the Chair and the meeting organizer at least three days before the meeting.
Minutes of the meeting must be posted (through a mailing list and to the group's Web space) within two weeks after the meeting. Action items must be posted within two days after the meeting.
For all meetings, each absent group participant may nominate an alternate. At any one time, a participant may have one and only one chosen alternate.
For all remote meetings (telephone, IRC, etc.), the group Chair will announce that a meeting will take place at least one week before the meeting.
At least 24 hours before the meeting (or 72 hours if the meeting is on a Monday) all group participants will be sent an email specifying how to join the meeting (e.g., the telephone number) and the meeting's agenda. Participants unable to attend a meeting should notify the Chair at least 24 hours before the meeting.
Minutes of the meeting shall be posted (through a mailing list and to the group's Web space) within 48 hours of the meeting. Action items must be posted within 24 hours of the meeting.
For all meetings, absent group participants may nominate an alternate to act on their behalf.
Group participants and their alternates exchange information via a mailing list. The Chair should ensure that new participants are subscribed to all relevant mailing lists.
The names of available mailing lists [MEM2] may be found at the W3C Web site.
Each group will maintain a Web site. Each group's home page will be linked from the home page of the Activity to which it belongs. The list of W3C Activities [PUB9] is available online.
The following must be accessible to W3C Members at the group Web site, with links from the Activity home page:
The following information must be accessible to group and Team members:
The Director creates a group by announcing a call for participation to the Advisory Committee that includes a reference to the defining charter, the name of the group's Chair(s), the name of the Team contact, and an email address for participant nominations. The group does not exist prior to this announcement.
A call for participation in an group may be issued at the same time as the Director's announcement of a new Activity. In this case, the referenced charters are the provisional charters of the Activity proposal, potentially amended according to comments received during the review period, input from a Coordination group, etc.
A group must be created within the scope of an approved Activity. Note that no Activity statement may refer to a group until the group exists.
To join a group, individuals must be nominated by an Advisory Committee representative, either directly or indirectly. The Advisory Committee representative nominates the individual directly by sending email to the address indicated in the Director's call for participation in the group. Individuals are nominated indirectly by sending email to the address themselves, and copying their Advisory Committee representative. Group participants who do not represent a Member organization (invited experts) must still join a group by sending email to the indicated address.
Nominations must include the following information:
Individuals may join a group at any time during its existence and follow the nomination procedure specified in the original call for participation.
A group Chair may not reject a nomination, but the Director may. It is the responsibility of the Advisory Committee representative to ensure that nominees are qualified. Chairs should set expectations about the roles and qualifications of participants to assist the Advisory Committee representative.
See also the conditions that must be met by invited experts.
At times it may be necessary or desirable to modify a group's charter (e.g., to prolong it, to add a new work item, etc.).
Before any modifications are made, the Chair must determine whether the change is appropriate for the group (e.g., whether the group is the appropriate forum for a new work item) and reach consensus in the group about the change. Group participants who do not agree with the Chair's decision may raise objections through their Advisory Committee representative. In cases of unresolved disagreement, the final decision is the responsibility of the Coordination Group Chair, when the group is part of a Coordination Group. Otherwise, the Director will decide which groups will pursue which work items.
The Director must approve all proposed modifications to a charter. The Director must announce the modifications to the Advisory Committee and highlight significant changes (e.g., in resource requirements). The Advisory Committee has four weeks after the announcement to appeal the decision.
A group closes normally when its charter expires. It may close prematurely in the following circumstances:
This document defines four types of groups that may carry out W3C's Activities.
The following sections describe the procedures that govern each type of group.
A Working Group's purpose is to study a technical or policy issue involving the Web and to develop proposals for W3C Recommendations. Working Groups are created according to the procedures indicated in this document, including the procedure for charter submission and approval.
Someone is considered to participate in a Working Group if:
The following people may participate in a Working Group on an ongoing basis:
The Chair may ask an invited expert (who may or may not belong to a Member organization) to participate in a Working Group on a one-time basis. They may not participate in Working Group votes. One-time participation implies no commitment from the participant nor does it imply future participation or invitation to Working Group meetings.
To allow rapid progress, Working Groups are intended to be small (typically less than 15 people) and composed of experts in the area defined by the charter.
Participation on an ongoing basis implies a serious commitment to the Working Group charter, including:
A Chair may decide that a participant has lost good standing if either:
Chairs may relax these criteria if doing so will not set back the Working Group. For example, the Chair may relax the attendance requirement for expensive meetings (international phone calls or travel) for participants who do not have financial support. The Chair is expected to apply standards for good standing consistently.
When a participant risks losing good standing, the Chair must discuss the matter with the participant and the participant's Advisory Committee representative before declaring the participant in bad standing.
The Chair declares the participant in bad standing by informing the participant's Advisory Committee representative and the participant of the decision.
The Advisory Committee representative may appeal the decision to the Director. The Advisory Committee representative must make the appeal known to the Chair and the Team contact. In case of an appeal, the Chair may not alter the participant's standing before the Director has confirmed or denied the decision.
A participant regains good standing by meeting the participation requirements for two consecutive meetings. The Chair must inform the Advisory Committee representative of any change in standing.
Good standing is required to be able to vote. W3C considers that a Member organization is participating in a Working Group if at least one representative from the organization is in good standing.
Please consult the section on group communication for information about mailing lists and group Web sites.
Working Groups will organize both remote and face-to-face meetings.
Each Working Group (in conjunction with related Coordination Groups and the Communication Team) will post its intermediate results (called working drafts) to a public area of the Working Group Web space. Working drafts must be labeled as such. Please refer to the section on working drafts for information required in the status section of a draft document.
If a deliverable is code, proofs of concept and demonstrations should be published along with the code.
In addition to the deliverables specified in the Working Group charter, a Working Group will post its intermediate results to the public Web site at three-month intervals. The Working Group charter must specify the process for approving the release of these intermediate reports (e.g., consensus from the Working Group).
The following sections describe the processes by which Working Groups reach consensus, record minority views, appeal decisions, and vote when appropriate.
When resolving issues and making decisions, the goal of a W3C Working Group should always be to achieve unanimity of opinion.
Where unanimity is not possible, the Group must reach consensus (see the W3C consensus policy) by considering the ideas and viewpoints of all participants (including invited experts) who are in good standing. The Chair must be aware of which participants work for the same Member organization (or related Members) and weigh their input accordingly.
In establishing consensus, the Working Group must address the legitimate concerns of the minority. When a solution is available that addresses everyone's concerns, it should be preferred to a solution that carries approval of a majority (even a large one) but that causes severe problems to some members of the community. In general, it is desirable that a large majority of the Group favor a decision and that the minority accept the majority decision. However, at times it may be necessary (e.g., for timely delivery of a specification) to proceed with a large majority in favor and a small minority convinced in their hearts that the majority is making a mistake (possibly minor, possibly grave).
In order to ensure that the Chair can judge whether minority viewpoints can be accommodated, dissenting opinions must be accompanied by an indication of the technical reasons for the dissent and of what changes in the proposal, if any, would suffice to change the opinion to one assenting to the majority proposal. Dissents not explained in this manner need not be considered when the Chair decides whether consensus has been reached.
The Chair of the Working Group is responsible for ensuring that minority views are accommodated if possible. To that end, a Chair may occasionally ask members of the minority questions of the general form "Can you live with this decision?"
If holders of the minority view say they can live with a given decision, this will normally be taken as an indication that the group can move on to the next topic, but the inverse is not necessarily true: the minority cannot stop a Group's work simply by saying that they cannot live with the decision. When the Chair believes that the legitimate concerns of the minority have in fact been addressed as far as is possible and reasonable, then dissenting views will be recorded and the Group will move on.
Decisions may be made during meetings (face-to-face or teleconference) as well as through email. All decisions must be archived.
The Chair should archive decisions that are reconsidered (and must do so if requested by a Working Group participant). New information includes:
Minority views must be archived. If requested, the Chair must include archived minority views with other deliverables (e.g., in the Chair's report to the Director when a document goes to Proposed Recommendation). During an Advisory Committee Review, representatives must be able to refer to archived minority views. Minority views from the Team that are to be recorded should be sent by the Team contact for the Group.
All appeals, counterarguments, rationales, and decisions must be archived for reference (e.g., by the Working Group Chair).
At times, the Working Group may settle an issue by simple majority rather than by trying to establish consensus; the Chair will decide when majority voting is appropriate.
Working Groups should not use simple majority votes to resolve issues that have a technical or process impact, but only when the outcome is "arbitrary". As an example, while it is appropriate to decide by simple majority whether to hold a meeting in San Francisco or San Jose (there's not much difference geographically), it is inappropriate to vote on substantive technical decisions regarding the Working Group's deliverables.
When simple majority votes are used to decide minor issues, members of the minority are not required to state the reasons for their dissent, and the votes of individuals need not be recorded.
An issue resolved by simple majority vote may be reopened by the Chair as described above. A decision reached by majority vote may be appealed by a Working Group participant as described above.
The charter of a Working Group may include provisions for Working Group voting procedures (for example, in order for a proposal to pass, it must gain a particular proportion of participant votes or a particular proportion of the total membership of the Group).
Any such voting procedure must include the following:
In cases of deadlock, the Group or Chair may decide that it is necessary to proceed by way of simple majority vote; this step should be taken only in extreme circumstances. When simple majority voting is used to break a deadlock on a major issue when consensus cannot be reached, then the Chair must archive:
An Interest Group brings together people who wish to evaluate potential Web technologies and policies. An Interest Group does not have the goals of a Working Group -- development of specifications or code. Instead, it serves as a forum to explore cooperation and exchange ideas.
It is quite possible that an Interest Group's studies will lead to the creation of a Working Group, but this may not be known in advance nor is it guaranteed. Interest Groups are created according to the procedures indicated in this document, including the procedure for charter submission and approval.
See also how to join a group.
Interest Group Membership is not, in principle, limited in size. The following people may participate in an Interest Group on an ongoing basis:
Please consult the section on group communication for information about mailing lists and group Web sites.
Interest Groups will organize both remote and face-to-face meetings, but remote meetings should be the more common mode of communication.
From time to time, Interest Group participants may choose to vote on issues of policy or direction.
In an Interest Group, each Member organization or group of related Members is allowed one vote, even though each Member may have several participants in the group. If more than one vote is received from a Member organization or group of related Members, the votes are counted as one valid vote if they agree, otherwise they are ignored and the relevant Advisory Committee representative(s) will be notified of the discrepancy.
Voting proceeds as for Working Groups unless otherwise indicated.
The Interest Group charter must specify the type of deliverable the group intends to produce and with what frequency (e.g., a report summarizing the group's findings or comments on and requirements for the activities of other groups).
W3C Activities interact in many ways. There are dependencies between groups within the same Activity or in different Activities. There may also be dependencies between W3C Activities and the activities of other organizations. Examples of dependencies include the use by one technology of another being developed elsewhere, scheduling constraints between groups, the synchronization of publicity for the announcement of deliverables, etc. Or, a Working Group may decide that to pursue its goals more effectively, it should assign specific work to smaller task forces. In this case, the Chair may ask for a Coordination Group to be formed to manage the cooperating task forces (which may be either Working Groups or Interest Groups).
Coordination Groups are created when dependencies exist so that issues are resolved fairly and the solutions are consistent with W3C's mission and results.
When an Activity is proposed, dependencies should be made as explicit as possible in the briefing package. The briefing package may include a proposed charter for a Coordination Group (designed to coordinate groups described in the Activity proposal or to draw up charters of future groups).
It is also the case that dependencies arise after the creation of groups, and the Team should ensure that these are recognized and accepted by the parties involved. The Team should, where necessary, in consultation with Working Group Chairs, inform, create, and modify Coordination Groups when a new dependency is detected. When the issues within the scope of the Coordination Group are no longer being (or to be) addressed by W3C, then the Coordination Group should be closed.
Arbitration
W3C is a forum for those wishing to agree; it is not a battleground. At times, unforeseen dependencies may arise that are proposed by one group but that a related group does not wish to accept. Tension may also mount when expectations defined in a dependency are misunderstood or are not met. The Team should be informed of such tensions. Where a Coordination Group's scope covers the issues and parties involved, it is the first locus of resolution of such tensions. If agreement cannot be found between the Coordination Group and other groups involved, then the Team should arbitrate after consultation with parties involved and other experts, and, if deemed necessary, the Advisory Committee.
The charter of a Coordination Group must specify the scope of the group's work and the frequency of its meetings. The charter must also list the Working Groups or Interest Groups involved and the name of each group's contact for communication with the Coordination Group.
The charter of a Coordination Group must also specify whether the group may create new Working Groups. When new groups are created, they may not exceed the scope of the Coordination Group. In addition, any proposed Working Group may only proceed subject to the Director's decision that sufficient Team resources are available to support it and that other organizational and coordination work is not first required.
See also how to join a group.
The participants in a Coordination Group (defined in the charter) should represent the coordinated groups; participation should evolve as groups become newly dependent or independent. To promote effective communication between a Coordination Group and each group being coordinated, participation in a Coordination Group is mandatory for the Chair of each group being coordinated. The Coordination Group's charter may also specify other participants, such as invited experts or liaisons with other groups internal or external to W3C. The role of these additional participants should be clearly stated, as well as whether they are invited experts specified by name, invited experts in a specific field to be invited by the Chair, or representatives of particular organizations.
The Team, after consultation with Working Group Chairs, is responsible for ensuring that the Coordination Group structure is efficient and appropriate to its needs at each point in time, and making modifications to the list of participants as appropriate.
The Director appoints the Chair of a Coordination Group unless the majority of participants of the Coordination Group requests an election of the Chair. In case of an election, the Chair of the Coordination Group will be elected by majority vote from and by the Membership of the Coordination Group.
Please consult the section on group communication for information about mailing lists and group Web sites.
A Coordination Group will organize remote and/or face-to-face meetings. Reports of these meetings are to be published to Members on the Coordination Group's Web space.
A Coordination Group will publish reports on the Member Web site assessing the work and progress of the groups it oversees.
W3C may organize several types of shorter term events that do not demand on-going participation by Members or the Team.
This document defines three types of W3C events:
A workshop brings experts together for a single meeting, typically for one or two days. Workshops generally fall into two categories: those convened so that Members may exchange ideas about a technology or policy and those convened to address the pressing concerns of W3C Members.
Organizers of the first type of workshop should use the workshop to gather information about issues that interest its Members, opportunities to pursue activities, directions for W3C, and possible resource commitments. The organizers should plan a workshop program that includes position papers and talks. These papers should be distributed to other workshop attendees. The organizers may select among position papers to choose attendees and/or presenters. In order to allow speakers and authors adequate preparation time, the call for participation must occur no later than eight weeks prior to the workshop's scheduled date.
Organizers of the second type of workshop have a different goal: to address concerns of Members and resolve differences as quickly as possible. Although organizers must clearly specify the scope of the workshop in their proposal, they will not solicit papers. Due to the more urgent nature of this type of workshop, the call for participation must occur no later than six weeks prior to the workshop's scheduled date.
A workshop does not guarantee further investment by W3C in a particular topic. However, a workshop may result in proposals for new Activities or groups.
The Director announces (in a "call for participation") to the Advisory Committee that a workshop will take place. The call for participation must include the following information:
The Team schedules the workshop and coordinates (with Members and other interested parties) the workshop's program and organization.
Workshop minutes will be taken by the W3C Team and made available in the Member Web site. The minutes of the workshop must be published at the Member Web site before the Director may propose any new Activities to the Advisory Committee based on the workshop.
Any deliverables must be specified in the workshop call for participation. A W3C Team member will be assigned to edit any conclusions reached as a result of the workshop (e.g., a proposal that W3C examine this topic more closely in a new or existing group).
A symposium brings interested parties together for expert presentations on a given subject. Typically lasting one or two days, a symposium is intended to educate.
A symposium is initiated following the same procedure as for a workshop (type one). However, the call for participation in a symposium includes the following information instead:
There are no deliverables or criteria for success for a symposium.
A symposium is open to all W3C Member organizations. Seats should be allocated evenly to all W3C Member organizations, but seats not claimed one month before the registration deadline may be released and re-allocated equitably to other W3C Members.
Minutes shall be taken by the W3C Team and made available at the Member Web site.
A conference is a large, multi-subject, multi-day meeting. W3C does not, as a general rule, organize conferences. It does, however, sponsor the World Wide Web Conference. This conference is coordinated by the International World Wide Web Conference Committee (IW3C2).
The W3C Submission process allows Members to propose technology or other ideas for consideration by W3C. The formal process affords the submitters a record of their contribution and gives them a mechanism for disclosing the details of the transaction with the Team (including IPR claims). The Submission process also allows the Team to review proposed technology and accurately relay the status of Submission requests to the media.
Note. Members do not submit Notes to W3C; they make Submission requests. A Note is one artifact of an acknowledged Submission request.
Note. The Submissions process is not related to the W3C Recommendations track. Documents that are part of a Submission request have been developed outside of W3C. Members do not submit documents to W3C for "ratification" as Recommendations.
The Submission process begins with a Submission request from representatives of one or more Member organizations (and only Member organizations) to the Director. Organizations that are not Members of W3C may not send Submission requests directly to W3C (either alone or in conjunction with submitting Members). Submitters should refer to the submission request template [PUB13] published at the W3C Web site.
To send a Submission request:
The Submitter will receive prompt notification that the Team has received the Submission package.
If for any reason the Submission request is deemed incomplete or incorrect by the Team (e.g., the Submission package lacks information, documents in the Submission package are invalid, confirmations of position statements have not been received, Member agreements from participating companies have not been signed, etc.), the Team will help the Submitter complete and correct the request.
The Team sends a validation notice to the Submitter as soon as the Team has reviewed any Submission request and judged it complete and correct. The Director then reviews the validated Submission request and either acknowledges or rejects it. The Submission request is acknowledged only after the Director has announced the decision to the Advisory Committee. This announcement must occur between one and four weeks after the validation notice. The announcement may come at any time during the three-week window, but the Team must tell the Submitter, within one week of the validation notice, when the announcement is most likely to occur.
Prior to the acknowledgment, the Submission request must be held in the strictest confidentiality by the Team. In particular, the Team must not comment to the media about the Submission request.
Under no circumstances may a document be referred to as "submitted to the World Wide Web Consortium" or "under consideration by W3C" or any similar phrase, nor should there be any implication made that W3C is working on a specification or with a company prior to the acknowledgment.
The Submitter may withdraw the Submission request at any time prior to acknowledgment. W3C will not make statements about withdrawn Submission requests.
Submitting organizations have the right to publish the documents in the Submission package before acknowledgment. However, the W3C name cannot be used in this publication.
Only after the Director has acknowledged the Submission may the submitting organizations refer to it as having been submitted to W3C. There may be no implication made to any further or required action by W3C until and unless the item is taken up as part of a W3C Activity.
Once the Director has acknowledged a Submission request, the Team:
Publication of a Note by W3C indicates no endorsement by W3C, the W3C Team, or any W3C Members. The acknowledgment of a Submission request does not imply that any action will be taken by W3C. It merely records publicly that the Submission request has been made by the submitting Member. This document may not be referred to as "work in progress" of the W3C.
The list of acknowledged Submissions [PUB10] may be found at the Web site.
A Submission request may be rejected by the Director on the following grounds:
If the subject of a Submission request is already being addressed by a Working Group and the Director feels that acknowledging the Submission request would interfere with the group's work (e.g., for reasons of confidentiality), the Director may ask the Submitter to take the proposal to the Working Group. The Submitter may proceed with the Submission track nevertheless, but ultimately the Director may choose to reject the request.
In case of a rejection, the Director will inform the Submitter's Advisory Committee representative. The Submitter may appeal the decision to the Advisory Committee. No statements will be made by W3C about the reasons why a Submission request was rejected.
A Submission package must include the following information:
The Submission request must include complete electronic copies of any pertinent documents. The Communication Team will establish a policy for which electronic formats (e.g., HTML) it will accept and criteria that must be met prior to publication (refer to conventions for creating and publishing documents [MEM11]). Please refer to general information about documents and the section describing W3C Notes for more information.
The Submission request must also address the following questions:
W3C publishes several types of technical reports:
All public technical reports [PUB11] are available at the Web site. W3C will make every effort to make archival documents indefinitely available at their original address in their original form.
The W3C Team will establish conventions for creating and publishing documents [MEM11] and will publish these conventions on the Web site. In general, the Team will not publish a document as a public W3C Technical Report unless it follows these conventions (for naming, style, copyright requirements, etc.). The Team reserves the right to reformat documents at any time so as to conform to changes in W3C practice (e.g., changes to document style or the "Status of this Document" section).
All Notes, Working Drafts, Candidate Recommendations, and Recommendations must include a section indicating the status of the document. The status section of a document should explain why W3C has published the document, whether or not it is part of the Recommendation track, who developed the document, where comments about the document may be sent, and any other metadata about the document deemed relevant by the editors. The status section indicate the document's maturity level (Working Draft, Candidate Recommendation, or Recommendation).
Each document produced by a group will be edited by one or more editors appointed by the 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 document. Document editors need not belong to the W3C Team.
The primary language for official W3C documents is English. In addition to the official English version of a document, W3C welcomes translated versions. Information about translations of W3C documents [PUB18] is available at the Web site.
At times, it may be deemed necessary to make hitherto confidential documents public. Any proposal to make a document public must be approved by a majority of the Advisory Committee through the review process. If approved, the document may be published in the public Web site (e.g., as a Note) at the discretion of the Director.
W3C Working Groups are generally chartered to produce documents (e.g., technical specifications, guidelines, etc.) The W3C "Recommendation Track" refers to the process by which a document is revised and reviewed until considered mature enough by the Membership and Director to be published as a Recommendation.
The following labels refer to the level of maturity of a document:
Every document must clearly indicate its maturity level.
For a document to become a Recommendation, it must begin as a Working Draft and follow the process described below. Generally, Working Groups create Working Drafts with the intent of advancing them along the Recommendation track. However, publication of a Working Draft does not guarantee that it will advance to Candidate Recommendation or Recommendation. Some Working Drafts may be dropped as active work, others may be subsumed by other Working Drafts, still others may be published as Notes.
A W3C Recommendation may be submitted to other standards bodies for ratification by their constituencies, however this is not required or guaranteed. Additionally, steps in the process below might be modified in order to properly coordinate W3C activities with other related Standards Development Organizations.
A Working Draft is a chartered work item of a Working Group and generally represents work in progress and a commitment by W3C to pursue work in a particular area. At least every three months, a Working Group must publish a (public) Working Draft to keep the community abreast of its progress and to prompt the Working Group to resolve issues in a timely fashion. The first public Working Draft (or release of the document for review beyond the Working Group) must be approved by the Director.
Publication of a Working Draft is not an assertion of consensus, endorsement or technical and editorial quality. The Working Draft may be unstable and it may not address all Working Group requirements, though the Chair should endeavor to obtain Working Group support for publication within the constraints of the requirement to publish every three months.
A Working Draft must include a paragraph in the status section of the document that makes clear that the document may change at any time, does not represent consensus from W3C or its Members, and may not be cited as other than a work in progress. Here is a sample paragraph for a public Working Draft:
This is a public W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current public W3C Working Drafts can be found at http://www.w3.org/TR.
A Last Call Working Draft is a special instance of a Working Draft that is considered by the Working Group to meet the requirements of its charter. The Working Group publishes a Last Call Working Draft in order to solicit review from at least all dependent Working Groups (copying Chairs of known dependent groups). External feedback is also encouraged. A last call announcement must recapitulate known dependencies. It must also state the deadline for comments (e.g., three to four weeks is issued). The Last Call Working Draft must be a public document.
To ensure the proper integration of a specification in the international community, documents must, from this point on in the Recommendation process, contain a statement about how the technology relates to existing international standards and to relevant activities being pursued by other organizations.
Once the last call period has ended, all issues raised during the last call period resolved, and the Working Draft modified if necessary, the Working Group may request that the Director submit the document for review by the Advisory Committee as a Candidate Recommendation. It is possible that comments will cause substantive changes that require that the document return to Working Draft status before being advanced to Last Call again.
A Candidate Recommendation has received significant review from its immediate technical community (resulting from the Last Call). Advancement of a document to Candidate Recommendation is an explicit call to those outside of the related Working Groups or the W3C itself for implementation and technical feedback. There is no requirement that a Working Draft have two independent and interoperable implementations to become a Candidate Recommendation. Instead, this is the phase at which the Working Group is responsible for formally acquiring that experience or at least defining the expectations of implementation.
The Working Group's request for advancement to Candidate Recommendation should include a report of present and expected implementation of the specification. The request must also specify a duration for the implementation period. If, at the end of that time, the Working Group has not requested that the document advance to Proposed Recommendation, the document returns to Working Draft status. A Candidate Recommendation may be updated while in review if those updates clarify existing meaning or consensus. Substantive changes that require coordination with other groups will cause the document to return to Working Draft status. The Working Group may request that the implementation period be shortened or lengthened, subject to approval by the Director. The request must explain the reasons for the change.
The Working Group may request that the Director advance a document directly from Working Draft to Proposed Recommendation status under two conditions:
A Proposed Recommendation is believed by the Working Group to meet the requirements of the Working Group's charter and to adequately address dependencies from the W3C technical community and comments from external reviewers. The Director issues a call for review of a Proposed Recommendation (accompanied by other materials such as documented minority opinions, implementation status, etc.) for political and promotional support and feedback from the Advisory Committee (refer to how to start Member review of a Proposed Recommendation [MEM12]). The review period may not be less than four weeks.
Although the Advisory Committee may also comment on technical aspects of a specification, most technical issues should have already been resolved at this phase. There is no requirement that a Candidate Recommendation have two independent and interoperable implementations to become a Proposed Recommendation. However, such experience is strongly encouraged and will generally strengthen its case before the Advisory Committee.
The editors of the Proposed Recommendation must respond to substantive comments from the Advisory Committee until the end of the review period.
No sooner than two weeks after the end of the review period, the Director announces the outcome of the proposal to the Advisory Committee. The Director may:
A Recommendation reflects consensus within W3C, as indicated by the Director's approval. W3C considers that the ideas or technology specified by a Recommendation are appropriate for widespread deployment and promote W3C's mission. W3C will make every effort to maintain its Recommendations (e.g., by tracking errata, providing testbed applications, helping to create test suites, etc.) and to encourage widespread implementation.
Editorial changes may be made to a W3C Recommendation after its release in order, for example, to clarify an issue or correct minor errors. The status section of a revision should indicate that it supersedes previous versions. The Communication Team will notify the Members when a revised Recommendation is published.
If more substantial revisions to a Recommendation are necessary, the document must be returned to the Working Draft phase and the Recommendation process followed from the beginning.
Documents may stay at the Recommendation level indefinitely, though the status section of a Recommendation should indicate whether other documents supersede it (or are expected to).
A Note is a dated, public record of an idea, comment, or document. Notes are published on the Web site at the discretion of the Director and may be published at any time. The publication of a Note does not imply endorsement of its contents by W3C. The status section of a Note indicates whether or not W3C has allocated resources to the topics covered by the Note.
Notes are used in the following situations:
The status section of a Note must state whether W3C has allocated and/or will allocate resources to the work covered by the Note. The status sections of every Note must include this statement:
This document is a NOTE made available by the W3C for discussion only. Publication of this Note by W3C indicates no endorsement by W3C or the W3C Team, or any W3C Members.
If W3C has no resources allocated to the note, include this statement (modifying it appropriately) as well:
No W3C resources were, are, or will be allocated to the issues addressed by the NOTE.
If the document was not prepared or authored by the Team, include this statement as well:
W3C has had no editorial control over the preparation of this Note.
If the Note is the result of a acknowledged Submission request, it must contain the following statement:
This Note is the result of an acknowledged Submission request. Publication of this Note by W3C indicates no endorsement by W3C, the W3C Team, or any W3C Members. W3C has had no editorial control over the preparation of this Note. The acknowledgment of a Submission request does not imply that any action will be taken by W3C. It merely records publicly that the Submission request has been made by the submitting Member. This document may not be referred to as "work in progress" of the W3C.
Like any other Activity in W3C, the W3C process may require amendment from time to time.
If a Working Group is created to amend the process, participation in the Working Group is open to any Advisory Committee representative. Participants are expected to attend all the Advisory Committee meetings that take place during the Working Group's existence.
Voting will proceed as described for other Working Groups.
The Process Document describes the processes that govern the W3C. The Process Document must be revised after a decision to modify the process. It may be revised regularly to incorporate clarifications or correct errors.
When a Process Working Group is created to modify the process (major changes), its charter must propose the editor(s) who will revise the process document. When no Process Working Group is created to modify the process (medium or minor changes), the Director appoints the editor(s) who will revise the process document.
This document was initially prepared by the Process Working Group (WG) of the World Wide Web Consortium. The Working Group was elected by the W3C Advisory Committee representatives on September 16, 1996 and consisted of the following individuals:
The Team Members involved in producing this document were:
| Process | Initiated by | Intended for | Time to next step | Next step |
|---|---|---|---|---|
| Activity proposal | Director | Advisory Committee | Four weeks | Director's decision. If approved, Director issues calls for participation in Working Groups. Director sends comments received during the review period within one week after end of review. |
| Working Group Meeting announcement. | Working Group Chair | Working Group (notably Team contact) | Eight weeks for face-to-face. One week for remote. | Meeting, followed by publication of minutes. |
| Working Draft Last call | A Working Group Chair | All Working Group Chairs | Generally two to four weeks | Proposed Recommendation |
| Proposed Recommendation | Director | Advisory Committee | At least four weeks | Director's decision, which comes at least two weeks later. If approved, becomes a Recommendation. |
| Submission request | Member | W3C Team | After Submission package is validated by Team, one to four weeks. | Director's acknowledgment or rejection of request. |
| Call for nomination to Advisory Board | Director | Advisory Committee | Specified in call. | Call for votes from Director to Advisory Committee. Duration of election period specified in call. |
| Workshop announcement | W3C Team | Advisory Committee | Eight weeks if for information gathering, six weeks if to deal with pressing issues. | Workshop. |
The home page of the W3C Web site: http://www.w3.org/
The work of the IETF in places may overlap with the Activities of W3C. To allow clear progress, it is important for the role and domain of operation of each organization to be well defined and for communication between the two organizations to be efficient.
The IETF works in an entirely open manner: meetings are generally attended, by email or physically, by anyone who wishes to participate. W3C, by contrast, is a Consortium of organizations that pay a Membership fee to support its operation (Membership is open to any organization). W3C has a process for assigning defined groups of committed experts to solve specific tasks.
As a result of these differences, IETF working groups tend to be effective both for the collection of ideas from a wide community, and also, when a specification exists, for providing criticism from a wide community. W3C is effective at producing, in a timely fashion, a specification that is likely (though not guaranteed) to meet the needs of its Members and the community.
The IETF addresses specifically issues of Internet protocols while W3C addresses the architecture of the Web -- the global information space that is implemented by using Internet protocols and other tools.
W3C defines the Web, Web documents, and protocols for their access and distribution. W3C is the home of the HTML specifications, for which it brings together expertise in many areas outside the IETF. It also addresses the questions of intellectual ownership of documents, rating schemes for documents and the transport of labels (PICS), and in general the metadata that is information about documents.
W3C intends not to be involved with the specifications for IP, TCP, or DNS, for security at any of these levels; with SMTP or NNTP protocols.
The HTTP protocol has been developed with W3C participation in an IETF context. This is the area in which IETF experience has been very relevant, and W3C effort is provided in order to help attain a timely result.
The URI scheme is the central specification of the Web. Although it is fairly stable, its extension, where necessary, lies within the scope of W3C Activities. It would be appropriate for W3C to include a new naming scheme developed by a third party (or the IETF) into the URI specification.
Every effort must be made for open communication and cooperation between W3C and the IETF so that, for example, two versions of a specification do not evolve independently as a result of separate work. Such fragmentation thwarts the principle of interoperability so vital to W3C success.
This section summarizes the partnerships (potential or other) for the W3C with other organizations. A partnership begins with a written agreement between W3C and some other organization that specifies how the partners will participate in a given Activity.
Each table entry below addresses the following questions:
| Groups Relevant to W3C | Contribution to W3C or Web | Interested in working with W3C | Cost of Liaison | Special expertise from W3C |
| IETF Internet Engineering Task Force | Internet Infrastructure | Relationship needs to be focused, identify specific groups and people to meet. | High, knowledge of the organization is well known, but a close
relationship needs to be built.
Resource costs are high to participate in IETF Working Groups under their organizational structures rather than the W3C's. |
HTTP, URNs, Naming |
| ISO Standards - International
Organization for Standardization; includes national bodies standards |
ISO TC
46; Standards for Thesauri, Indexing, Bibliographies, and Searching.
ISO TC 68;
ISO TC 154;
ISO TC 187;
ISO/IEC WG2 SC2;
US Z39.50;
ANSI X9;
ISO/IEC JTC1; Information Processing, |
Yes, W3C was requested to provide liaison in HTML and graphics. | High, organization is complex. W3C Advisory Committee meeting June 1996 was
against following the PAS ISO procedure.
ISO organizations run at a different speed. |
HTML and graphics. |
| OMG Object Management Group Consortium | CORBA, IIOP, Enterprise Users | Strong Yes | Low | Architecture Areas, HTTP |
| OASIS-open | SGML Standardization and Expertise | Medium/Low | Low; primarily requires knowledge of relevant activities as they happen and making comments about possible changes to SGML. | HTML, XML |
| The Open Group (X/Open, Uniforum, OSF, SAG) | Active X, Validation Suites, Reference Implementations | Strong Yes | Low | Architecture and User Interface Areas, PICS |
| Unicode Consortium | Character encoding, character properties | Yes | Low | Markup, Language tagging, etc. |
| WAP Forum - Wireless Application Protocol | Protocols for mobile devices | Strong Yes | Low, because Mobile Interest Group already exists | See WAP Forum - W3C Cooperation White Paper |
| Government Regulators, European Commission, US Govt., G7,... | Regulatory Control | Depends | High, personal visits to each government and group are required. | Technology and Society Areas |