Copyright © 2001-2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, and document use rules apply.
This is the (superseded) charter for the W3C Technical Architecture Group (TAG). W3C created the TAG to document and build consensus around principles of Web architecture and to interpret and clarify these principles when necessary. The TAG will also resolve issues involving general Web architecture brought to the TAG, and help coordinate cross-technology architecture developments inside and outside W3C.
The W3C Process Document [PROCESS] also includes provisions relevant to the TAG. All references to the Process Document in this charter are to the version identified by [PROCESS].
14 May 2023 status update: This charter has been superseded per resolution of the TAG and a similar resolution by the W3C Advisory Board. The W3C Process Document henceforth describes the role, composition, and other aspects of the TAG.
Note: Although this charter has been superseded, the following paragraph and the rest of the document remain intact for archival purposes.
This is the 11 October 2004 version of a proposed TAG charter. It was reviewed by the W3C Membership and became the operative TAG charter on 14 December 2004. This version of the charter incorporates changes for the W3C Patent Policy and other updates since the original July 2001 version.
There are a number of architectural principles that underlie the development of the World Wide Web. Some of these are well-known; others are less well-known or accepted. It is important for the growth and interoperability of the Web that these principles be documented and generally agreed to.
Web architectural principles are debated, developed, and documented both inside and outside of W3C. For instance, W3C Working Groups use the Recommendation track to build consensus around principles that fall within the scope of the Working Group's charter and expertise. The W3C Team has published architecture documents as informal Web pages on the W3C site or as W3C Notes (e.g., "Design Issues," "What is a Good Standard?," and "Common User Agent Problems,").
As W3C has grown, there have been more frequent requests (from W3C Members and other parties) for documentation of architectural principles that cross multiple technologies. People ask, "How do W3C technologies fit together? What basics must people know before they start developing a new technology?"
Some discussions and debates within W3C have highlighted the need for documented architectural principles as well as a process for resolving disagreements about architecture:
To improve the effectiveness of Working Groups, to reduce misunderstandings and overlapping work, and to improve the consistency of Web technologies developed inside and outside W3C, the Consortium established the Technical Architecture Group (TAG) in 2001.
For the purposes of this charter, Web architecture refers to the underlying principles that should be adhered to by all Web components, whether developed inside or outside W3C. The architecture captures principles that affect such things as understandability, interoperability, scalability, accessibility, and internationalization.
For understandability, it is important that specifications be built on a common framework. This framework will provide a clearer picture of how specifications for Web technology work together.
For interoperability, there are some principles that cross Working Group boundaries to allow technical specifications to work together. For example, W3C has adopted an architectural principle that XML should be used for the syntax of Web formats unless there is a truly compelling reason not to (refer to "Assumed Syntax", by Tim Berners-Lee). This principle allows broad applicability of generic XML tools and is more likely to lead to general protocol elements that are useful for multiple purposes.
For scalability, it is important to base current work on wide applicability and future extensibility. For example, it is a common principle in designing specifications to avoid single points of control (e.g., a single registry that all specification writers or developers must use).
W3C's Web Accessibility Initiative and Internationalization Activity are already producing Architectural Recommendations in the areas of accessibility and internationalization, respectively.
The mission of the TAG is stewardship of the Web architecture. There are three aspects to this mission:
No set of documents will ever answer all the hard questions, so interpretation and subsequent refinement of the W3C architecture will certainly be necessary. As issues are resolved, the decisions will be documented so that principles can be observed consistently, to ensure stability and coherence in W3C Recommendations.
The TAG will not just document what is widely accepted; it will also anticipate growth and fundamental interoperability problems. Elaborating the intended direction of the Web architecture will help resolve issues when setting future directions, help establish criteria for starting new work at W3C, and help W3C coordinate its work with that of other organizations.
The TAG's scope is limited to technical issues about Web architecture. The TAG should not consider administrative, process, or organizational policy issues of W3C, which are generally addressed by the W3C Advisory Committee, Advisory Board, and Team.
The primary activity of the TAG is to develop Architectural Recommendations. An Architectural Recommendation is one whose primary purpose is to set forth fundamental principles that should be adhered to by all Web components. Other groups within W3C may include cross-technology building blocks as part of their deliverables, but the TAG's primary role is to document cross-technology principles. Like other groups within W3C, the TAG will follow the W3C Recommendation track process for its Recommendations (including public draft requirements and Proposed Recommendations to the Advisory Committee); refer to section 7 of the Process Document.
In addition to the production of Recommendations, the TAG will help resolve technical issues having architectural impact. The process for issue resolution is likely to evolve over time. The initial process is:
The TAG will hear appeals by Advisory Committee representatives of Member Submission requests rejected for reasons related to Web architecture. The Team will establish a process for such appeals that ensures the appropriate level of confidentiality.
As a persistent body within W3C, the TAG will be able to help coordinate cross-technology Web architecture discussions and reviews, both within W3C and between W3C and other organizations. In this capacity, some TAG roles will include:
The TAG is not expected to review every document on the W3C Recommendation track, only those that include Architectural Recommendations or that are brought to the attention of the TAG.
Except for hearing appeals of Member Submission requests rejected for reasons related to Web architecture, the TAG does not replace the Director in the W3C Process. However, it is likely that the Director will consult the TAG when issues of Web architecture arise. For instance, the Director may consult the TAG in cases where architectural issues are raised during the process of deciding whether to advance a document on the Recommendation track. The TAG is not expected to have a special role in advising the Director about whether Web technologies that are part of an Activity proposal are "horizontal" or "vertical".
The TAG is chartered as a permanent part of W3C. Unlike other W3C groups whose work ceases when completed or discontinued, the work of the TAG -- documenting fundamental principles of Web architecture -- is expected to require ongoing stewardship and continuity.
The TAG is expected to evolve with experience, and its charter may be revised as its role and W3C change. The Director must propose any non-editorial changes to the charter to the W3C Advisory Committee for a four-week review. After the end of the review, the Director must announce the disposition of the review to the Advisory Committee.
W3C may publish a revised version of the TAG charter to make minor clarifications, error corrections, or editorial repairs, without following the Advisory Committee review process. The Team must notify the Advisory Committee when an editorial revision of the TAG charter has been published.
Advisory Committee representatives may appeal any revised charter; refer to the appeal process described in section 8.2 of the Process Document.
The deliverables of the TAG are its Architectural Recommendations, review reports, and issue resolutions. The TAG may publish a variety of materials (e.g., short-term resolutions to issues that arise), but its Architectural Recommendations must be produced according to the formal Recommendation track process. As of the date of this charter, the TAG has produced one Recommendation track deliverable: Architecture of the World Wide Web, First Edition.
The schedule for these deliverables should be maintained on the TAG Web site.
The TAG should send a summary of each of its meetings to the Advisory Committee.
The TAG will present a report of its activities to the Membership at each Advisory Committee meeting. The TAG may report at other W3C-wide meetings (e.g., technical plenary meetings).
The TAG will coordinate its work with other groups within and outside of W3C whose technologies have an impact on Web architecture. Like other Working Groups within W3C:
As part of coordination with other groups producing Architectural Recommendations, TAG deliverables will acknowledge the timing and historical perspective of existing Web technologies.
All W3C Working Groups are expected to follow the Architectural Recommendations. If a Working Group intends to contradict an established Architectural Recommendation in a technical report, the group is expected to identify which principles are being contradicted and to provide technical rationale for the decision (e.g., the principle is wrong or conformance is impossible).
The following information will be public:
Other TAG information, including archives of the TAG's Member-only mailing list, will be confidential within W3C. In rare cases (e.g., when the TAG hears an appeal of a rejected Submission request), TAG deliberations may be confidential to the TAG and Team.
The TAG will use several mailing lists for its communications:
www-tag@w3.org, a public discussion (not
just input) list for issues of Web architecture. The TAG will conduct its
public business on this list.The TAG may create additional topic-specific, public mailing lists. In rare cases, (e.g., about a rejected Submission appeal), the TAG may require the use of TAG-only lists that will be visible to the TAG and Team. Additional information about communications mechanisms will be provided on the TAG Web site.
The TAG meeting plan is as follows:
The TAG consists of eight elected or appointed participants, and the Director, who is the Chair of the TAG.
Three TAG participants are appointed by the W3C Team under the leadership of the Director. Appointees need not be on the W3C Team.
The remaining five TAG participants are elected by the W3C Advisory Committee following the AB/TAG nomination and election process. TAG elections should be offset from Advisory Board elections by approximately six months. Nominees need not be employees of a Member organization. A nominee from a Member organization should have employer approval in order to participate. W3C Fellows (employees of W3C Members who are part of the Team) may be appointed or elected to the TAG.
Additional details about elections and appointments may be found in section 2.4 and section 2.5 of the Process Document.
W3C Members are encouraged to nominate individuals who:
Other key qualifications include experience with W3C process and Working Groups, experience in other related organizations, experience implementing Web technologies, and good writing skills.
The TAG will observe the standard W3C consensus practices described in section 3.3 of the Process Document in developing its Architectural Recommendations.
However, there may be times when a timely decision is required even if consensus cannot be obtained. To ensure that a resolution can be reached in such situations, after a good-faith attempt at consensus has failed, the TAG may vote. Resolutions approved by vote must have support from the majority of the TAG, defined as more than half of the non-vacant seats on the TAG (e.g., five votes if there are no vacant seats).
When the TAG must vote to resolve an issue, each TAG participant has one vote (whether appointed, elected, or the Chair). The name and vote of each TAG participant will be recorded in the minutes that are made available to the W3C Membership.
The TAG operates under the 5 February 2004 W3C Patent Policy. To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis. All individuals participating in the TAG have the licensing obligations described for invited experts in section 3.4 of the Patent Policy and the disclosure obligations described for invited experts in section 6.10. See the W3C Patent Policy FAQ for additional information about disclosure obligations.
It is likely that some of the appointed TAG participants will be from the W3C Team (though this is not a requirement). In addition, the Team as a whole will provide the working environment for the TAG, as well as administrative support for the Director, who is Chair of the TAG. This Team support includes:
In most ways, the TAG shares the same rights and responsibilities as other groups within W3C: it is important for the TAG to respond to architectural issues in a timely manner, to keep the community informed of its progress, to announce its resolutions, to provide substantive replies to reviewers' issues, etc. The TAG will therefore follow the applicable general provisions for W3C Groups described in section 3 of the Process Document except in the following cases:
The Advisory Board participants and Team that produces the July 2001 (first) version of the TAG charter were: Jean-François Abramatic (Chair, W3C), Ann Bassetti (The Boeing Company), Tim Berners-Lee (W3C), Carl Cargill (Sun Microsystems), Paul Cotton (Microsoft Corporation), Janet Daly (W3C), David Fallside (IBM), Renato Iannella (IPR Systems), Alan Kotok (W3C), Ken Laskey (SAIC), Ora Lassila (Nokia), Håkon Wium Lie (Opera Software), Larry Masinter (Adobe Systems), David Singer (IBM), Steve Zilles (Adobe Systems).