This work is licensed under a
Creative Commons License.Version 2.0a - Last Modified 12 January 2003. All comments and suggestions are welcome. Thanks for comments on 1.0 go to John Simpson, Janet Daly, Dan Brickley, Ann Navarro, Victor Lombardi, Tim Bray, Ken Sall, Kynn Bartlett, and David Brownell. Helpful commentators for the second edition include Jonathan Robie, Tim Bray, David Carlisle, Lauren Wood, Rich Salz, and Janet Daly. These comments do not, of course, constitute endorsement or approval.
The World Wide Web Consortium (W3C) is the home of an enormous amount of World Wide Web (WWW) technology development. Its Director, Tim Berners-Lee, is widely acclaimed as the inventor of the Web, and continues to exert considerable influence on the development of this key Internet technology through the W3C. While the W3C is an important player in the creation and management of Web standards, most Web developers hear of the W3C's output without participating in its creation.
The W3C provides limited opportunities for participation by non-members (though it does invite 'experts' to participate). While the results of its work are open to the public, including periodic drafts, the discussions that generate that material are often closed to non-members. This document provides an outsider's guide to the W3C, explaining its processes and its output from the perspective of a non-member, and identifying areas where non-members can participate.
The W3C is a consortium, a gathering place where organizations can meet and work together without the appearance of antitrust problems. The W3C is actually not a legal entity. It is supported by its host institutions and the participation of its members. The W3C has no responsibility except to its members, and even members have limited rights within the process.
The W3C primarily creates recommendations for the Web, which are effectively standards documents. Technically speaking, the W3C does not create 'standards' - this is the domain of ISO, the International Organization for Standardization. The W3C does not enforce its recommendations on its members, though it has stepped up its testing efforts. A separate organization, the Web Standards Project, has been formed by Web developers to encourage browser vendors to stick to the W3C recommendations, but has no affiliation with the W3C. The W3C is not charged with developing standards for the Internet in general; this is more the role of the Internet Engineering Task Force, a separate organization with which the W3C cooperates on certain projects.
The W3C formerly described the coordination and separation between itself and the IETF, as well as partnerships with other organizations, in an appendix to its process document, though that information is now kept in a separate liaison list including all of its formal relationships with other organizations. There is also a public IETF-W3C coordination mailing list.
The W3C also hosts conferences and symposia.
The main place to look for public information is the left-hand side of the main W3C page. Some projects are more deeply buried. The W3C also maintains a list of its activity statements, less technical introductions to the work its various projects are performing. If all else fails, the technical reports page has a complete list of documents available that can help you find your way.
There are several kinds of documents available from the W3C:
There are other documents available in the public areas of the W3C site. Many of the Working Groups have their own areas and activity statements, and post information about their work on a somewhat regular basis. The W3C also produces Open Source software as a testbed for its development work.
The W3C is a member-supported consortium including both software vendors and a variety of consumers. It is hosted by three institutions: Massachusetts Institute of Technology's Laboratory of Computer Science (MIT/LCS) in the United States, ERCIM in Europe (taking over in 2003 from the French Institut National de Recherche en Informatique et en Automatique (INRIA)), and Keio University in Japan. The W3C also maintains international offices.
The members are a fairly diverse group of companies and organizations. The usual suspects (Microsoft, AOL, Sun Microsystems, and IBM) participate, as do large customers (like Boeing, Electricité de France, and the United States Defense Information Systems Agency), educational institutions and organizations (University of Edinburgh HCRC Language Technology Group, OCLC, and The Hebrew University of Jerusalem), and a large number of small-to-medium companies. Membership allows organizations and their employees to participate on W3C projects and gives them access to internal W3C discussions.
The W3C is pretty much the flag-bearer for the Web. The W3C's member companies take the W3C seriously (though the extent varies among members), as does the press. The Web Standards Project, a completely separate organization, doesn't create its own standards - it just encourages companies, including W3C members, to implement key W3C standards completely.
Because the W3C has significant credibility, it's important to be aware of and participate in its work if you want to have an impact on Web standards.
W3C membership costs money. Do you have US$5750/year, and can you make a three-year commitment? Or, if your organization or its parent has gross annual revenues over US$50 million, do you have $57,500? (Dues can be paid in US dollars, Euros, or Yen.) If your organization's projects are centered on or highly dependent on W3C activity, joining the W3C probably makes sense. If you can't find that amount of funding, you're out of luck, unless you can get in as an invited expert. There are no lower-priced 'individual memberships', though individuals can get in at the affiliate (US$5750/year) price.
Joining will get you access to Member Areas and other benefits as well. Basically, you'll have a seat at the table, advance knowledge of what's coming out, and access to the discussions that formed the basis for standards. Knowing why a standard was written a particular way may help you plan for future versions more effectively than your competitors. This may be worth much more to your organization than US$5750 (or even US$57,500).
While the W3C welcomes implementations of their recommendations, they don't reduce the price of membership simply because you aren't getting paid for your software. This can make your projects more difficult - it's hard to predict how quickly (or sometimes, even if) the W3C will finish a project, and your implementation won't have the benefit of inside knowledge of upcoming development that W3C members may have.
If your project strikes those inside the W3C as being important or ground-breaking enough, you may be invited to participate as an invited expert. You'll have to sign some intellectual property agreements, but you won't have to pay a fee.
You can comment on public drafts, and participate in the public W3C mailing lists. Archives of the public mailing lists are open to the public, so you can (and should) read up on current discussions before jumping in. Many working drafts and proposed recommendations, though not all, provide an address to which you can send comments on that document. Implementing a W3C specification will likely give your comments some extra credibility.
If you feel strongly about an issue, you can start discussion outside of the W3C and generate your own drafts and documents. Some public mailing lists are open to such discussion, and it is possible to submit your documents to the W3C as a Note if you can find a sympathetic member to claim your proposal. Document Description Markup Language began as such a project and was eventually submitted to the W3C.
If you start such a project, be prepared: 'rogue' projects that conflict directly with W3C activities are likely to be shunned by those involved with the W3C. Be certain that your project isn't treading on another project, and don't try to claim any 'legitimacy' for your 'standard'. Of course, there aren't really any rules for such work, but these steps may help you get the W3C (or other bodies) to take your work seriously if and when you're ready.
If your project is outside the scope of the W3C - say you're creating an industry-specific XML vocabulary - be sure to coordinate it with others who might be interested and publicize it as widely as possible to avoid overlap with other projects. Organizations like OASIS and industry consortia often offer support and information about such projects. Robin Cover's XML Cover Pages is a key resource for finding and promoting XML specifications.
If your project is really about Internet infrastructure, look into the IETF for possible synergy. The IETF runs on an open consensus-based process - anyone may participate or make submissions. Also, for the XML-oriented, OASIS membership isn't free, but OASIS does offer a lower-cost individual membership option. (Individuals can participate but don't have voting rights at the organization.)
You may also choose to run your development on its own site, without affiliating it with a particular standards body. The Simple API for XML (SAX) effort is an example of such an independent process. Companies, individuals, and other organizations can all operate in this way. Processes vary from completely open to completely closed.
While decisions are generally still made by the Working Groups themselves, there are a number of W3C activities with a reputation for openness. The Web Accessibility Initiative has always made its own accessibility a priority. The Semantic Web activity has public lists, much public participation, and an RDF Interest Group that is open to members and non-members alike. There's even an RDF IG IRC channel.
The Web Services Activity also does much of its work in public, as does the W3C's Technical Architecture Group (TAG). Joint activities with the IETF have always been open, reflecting the IETF approach. The XML Signature Working Group led the way on that, and others have followed.
You should ask within your organization. Even members of the W3C don't necessarily want their employees spending all their time pondering standards rather than doing their job. Different organizations (and even areas within organizations) have different policies. A good place to start is by finding your organization's W3C Advisory Committee representative. The W3C keeps that list private, but you can ask if you know your organization is a member.
It is worth noting that working on W3C Activities often involves a large time commitment. 25-50% of working time is not unusual, and some travel may be required. Even if your employer is already a member, there are resource costs worth thinking about. On the other hand, participating in a Working Group gives you a heads-up on what's happening and connects you with people working in that field.
Even if you don't participate explicitly in Working Group activities (or in the broader Interest Groups maintained by some activities), you may find it worthwhile to read the W3C member archives to find out what went into particular decisions. Employees of member companies can get access to this information through their Advisory Committee representative. You will be bound by W3C confidentiality rules, of course, for any member-confidential information you read.
You don't need to be a W3C member to translate W3C Recommendations. However, the W3C does have some rules with which you'll need to comply. In all cases, the English version of a Recommendation at the W3C is the 'official' version.
The W3C doesn't discuss translating drafts or notes on their site.
The W3C has a full-blown Process Document that explains how it operates. The short version is:
Final decision-making power rests with the Director, who relies on the consensus of members to create documents. The Director, in consultation with the membership, has the power to set up Activities and working groups within them to address new areas, and these working groups do most of the standards development. (The current Director invented the World Wide Web, but expecting him to continue inventing it all by himself is asking a lot.)
Working groups (WGs) do most of the standards development, producing documents on a regular basis. Working groups are given charters (sometimes public, sometimes private) for the work they are to do, and usually publish activity statements as well. In some fields, there is one working group for a given activity, while in others there are many. While the W3C encourages small Working Groups, larger groups, even some enormous ones, persist. The XML Activity statement is especially complex, identifying multiple working groups and the coordination of their activities.
Working groups have publicly identified chairs, though their membership sometimes remains anonymous. (People can identify themselves as members, but only some Working Groups list names on the public site.) All members of working groups are representatives of W3C members, W3C staff, or invited experts. Working Groups produce Working Drafts, and eventually (possibly) Proposed Recommendations and (with the approval of the Director) Recommendations.
Working groups conduct most of their discussions by email, though there are face-to-face meetings, telephone conferences, and sometimes IRC conversations as well. All internal correspondence is archived in member-only areas, giving W3C members a glimpse of what went into a specification as well as the drafts and recommendation. Working Groups are encouraged to work through consensus, but in cases where votes are required the voting is on a per-member-organization basis. (The W3C also has an annual plenary meeting where working groups are encouraged to meet with each other to encourage coherence across projects.)
Some Working Groups now work largely in public. The RDF and XML Protocols Working Groups are well-known for this openness, but other groups continue to operate behind a wall of member-confidentiality. Even in cases where Working Groups operate openly, there is still the possibility that some material (perhaps involving business plans) will be member-confidential and not accessible to the general public.
When a Working Group feels that its work on a document is reaching completion, they can publish the document as a 'Last Call' Working Draft to announce their progress. The Last Call phase is both a sign that the Working Group believes their work is close to complete and a chance for developers both inside and outside the working group (and the W3C) to comment on the state of the draft.
After any 'Last Call' revisions, the document is submitted to the Director for approval to become a Candidate Recommendation (or possibly skip to Proposed Recommendation if they can make a case that enough implementation has already been done). After a period of collecting implementation feedback, the Working Group may submit it (possibly with revisions) to the Director for approval to become a Proposed Recommendation. If the Director approves this, it is published and W3C members may begin balloting. Editors may reply to ballot comments in this period, and sometimes changes can still be made before the final publication of the document as a W3C Recommendation, if it receives the Director's approval. (If the Director doesn't approve the document, it may go back to the working group as a working draft or be abandoned.)
Interest Groups work alongside the WGs. Unlike Working Groups, they aren't chartered to create particular documents. Instead, they evaluate and explore technology, possibly in conjunction with (or leading to the development of) Working Groups.
On a separate track, members can contribute proposals to the W3C through a submissions process, the results of which are published as Notes. (The W3C activities also occasionally publish Notes.) While a member organization is waiting for W3C acceptance of the submission, a quiet period is required. Only when the W3C has accepted a submission can the member organization announce the submission or describe the proposal as a Note. Acceptance of a Note by the W3C gives it no official standing - Notes are not standards, whatever a press release might imply. Member submissions may be used as foundations for further development, spurring additional W3C activity, but they have no 'official' standing as W3C output.
This process, like the Process Document underlying it, is subject to change. The W3C Advisory Board manages such change through the usual document publishing process. Changes have been fairly slow over the past few years, with the addition of the TAG and the creation of Candidate Recommendation status among the larger changes.
The W3C's Technical Architecture Group (TAG) is a group of people who both work on documents explaining the Web Architecture and make advisory recommendations on how various pieces of W3C work fit or don't fit into that architecture. The TAG's Charter is public.
The TAG consists of nine members. The W3C Director is one of them, and appoints three of the other members. The other five members are elected by the W3C Advisory Committee. TAG members do not need to be employees of W3C member organizations, and only one member of any given organization is permitted to serve on the TAG. TAG members serve for two years, though the initial group included some one-year members to permit the staggering of terms.
The TAG conducts most of its work publicly, on the www-tag mailing list. It also has teleconferences and face-to-face meetings, minutes of which are published to the mailing list. This list is probably the best place to see how the TAG chooses formal issues as discussions evolve and the manner in which they resolve (or don't resolve) them. The TAG can also hear appeals for submissions that were rejected on grounds related to Web Architecture.
The W3C's Advisory Board is a group of nine people elected by the membership plus the Chairman of the W3C. This board is perhaps best defined by what it is not: "The Advisory Board is not a board of directors and has no decision-making authority within W3C; its role is strictly advisory."
The Advisory Board has no public site, and draws far less public attention than the TAG. Like the TAG, it has some influence on the W3C decision-making process, but it focuses on "guidance to the Team on issues of strategy, management, legal matters, process, and conflict resolution" rather than on technical matters. The Advisory Board can hear appeals for submissions that were rejected on grounds unrelated to Web Architecture. It is also in charge of changes to the Process Document.
Members of the Advisory Board cannot simultaneously serve on the TAG and vice-versa.
Despite the best efforts of some members for the inclusion of fee-based patent work in W3C activities, the W3C Patent Policy Working Group appears to have concluded (as of a Last Call Working Draft, which "governs the handling of patents in the process of producing Web standards") that W3C Recommendations must use Royalty-Free approaches in handling patent issues. A "Reasonable and Non-Discriminatory (RAND)" exception process, which would have provided for some fee-based standards, was rejected.
This may not be the end of the story. The Free Software Foundation (FSF) still finds the draft unsatisfactory. On the other side, some W3C members appear to have started the Web Services Interoperability Organization with a very different approach to patents, as the Notice and Feedback sections on this document make extremely clear.
At present, you can largely count on being able to implement W3C Recommendations without fear of patent issues.
This work is licensed under a
Creative Commons License.
Copyright 1999-2003 by Simon St.Laurent.