XML.com: XML From the Inside Out
oreilly.comSafari Bookshelf.Conferences.


W3C and the Web Community

April 10, 2000

Table of Contents

How Ideas Become Specifications
How Specifications Become Recommendations
Participation in a W3C Working Group
Participation outside of a W3C Working Group
Acceptance of a Specification
W3C Organization

The World Wide Web Consortium (W3C) was founded in 1994 so that organizations and individuals interested in developing the Web would have a place to promote and listen to ideas, hammer out consensus on interoperable solutions, and create high-quality technical specifications as a stable foundation for the Web. W3C's process has been designed so that developers, content providers and users, W3C Members and the public, and industry and government can all contribute to and benefit from the W3C forum. Only by serving the entire Web community can W3C claim to lead the Web to its full potential. "I devote my career to the XML development community," says Dan Connolly, the XML Activity Lead at W3C. "I occasionally get recruited to join this or that start-up as CTO, but it's more important to me today to work directly with the open standards XML community.

W3C's growth in just over five years (over 400 Members, 22 Recommendations, 60 full-time staff, over 20 Activities) shows that the international community considers W3C the place to go to develop fundamental Web technologies. Demand for the W3C forum is high today, but as soon as W3C stops meeting expectations, or the Web itself makes the need for this forum obsolete, we can all go home. Like everyone in the industry, W3C struggles to keep pace with rapid changes to Web markets, technology, and society. W3C must take these factors into account while building a sturdy and flexible foundation for the Web at the same time. Our success in this project depends largely on community trust and participation, including review of specifications, implementations, translations, and promotion. We invite you participate in W3C's mission and explain below how you can.

How Ideas Become Specifications

The W3C process (described in the Process Document) strives to ensure consensus among audiences that increase in size at each stage of the process. Proposals that trigger this process often come from these sources:

  • The W3C Team tracks developments in Web technologies and suggests directions to the Membership. The Team works full-time to coordinate W3C Activities, a service that distinguishes W3C from some other standards bodies such as the IETF and OASIS.
  • Workshops evaluate and foster interest in a particular topic and can lead to the creation of a new Working Group or Activity. For example, the 1998 The Query Languages Workshop led to work on XML queries.
  • Members can request publication of ideas at the W3C Web site. This is called the Member Submission process. One or more Member organizations send to the Team a "Submission Request" that includes a technical report or other material. The Team evaluates the submitted material and, if it is not out of scope for W3C or considered harmful to the Web, the material is published as a W3C Note along with a comment from the Team, and the request is added to the list of acknowledged Submission requests. Acknowledgment of a Submission request does not imply endorsement of the submitted material, or that W3C will do anything else with the submitted material. The material has not been reviewed by the Members, so acknowledgment does not imply consensus within W3C. A Working Group may use submitted material as part of its work, but this is not a requirement.

Once there is momentum behind an idea or area of technology, the Members are asked whether W3C should dedicate resources to it. A new Activity Proposal is sent to the Membership for review and the proposal is adopted when the review indicates consensus. Activity Proposals describe how work in the Activity will be carried out by and divided among Working Groups, Interest Groups, and Coordination Groups. For instance, work in the XML Activity is carried out by four Working Groups (Core, Schema, Linking, and Query), three Interest Groups (Plenary, Schema, Linking) and one Coordination Group. To help organize related Activities, W3C groups them into four Domains: Architecture, Technology and Society, User Interface, and the Web Accessibility Initiative (WAI). The XML Activity is part of the Architecture Domain, which also includes work on HTTP, Television and the Web, and Jigsaw (W3C's Web server).

Each Working Group expresses in its charter what piece of the Activity it agrees to develop. A charter must be reviewed by the Members (e.g., in an Activity Proposal) before a group can begin its work. A charter includes information about the nature, scope, goals, criteria for success, and deliverables of the Working Group. Deliverables might include, for example, a requirements document, one or more specifications (some of which are meant to become Recommendations), test suites, plans for implementation tracking, etc. Each Working Group is led by a Chair (or two co-Chairs on occasion) and includes at least one person from the Team (the Team contact) whose role is to (1) ensure that the Working Group functions within the W3C process, (2) monitor the group's progress and keep the Team aware of obstacles or successes, (3) help coordinate communication with other W3C groups, and (4) help with publications, press releases, meeting arrangements, etc.

How Specifications Become Recommendations

Just as in other standards organizations, W3C specifications undergo a lengthy formal process of review, revision, and refinement (called the "Recommendation track" at W3C) to build consensus. Documents on the Recommendation track advance from Working Draft to Candidate Recommendation (for implementation experience) to Proposed Recommendation (for Member review) and finally to Recommendation. Passage from one stage to the next requires consensus within a particular reviewing community. This includes industry, the developer community, the W3C Membership, and the other standards bodies and consortia with whom W3C coordinates its efforts.

To ensure that the public can track the development of a specification, Working Groups are required by the W3C process to make available a public draft at least every three months. More importantly, W3C asks for public comment at several critical points:

  • When the Working Group publishes the first public draft.
  • When the Working Group considers that it has met the requirements of its charter ("we're done"). At this point it solicits technical comments by issuing a "Last Call" to the Web community. The Working Group uses these comments to judge whether there is consensus about the specification. The Working Group must document any opposing viewpoints (from the public or anyone else) that it chooses to override in order to move forward. These objections are weighed alongside other criteria as part of the Recommendation track process. Working Groups are expected to respond publicly to all reasonable public comments made about a specification.
  • When the Working Group issues a Candidate Recommendation.

Please note that W3C specifications are created by Working Groups and proposed to the Members for adoption as a Recommendation. W3C does not create standards in the other direction; it does not put the Recommendation stamp on materials that come directly from its Members.

W3C has one other type of technical report, called a Note. A Note is not part of the Recommendation track and has no special meaning other than W3C has chosen to make some information available to the public. Each Note explains why it was published, what review process if any it has undergone, whether there is consensus among the authors, and other important status information. W3C uses Notes for a variety of reasons, including making available information that is part of an acknowledged Submission request.

Pages: 1, 2

Next Pagearrow