Technical Architecture Group (TAG) Charter

19 July 2001

This version:: http://www.w3.org/2001/07/19-tag
Previous (Member-only) version:: http://www.w3.org/2000/06/15-tag
Authors:: The following individuals participating on the W3C Advisory Board: 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)
Editor:: Ian Jacobs, W3C

Abstract

This is the charter for the W3C Technical Architecture Group (TAG). W3C has 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] has been modified to include provisions relevant to the TAG.

Status of this Document

This charter has been superseded by the 27 October 2004 TAG charter per announcement to the Advisory Committee (Member only).

This is the 19 July 2001 version of the proposed TAG charter. This version of the TAG charter incorporates the Advisory Board's resolutions to issues raised by the W3C Advisory Committee and Team. This document was produced by the W3C Advisory Board.

Please send comments about this document to www-tag@w3.org. Comments sent to this archive are visible to the public.

Background

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," "XML in 10 points," "What is a Good Standard?," "Common User Agent Problems," etc.).

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:

In some cases, two Working Groups have diverged on their interpretation of a specification (e.g., the role of relative URIs within XML namespace names).
In other cases, a Working Group has stumbled over an issue that, while important to Web architecture, was not of primary focus to the Working Group. Documented principles should limit such stumbling.

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, this charter establishes the Technical Architecture Group (TAG) for the W3C.

What is Web architecture?

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.

Mission statement

The mission of the TAG is stewardship of the Web architecture. There are three aspects to this mission:

to document and build consensus around principles of Web architecture and to interpret and clarify these principles when necessary;
to resolve issues involving general Web architecture brought to the TAG;
to help coordinate cross-technology architecture developments inside and outside W3C.

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.

Scope of activity

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.

Architectural Recommendations

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, Proposed Recommendations to the Advisory Committee, etc.); refer to the Process Document [PROCESS], section 5.2.

Issue Resolution

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:

Issues may be brought to the TAG by a variety of parties: Working Groups, the public, the W3C Team, as part of an appeal to the W3C Director, the TAG itself, etc. Issues may arise in the interpretation of already published Architectural Recommendations, or with new issues not (yet) within the scope of such Recommendations.
By a majority vote, the TAG must agree to consider an issue as having sufficient breadth and technical impact to warrant its consideration. The TAG will work to prioritize the issues before it, and to address those of most immediate impact in a timely manner. There will be a Member-visible database of issues maintained at the TAG Web site.
The TAG will act to ensure that issues are resolved quickly, consistently, and with as much consensus and agreement of the community as possible. In some cases, a short-term resolution will be proposed while longer-term architectural directions are developed. Short-term resolutions must be public. Short-term issue resolutions are subject to appeal by Advisory Committee representatives; refer to the appeal process described in section 6 of the Process Document [PROCESS]. Note: TAG Architectural Recommendations are subject to Advisory Committee review by virtue of the fact that they involve the Recommendation track process.
Resolved issues may result in brief statements of architectural principle, which should later be incorporated in Architectural Recommendations.

Appeals of rejected Member Submission requests

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.

Coordination of cross-technology architecture work

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:

very early review (prior to Last Call) of the deliverables of Working Groups chartered to produce Architectural Recommendations;
coordination with Working Groups that realize only after chartering that they are producing Architectural Recommendations.
establishing liaisons with groups outside of W3C involved in the development of Web architecture. To this end, the TAG will follow the "Guidelines for Establishing Partnerships with W3C" [LIAISONS]

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.

Relationship between the Director and 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".

Duration

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.

Amendments

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 TAG charter for a four-week review by the Advisory Committee. After the end of the review, the Director must announce the new charter 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 6 of the Process Document [PROCESS].

Deliverables

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.

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).

Dependencies

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:

TAG deliverables on the Recommendation track will be subject to wide review;
the TAG may request the expertise of other groups within or outside of W3C to resolve issues;
the TAG will make best efforts to accommodate the needs of Working Groups that have begun work and need to complete it in a timely manner.

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, conformance is impossible, etc.).

Confidentiality

The following information will be public:

the TAG charter;
deliverables on the Recommendation track will be public according to the requirements of that process;
the archive of public discussion of Web architecture issues;
status reports at least once every three months, per the "three-month rule" of the Process Document [PROCESS], section 4.2.5;
TAG participant contact information.

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.

Communication

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.
a Member-visible list for discussions within the TAG and for requests to the TAG from Members that, for whatever reason, cannot be made on the public list. For instance, if the TAG is helping two Member-only Working Groups resolve an issue, it may be necessary to conduct business initially 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.

Meetings

The initial TAG meeting plan is as follows:

The TAG will hold a regularly scheduled distributed meeting (at least every other week).
The TAG will organize occasional face-to-face meetings.
The TAG may organize workshops to explore particular architectural issues.

Participation

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 the Process Document, section 1.4.1.

Participant Qualifications

W3C Members are encouraged to nominate individuals who:

Demonstrate depth of experience in broad areas of Web development; deep understanding of the architectural issues surrounding the Web and related technologies.
Are available to spend approximately 25% percent of their time writing and resolving issues.
Demonstrate the ability to resolve disputed technical issues and to build consensus.
Demonstrate the ability to put the common good above proprietary considerations. TAG participants must be willing, when circumstances require, to recuse themselves from decisions where proprietary interests might interfere with their judgment.

Other key qualifications include experience with W3C process and Working Groups, experience in other related organizations, experience implementing Web technologies, and good writing skills.

Special rules for the initial TAG

When the W3C Director appoints three individuals to the initial TAG, he will appoint two people until 31 December 2002, and one person until 31 December 2003.

In the initial TAG election, three of the seats will expire on 31 December 2002 and the other two on 31 December 2003.

In its status report at the Advisory Committee meeting in November 2002, the initial TAG will discuss issues raised during the charter review and the impact of the Advisory Board's resolutions to those issues.

Voting

The TAG will observe the standard consensus practices described in the Process Document (section 4.1.2) 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.

Intellectual property rights

The TAG will follow W3C's IPR policy; refer to the Process Document [PROCESS], section 2.2. All relevant IPR known to the participants in any TAG discussion will be disclosed by them.

Note: W3C is developing a new patent policy that is expected to obsolete the IPR policy described in the Process Document. The TAG will adhere to the new patent policy adopted by W3C.

Team involvement

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:

Maintenance of the TAG home page, mailing list, and archives.
Organization of meetings (both distributed and face-to-face) and publication of meeting minutes.

Summary of special TAG characteristics

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 provisions of W3C Working Groups (refer to the Process Document [PROCESS], section 4.2) except in the following cases:

Deliverables. The TAG will deliver a report at every Advisory Committee meeting.
Duration. The duration of the TAG is permanent (unless rechartered).
Participation. See previous section on participation.
Voting. See previous section on voting.
Last Call. Because the primary consumers of Architectural Recommendations will be other technical groups (both inside and outside of W3C), the last call review period for an Architectural Working Draft is expected to be longer than for other types of technical reports, to allow for sufficient review.

References

[PROCESS]: World Wide Web Consortium Process Document, 19 July 2001.
[LIAISONS]: Guidelines for establishing partnerships with W3C