This document has been superseded. Please consult the latest public process document.
This document describes the processes that govern the activity of the World Wide Web Consortium (W3C).
This document has been prepared by the Process Working Group (WG) of the World Wide Web Consortium. The WG was elected by the W3C Advisory Committee Representatives on September 16, 1996 and comprised the following individuals:
The Consortium Team Members involved in producing this document were:
A list of changes to public versions of this document is available.
This revision $Revision: 1.2 $
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. 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 should be recorded 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 consensus by those participating in the decision -- the decision does not reflect a single market and therefore the group has failed to reach true consensus.
All W3C final results are made available free of charge to the general public. 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 therefore get implemented in products and services, W3C may call for public comments about intermediate documents.
Unless otherwise stated, all announcements, replies, confirmations, notifications, votes, minutes, and other documents exchanged within W3C will be electronic (e.g., email, mailing lists, and the Web site).
In its quest for universality, 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 a Full Member agreement [PUB6] or an Affiliate Member agreement [PUB7].
W3C has no membership class for individuals, although individuals may participate in W3C's activities via W3C's public mailing lists. Individuals may also participate as invited experts at the Director's discretion, or may join W3C as Affiliate Members.
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.
The W3C Team consists of a Chairman, a Director and Staff. The Team coordinates the global activities of W3C. It is their responsibility to:
The specific roles of the W3C Chairman, W3C Director and W3C Staff members are described throughout this process document.
This document describes expectations the Members have of the Team and the Team of the Members. Activities of W3C take place through the actions of the Team, and mechanisms and procedures set in place by the Team, which are not described in detail in this document. The Team provides such information primarily on the Member Web site as the primary resource, and is personally at the disposition of members through the appropriate staff contact.
To improve the cooperation between the Members and the Team, Member organizations may send visiting engineers to work with the Team on host sites.
The Advisory Committee (AC) has several roles within W3C:
The Advisory Committee consists of one representative from each Member organization. This representative is named in the Membership Agreement when the organization joins W3C [PUB5]. When a Member organization wishes to change its AC representative, the departing representative should notify the Director of the change by email. If the departing AC representative cannot be contacted, the new representative shall be confirmed by a responsible officer of the Member organization.
The AC representative is the official link between the Member organization and the Team. Thus, the AC representative is responsible for receiving information from the Team (such as the newsletter, calls for interest, participation, votes, etc.) on behalf of the Member organization, and acting as the conduit for the Member organization's official statements, positions, votes, and submissions to the Team.
The specific roles of the AC representatives are described throughout this process document.
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 AC mailing lists [MEM2] may be found at the W3C Web site.
At each Advisory Committee meeting, the W3C Team will provide Member organizations with an update of key W3C information, including:
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.
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 AC 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 AC meeting, a mailing list will be established (and AC representatives notified) by which AC representatives may suggest topics of discussion for the meeting. Suggestions must also be sent to the mailing list for internal AC 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 will be asked to vote whether to initiate an activity, whether to approve a Proposed Recommendation, etc. An announcement requesting votes will be sent to the Advisory Committee; all votes must be received within four weeks thereafter. Votes must be sent to the address indicated in the announcement.
Each unrelated Member organization is allowed one vote through its AC representative. Each group of related Members is also allowed one vote, exercised by an AC representative chosen by the group. In the event that the AC representative is unable to vote, another person in the organization may submit the vote accompanied by a statement that the voter is acting on behalf of the official representative. The official representative must receive a copy of this vote. If more than one vote is received from a Member organization, the votes are counted as one valid vote if they agree, otherwise they are ignored and the AC representative will be notified of the discrepancy.
Any vote may include comments, but all No votes must be accompanied by substantive comments explaining the voter's rationale.
Comments (e.g., issues of intellectual property rights) accumulated during the voting period shall be sent to all AC representatives within one week after the end of the voting period. If any No votes are received, for a two-week period, representatives may request to re-vote based on comments and other new information. If five percent or more of the representatives (or fewer at the discretion of the Director) request to re-vote, the entire voting process will start from scratch according to the same procedures.
Once all voting has ceased, the Director may elect to do one of the following:
A Communication Team 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 Communication Team will be made up of W3C Team members.
The Communication Team will use a variety of mechanisms to complete its tasks.
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 world-wide audience.
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. At all times, Members have access to all information at this site.
All documents appearing on the Member Web site must be respected by those authorized to consult the site 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.
A suitable security mechanism, managed by the Team, will be used to screen out unauthorized viewing and each AC representative will be instructed on how to gain access. The AC representative may extend access to Members-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 Members-only information.
The Member Web site includes a help page [MEM6] to assist Members in finding the right contact or location for information.
A portion of the Member Web site will be reserved for each W3C group. It is each group's responsibility to maintain its own archives (minutes, mailing lists, etc.) at this space. See the section on group Web sites for more information.
The following types of documents must be available to the general public on the Web site at all times:
The Communication Team will maintain a document registry on the Web site. This registry will archive all active and obsolete W3C documents (including URLs to each document) that bear a document name.
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.
The W3C Team will maintain one mailing list for all official communications to AC representatives. The email address of each Member organization's AC representative will be on this list.
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 AC representative's email address should suffice. However, upon request from the AC 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 AC 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 scheduled official events of 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 publish a newsletter [MEM4] containing updates on W3C activities, announcements of meetings, workshops and conferences, and a calendar of upcoming events.
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 staff salaries, detailed budgeting, and other business decisions must be held in confidentiality between the Team and the host institutions.
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. The activity is carried out by one or more groups, which may already exist or be created for the purpose of pursuing the new activity (e.g., as the result of a workshop on how to organize the activity).
At all times, the W3C Web site publishes the list of activities currently being pursued by W3C [PUB9].
A technological or policy area not declared at the Web site is not the object of a W3C activity.
To initiate an activity, any W3C Member may submit an activity proposal to the Director. Acceptance by the Director implies that there is adequate interest to commit W3C resources to the next phase.
Members of the Team can also propose an activity subject to the Director's approval, if they believe that there is adequate Member interest to warrant the activity. The Team may solicit Member input when compiling its activity briefing package.
Each activity proposal must be accompanied by an activity briefing package that defines the activity. The issues discussed in the activity briefing package depend on the nature of the activity. For a technical or strategic activity, the activity briefing package must address the following questions:
For a policy or process issue, the activity briefing package must address the following questions:
The briefing package must specify the structure of groups and/or events foreseen for the proposed activity. The briefing package must also contain the provisional charters for any groups that will be created as a result of the briefing package. Groups may be scheduled to run concurrently or sequentially (either because of a dependency or an expected overlap in membership and the desirability of working on one subject at a time).
The briefing package may specify the threshold level of effort that Members must pledge in order for the activity to be accepted.
The W3C Web site contains an activity briefing package overview [PUB12], including samples.
If the submitters of an activity briefing package wish to assign a new work item to the charter of an existing group, they must first consult with the group Chair. The Chair may judge whether the Group is appropriate for pursuing the work item in question. Consensus about whether an existing group will pursue a new work item must be reached before the activity briefing package is submitted to the Director.
Group members who do not agree with the Chair's decision may raise objections through their AC representative. In cases of unresolved disagreement, the final decision is the responsibility of the Coordination Group Chair if the group is part of a Coordination Group. Otherwise, the Director decides whether the existing group or groups will pursue the new work item.
If it is decided that an existing group will pursue a new work item, the group's charter must be amended accordingly.
The Director has the role of acknowledging or rejecting an activity proposal.
If a proposal is rejected, the Director must provide the submitter(s) with a justification for the rejection.
If an activity proposal is acknowledged, it must be amended by the submitter with 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).
At this point, the activity proposal and supporting documents are sent to all Advisory Committee representatives, accompanied by a ballot. The AC representatives have four weeks to study the proposal and return their ballot with any comments. Comments that demonstrate serious flaws in the proposal, reflect burdensome resource allocations, reveal invalid or confused deployment methodologies, or illustrate an "out of scope proposal" are critical to the outcome of a proposal.
AC members are encouraged to include information in their ballots that might help the submitters amend their provisional charter, should the activity briefing package be accepted. Topics of particular importance include how the activity relates to existing activities in other organizations, how a Recommendation might relate to an existing international standard, etc. All comments will be archived so that anyone on the AC may review them.
The Director will review all comments and decide whether to accept or reject the proposal. The final decision will be based on the AC representatives' comments, projections as to whether W3C is likely to achieve market consensus, and the Director's personal and professional experience.
The first meeting of a group carrying out a new activity may occur, at the earliest, four weeks after the submission of the activity briefing package. The proposed date of the first meeting must be indicated in the activity briefing package.
Once an activity has been accepted, the Team must publish the briefing package information on the public Web site as an activity statement. The information may be amended as a result of Member or Team comments, to remove confidential information regarding Member or Team staffing levels, etc. The activity statement should be revised at least before each ordinary Advisory Committee meeting to include a current description of the activity, its goals, and rationale. Revised versions should include a statement of delivered work. If the analysis made in the initial briefing package becomes outdated, the revision should clearly state so.
Recall that at all times, the W3C Web site publishes the list of activities currently being pursued by W3C [PUB9].
An activity statement may be modified such that details (e.g., in group charters) are elaborated or adjusted to meet the goals of the activity within the spirit of the original briefing package. The Director must decide whether a revised activity statement continues to reflect the spirit of the briefing package. AC representatives may appeal this decision to the Advisory Committee.
If the Director decides that a revised activity statement no longer reflects the spirit of the original briefing package (e.g., it requires a substantial increase in resources, a change in scope, etc.), then the current activity must cease in its current form and a new activity must be proposed, according to the procedure for new activities. The revised activity statement should be part of the briefing package for the new activity.
Any activity may be terminated prematurely in the following circumstances:
All groups abide by the following procedures.
Every group must have one Chair to coordinate the group's activities. The Chair is appointed (or reappointed) by the Director.
Every group must have a charter that describes the following:
The group's charter must be approved by the Director. .
When a group's work lasts longer than the time period specified by its charter and there is consensus that the group should continue, the charter may be renewed.
If the group whose charter is about to expire is a "top level" group (i.e., a Coordination Group, Project, Interest Group, or sole Working Group), the charter must be revised and submitted to the Advisory Committee for approval.
If the group whose charter is about to expire is managed by a "top level" group, the revised charter must be approved by the Director. The Director must announce that the charter has been prolonged to the Advisory Committee. Such charters are assumed to have been approved by the AC four weeks after the Director's announcement unless at least 5% of the AC representatives request to vote on the revised charter during that period.
The same process applies to charters that must be modified for any reason (e.g., the addition of a new work item).
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. New participants must ask the Chair to be included on the mailing list.
The names of available mailing lists [MEM2] may be found at the W3C Web site.
Each activity leader (or delegate, possibly the Chair or document editor) will maintain a Group Web site structured as follows:
Each group's home page will be linked from the Activity home page [PUB9].
The following must be accessible to W3C Members, with links from the Activity home page:
The following information must be accessible to group and Team members:
W3C Activities may involve a variety of tasks, which must be defined in the briefing package. Examples include:
A group may be created, for example, as a result of an accepted activity briefing package A group does not officially exist until a charter has been drawn up for it and has been accepted by the Director, and the creation has been notified to the Advisory Committee.
Any group may be terminated 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.
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. The following people may participate in a Working Group on an ongoing basis:
Participation on an ongoing basis implies a serious commitment to the Working Group charter. Participation includes:
Participants who meet these criteria (and new participants) are considered to be "participants in good standing". If a participant cannot meet these criteria, either (a) by missing more than one of every three remote meetings or more than one of every three face-to-face meetings, or (b) by not providing deliverables in a timely fashion twice in sequence, the participant falls out of good standing. The AC representative of a participant's organization will be informed of all failures by the participant to remain in good standing.
The Chair may relax the attendance requirement for expensive meetings (international phone calls or travel) for invited experts who do not have financial support.
The status of voting participant may be regained by meeting the participation requirements for two consecutive meetings.
Good standing is required to be able to vote. Those not in good standing (and their alternates) are dropped from the Working Group mailing lists.
W3C considers that a Member organization is participating in a Working Group if at least one representative from the organization is in good standing.
The following may participate in a Working Group on a one-time basis:
One-time participation implies no commitment from the participant and nor does it imply future participation or invitation to Working Group meetings.
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.
From time to time, Working Group participants may choose to vote on issues such as the details of a specification. Only participants in good standing may vote. All votes shall be sent to both the group Chair (or a designee) and the Working Group mailing list.
The purpose of a Working Group vote is to identify roadblocks to consensus, and thus the voting process is designed to solicit constructive criticism from voters. All No votes must be accompanied by either a list of modifications that would change the vote to Yes, or an explanation as to why the project should be abandoned.
If more than one vote is received from a Member organization or a group of related Members, the votes are counted as one valid vote if they agree, otherwise they are ignored and the relevant Advisory Committee representatives(s) will be notified of the discrepancy.
Once all votes have been received, the Chair is responsible for resolving the issues that motivated the No votes. The Chair may do so either by revising the deliverable in such a way as to take the comments into account, or by providing a reason why the comment is not valid. The Chair may also eliminate stumbling blocks to consensus by creating two deliverables instead of one -- one for those topics amenable to consensus, the other for those topics requiring further study or agreement.
A successful yes vote occurs when three-fourths of the voting participants have voted yes and when the Working Group Chair decides that all substantive No comments have been addressed.
A Working Group may write slightly different voting rules into its charter. If such a charter is approved, those Working Group-specific voting rules will apply.
Each Working Group will post its intermediate results (called working drafts) to a public area of the Working Group Web space. Working drafts will be labeled as such. They will also include the following disclaimer in a section specifying the status of the document:
This is an working draft. W3C is not responsible for any implementations based on this draft. This draft may or may not be proposed as a Recommendation, and may change at any time and without notice.
If a deliverable is code, proofs of concept and demonstrations should be published along with the code.
The Team and any Coordination Groups whose scope includes the Working Group should be notified whenever there is a likelihood that a deliverable may not be produced on time, and a new date negotiated.
In addition to the deliverables specified in the Working Group charter, a Working Group will post its intermediate results to a public area of the Working Group Web site at three month intervals. The Working Group charter must specify the process for approving the release of these intermediate reports.
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.
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 Activities in different parts of W3C structure. There may also be dependencies that have been accepted between W3C and external groups. The Team should ensure that work throughout W3C is consistent, and the dependencies are acknowledged and met. Toward this purpose, Coordination Groups may be created.
Examples of dependencies include the use by one technology of another technology in the process of definition by another group, or the scheduling constraints, or the synchronization of publicity for the announcement of deliverables.
Coordination Groups are created to manage dependencies between groups within the well defined scope of a certain issue, or issues.
For example, a Working Group may decide that to pursue its goals more effectively it should break down its tasks and assign them 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).
When Activities are created, dependencies are made as explicit as possible in the Activity Proposal. A Coordination Group may be created initially when an activity is created, by being included in the proposal. A special case is that a Coordination Group may be created as an initial and only group, and tasked with defining the charters of, and proposing new Working Groups to address the issues within its scope.
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. Whereas generally this happens by direct negotiation between groups, the Team (through Team contact of the group) and any coordinating groups must be informed of any new dependency.
The Team should, where necessary, in consultation with Working Group Chairs, create and modify Coordination Groups when a new need is seen. 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 activities 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. Any proposed Working Group may only proceed subject to the Director's decision that sufficient Team resources are available to support it, that the creation of the Working Group has sufficient mandate from the Advisory Committee without a further briefing package, and that other organizational and coordination work is not first required.
The membership of Coordination Groups should represent the groups involved in the scope coordinated, and is defined in the charter when the group is created, and may be modified as groups becomes 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 Group's charter may also specify other members, either as invited experts in a specific area, or as liaison with other activity internal or external to W3C. The role of such additional members should be clearly stated, and 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, in 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 membership 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 activities and progress of the groups it oversees.
Projects are activities that endeavor to develop systems that make use of Web technology. Projects develop proposals for Recommendations and implement them in pilot environments while maintaining close ties with technology innovators, implementors, and users with very different backgrounds.
Whereas Coordination Groups coordinate the activities of a set of groups, Projects involve communication between external organizations and W3C, the management of software implementations, etc. Due to this additional responsibility, the Chair of a Project must have the skills of a project manager.
The Director appoints the Chair of a Project. If the Project includes a Coordination Group (the usual scenario), it must be chaired by the Project Chair.
A Project has the same structure and observe the same processes as a Coordination Group unless otherwise indicated.
Projects may engage in partnerships with other organizations. Procedures for participation must be negotiated between the Project and the external organization and added to the Project charter.
Please consult the section on group communication for information about mailing lists and group Web sites.
The Project charter must specify the type of deliverable the group intends to produce and with what frequency (e.g., Recommendations, prototype software, reports, etc.).
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 workshop proposal and call for participation must be made no later than eight weeks prior to the workshop's proposed 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 workshop proposal and call for participation must be made no later than six weeks prior to the workshop's proposed date.
Either type of workshop may result in a proposal to the W3C to launch a new Activity or a new Group, but there is no guarantee of subsequent activity or even a proposal for an activity.
Either a Member organization or the Team may propose a workshop. However, it is the Team's responsibility to accept or not, and to schedule the workshop and coordinate the attendance and program.
To propose a workshop, a workshop proposal must be drawn up and circulated to the Advisory Committee according to the aforementioned calendar.
The proposal must include:
The proposal must address the following questions:
The call for participation must include:
Workshop minutes will be taken by the W3C Team and made available in the Member Area at the W3C Web site. The minutes of the workshop must be published at the Member Web site before any further W3C activity can be initiated in the area addressed by the workshop.
The nature of the deliverables is specified in the workshop proposal. A W3C Team member will be assigned to edit any conclusions reached as a result of the workshop (e.g., a proposal that W3C study this activity more in depth 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 for a workshop aiming at the exchange of ideas (ie first type). However, the call for participation to a symposium must include the following information:
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).
Like any other activity in W3C, the W3C process may require amendment from time to time.
When expected changes are major (important and numerous), a Working Group must be created to draft a proposal for changes. The section on proposing an activity for information about creating a Process Working Group applies to this situation.
When expected changes are medium (important but few), the Director may decide that the creation of a Process Working Group is not warranted. In this case, the Director may write a proposal for changes and send a ballot directly to AC representatives for a vote.
When changes are minor (clarification rather than content), the Director may decide to implement them and notify the Advisory Committee. Such changes are assumed to have been approved by the AC four weeks after the Director's announcement unless at least 5% of the AC representatives request to vote on the revised process during that period.
Participation in a Process Working Group is open to any AC representative. Participants are expected to attend all the W3C AC meetings that take place during the projected life-span of the Working Group.
Voting will proceed as for Advisory Committee votes related to Recommendations.
The process document describes the processes that govern the activity of W3C. The process document must be revised after a decision to modify the process.
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.
There are three requirements an individual must satisfy in order to belong to the W3C Team or participate in a W3C activity (e.g., act as a Chair, editor, etc.):
Generally, the best assessment of whether an individual satisfies these criteria is the consensus of colleagues. Consensus on the nature of individual roles can greatly facilitate the process of reaching consensus on technical issues.
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.
To formalize an individual's commitment to a role, the individual must specify in writing (by email or letter):
Individuals must submit this information to the Director for approval and reference.
W3C encourages its Members, the Team, and the general public to contribute ideas and specifications that will help W3C achieve its mission.
Submissions to W3C may be formal or informal and may originate from within W3C or without.
Informal submissions (e.g., an email suggesting that someone look into a certain document) have no formal status and W3C is not required to act on them or even to respond to them. Submitters have no rights by virtue of having made a submission. W3C may respond to the submission by creating a public Note.
Formal submissions can only be proposed by Members. Work developed jointly by input from Members and the Team becomes jointly owned and distributable by the Team as per the Membership Agreement, to allow unfettered publication of W3C results.
Formal submission allows the status of work that has not been jointly developed to be stated and possibly transfer rights to W3C hosts to enable publication and promote the deployment of the technology.
A formal submission may result in action by, or creation of, a W3C activity. The following sections described the formal submissions process.
To submit a specification to W3C for review, Members must prepare a submission package based on the submission package template [PUB13] published at the W3C Web site.
The submission package must include a complete electronic copy of the specification being submitted, and must address the following questions:
The completed submission package must be sent to submissions@w3.org. It will be forwarded internally to the appropriate Team members. Note that even if several organizations compose and sign a submission package, it should only be emailed from one address with a single cover note signed by each submitter.
A Member organization submits a specification to W3C through its Advisory Committee representative. The submission may be withdrawn by the AC representative at any time. W3C will not make statements about a submission withdrawn by the submitting AC representative before action has been taken by the Director.
W3C will inform submitters that the submission package has been received no sooner than five days and no later than ten days following reception.
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 until the Director has formally acknowledged the submission (as described in section 4.4).
Once the submission package has been received, the Director may either acknowledge or reject it. The decision must be made no sooner than one week after reception of the submission, and no later than two weeks after reception.
Until that time, the submission package may not be considered a submission. The Team may not comment on the submission (to the press, for example).
A submission may be rejected on the following grounds:
In case of a rejection, the submitter's Advisory Committee Member will be notified. The submitter has the right to appeal the decision to the entire AC.
No statements will be made by W3C about the reasons why a submission was rejected.
If the Director acknowledges the submission:
The acknowledgment of a submission does not imply that any action will be taken by W3C. It does not imply an endorsement by W3C, the W3C Team, or any of the Members of W3C. It merely records that the submission has been made by the submitting Member. The specification may not be referred to as "work in process" of the W3C.
Once a submission has been acknowledged, several avenues may be open to it:
At all times, the definitive list of W3C submissions [PUB10] may be found at the Web site.
Submitting organizations have the right to publish the documents comprising a submission before it is formally acknowledged. 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.
All published W3C documents [PUB11] produced by the W3C process are available at the Web site.
All Notes, public working drafts, Proposed Recommendations, and Recommendations must include:
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 Team reserves the right to reformat documents at any time, including changing the "Status of this Document" section and the document style, so as to conform to changes in W3C practice.
Electronic documents have primacy over paper versions except when legal issues are involved.
The primary language for official W3C documents is English. In addition to the official English version of a document, W3C welcomes translated versions.
The W3C Team will establish a process for creating and maintaining document names and will publish this process on 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 vote from the Advisory Committee. If the vote is affirmative, the document may be published in the public area of the W3C Web site (e.g., as a Note) at the discretion of the Director.
A W3C Note is a public record of an idea, comment, or document (e.g., a submission package) submitted by the Team, Members, or the general public. Encapsulating a document not under W3C's control in a Note allows authors to refer to a stable, known, and available version of the original document.
Note: Some external documents may not be available for re-publication by W3C due to copyright issues, etc. In these cases, it is not possible to stabilize the document in a Note, so references to the original document must explicitly identify the exact version. It is not sufficient to cite the "current draft".
Information submitted for publication as a Note must be sent to notes@w3.org. Notes are published on the Web site at the discretion of the Director. Notes may be published at any time. The publication of a Note implies no endorsement of any kind by W3C nor does it imply that W3C resources are allocated to issues addressed by the Note.
Every Note will be allocated a document name to clearly indicate that the document is a Note.
A section entitled "Status of this Document" must appear at the beginning of a Note after the principle heading. It must include one of the two following statements. If the document was authored within the Team, include the following text:
This document is a NOTE made available by W3C for discussion only. This indicates no endorsement of its content, nor that W3C has, is, or will be allocating any resources to the issues addressed by the NOTE.
If the document was not prepared or authored by the Team, include the following text:
This document is a NOTE made available by W3C for discussion only. This indicates no endorsement of its content, nor that W3C has had any editorial control in its preparation, nor that W3C has, is, or will be allocating any resources to the issues addressed by the NOTE.
The "Status of this Document" section may also include a statement about the purpose of the document where this will help guide the public. There is no set form for this statement. Examples of statements include:
This document represents an early attempt to discuss the issues of diversification of archival retrieval reinsurance protocols that W3C is not working on at present, but would like to bring to the community's attention.
or
This document describes an experimental architecture differing significantly from the W3C's architecture for embedding obsolete computer simulations in virtual view walls, and is made available for comparison purposes. Section 6 is particularly relevant to the choices made in W3C-REC-inkpens-970101.
or
This document was referred to in Advisory Committee meetings last June and is made available here for convenience.
Authors may, at the discretion of the Director, submit new versions of Notes to correct errors, without changing the version of the Note. However, substantial changes to the issues addressed may not be made in revisions.
A Recommendation indicates that consensus has been reached among Members about a specific topic and that a specification is appropriate for widespread use.
The process described below for creating a Recommendation is an alternative to, and not a replacement for, or modification of, the standards process in the W3C Member agreement. In the event that there is a need to revise a Recommendation, the same process will apply to the creation of the revised Recommendation.
The result of the W3C Recommendation process may be submitted to a formal standards body for ratification, however this is not required or guaranteed.
To initiate the Recommendation process, a Working Group must submit a document to the Director. The Working Group may either submit its own document or an external submission (in Note form, with possible modifications) that has been acknowledged by the Director.
If the Director approves the Working Group's document, it becomes a working draft. Working drafts may be released publicly or only to a limited group of reviewers at the Director's discretion. Publication of a Working Draft does not imply a commitment to a future proposal as a Recommendation. Every working draft will be allocated a document name to clearly indicate that the document is a working draft.
Once the Working Group has produced a stable working draft, they may resubmit it to the Director as a Proposed Recommendation.
To ensure the proper integration of a Recommendation in the international community, Proposed Recommendations (and Recommendations) must contain a statement about how the subject of the Recommendation relates to existing international standards and to relevant activities being pursued by other organizations.
If the Director approves the proposal, the document becomes a "Proposed Recommendation". A Proposed Recommendation is given a new document name to clearly indicate that the document is a Proposed Recommendation.
At this point, an announcement will be made to the Advisory Committee (and possibly elsewhere, such as in the newsletter) about the release of the Proposed Recommendation. The announcement must include the following information:
AC representatives are thus invited to voice their opinions about the proposed Recommendation by vote.
Members vote on a Proposed Recommendation by sending their ballot to one of the addresses given in the proposal announcement before the specified deadline.
Public comments may be made available to Members or the public at the discretion of the proposal's editor. Confidential comments will not be made public by the Team.
The proposal's editors must respond to substantive comments until the date specified in the proposal announcement. During this review period, any Advisory Committee representative may demand a specific response from the editors to any public comment made by the representative's Member organization.
AC representatives are to return their electronic ballot with one of the following votes:
The voting period lasts at least three weeks.
Once the voting period has ended and all votes and pertinent comments have been considered, the Director may elect to do one of the following:
Once a document becomes a W3C Recommendation, it receives a new document name to clearly indicate that it is a Recommendation.
Editorial changes may be made to W3C Recommendations after their release in order, for example, to clarify the document. The date code will be changed, and the previous version on the Web will be marked as obsolete. The Director will notify the Members of such changes.
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 manner, 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, Searching and Character Sets.
ISO TC 68;
ISO TC 154;
ISO TC 187;
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 AC meeting June 1996 was
against following the PAS ISO procedure.
ISO organizations run at a different speed. |
HTML and graphics. |
| CommerceNet Consortium | Payment Protocols, EDI Relationship with users (i.e., banks, retail companies) |
Strong Yes | Low, relationship is simple since area of overlap is specific. | Project management of JEPI, and specification development |
| OMG Object Management Group Consortium | CORBA, IIOP, Enterprise Users | Strong Yes | Low | Architecture Areas, HTTP |
| SGML Open Consortium | 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, X Consortium, SAG) | Active X, Validation Suites, Reference Implementations | Strong Yes | Low | Architecture and User Interface Areas, PICS |
| Government Regulators, European Commission, US Govt., G7,... | Regulatory Control | Depends | High, personal visits to each government and group are required. | Technology and Society Areas |