27-tag-charter.html 25 KB

Raw Blame History Permalink

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
       "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
  <title>Technical Architecture Group (TAG) Charter</title>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  <link rel="stylesheet" type="text/css"
  href="http://www.w3.org/StyleSheets/TR/base.css" />
</head>

<body>

<div class="head">
<a href="http://www.w3.org/"><img height="48" width="72" alt="W3C"
src="http://www.w3.org/Icons/w3c_home" /></a>

<h1>Technical Architecture Group (TAG) Charter</h1>

<h2>27 October 2004</h2>
<dl>
  <dt>This version:</dt>
    <dd><a
      href="http://www.w3.org/2004/10/27-tag-charter.html">http://www.w3.org/2004/10/27-tag-charter</a></dd>
  <dt>Previous version:</dt>
    <dd><a
      href="http://www.w3.org/2004/10/11-tag-charter">http://www.w3.org/2004/10/11-tag-charter</a></dd>
  <dt>Authors:</dt>
    <dd>See <a href="#acks">acknowledgments</a></dd>
  <dt>Editor:</dt>
    <dd>Ian Jacobs, W3C</dd>
</dl>

<p class="copyright"><a
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Copyright">Copyright</a>
© 2001-2004 <a href="http://www.w3.org/"><abbr
title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup> (<a
href="http://www.csail.mit.edu/index.php"><abbr
title="Massachusetts Institute of Technology">MIT</abbr></a>, <a
href="http://www.ercim.org/"><span
title="European Research Consortium for Informatics and Mathematics">ERCIM</span></a>,
<a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Legal_Disclaimer">liability</a>,
<a
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#W3C_Trademarks">trademark</a>,
and <a
href="http://www.w3.org/Consortium/Legal/copyright-documents-19990405">document
use</a> rules apply.</p>
<hr />
</div>

<h2 class="notoc"><a id="abstract" name="abstract">Abstract</a></h2>

<p>This is the charter for the W3C Technical
Architecture Group (<acronym>TAG</acronym>). 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.</p>

<p>The W3C Process Document <a href="#ref-process">[PROCESS]</a> also
includes provisions relevant to the TAG. All references to the Process
Document in this charter are to the version identified by <a
href="#ref-process">[PROCESS]</a>.</p>

<h2 class="notoc"><a id="status" name="status">Status of this
Document</a></h2>

<p>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 <a
href="http://www.w3.org/Consortium/Patent-Policy-20040205/">W3C Patent
Policy</a> and other updates since the original July 2001 version.</p>

<h2><a id="background" name="background">Background</a></h2>

<p>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.</p>

<p>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., "<a href="http://www.w3.org/DesignIssues/">Design
Issues</a>," "<a
href="http://www.w3.org/People/Bos/DesignGuide/introduction">What is a Good
Standard?</a>," and "<a href="http://www.w3.org/TR/cuap">Common User Agent
Problems</a>,").</p>

<p>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?"</p>

<p>Some discussions and debates within W3C have highlighted the need for
documented architectural principles as well as a process for resolving
disagreements about architecture:</p>
<ul>
  <li>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).</li>
  <li>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.</li>
</ul>

<p>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 (<acronym>TAG</acronym>) in 2001.</p>

<h3>What is Web architecture?</h3>

<p>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.</p>

<p>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.</p>

<p>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 "<a href="http://www.w3.org/DesignIssues/Syntax">Assumed Syntax</a>", 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.</p>

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

<p>W3C's Web Accessibility Initiative and Internationalization Activity are
already producing Architectural Recommendations in the areas of accessibility
and internationalization, respectively.</p>

<h2><a name="Mission" id="Mission">Mission statement</a></h2>

<p>The mission of the TAG is stewardship of the Web architecture. There are
three aspects to this mission:</p>
<ol>
  <li>to document and build consensus around principles of Web architecture
    and to interpret and clarify these principles when necessary;</li>
  <li>to resolve issues involving general Web architecture brought to the
  TAG;</li>
  <li>to help coordinate cross-technology architecture developments inside
    and outside W3C.</li>
</ol>

<p>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.</p>

<p>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.</p>

<h2><a name="Scope" id="Scope">Scope of activity</a></h2>

<p>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.</p>

<h3>Architectural Recommendations</h3>

<p>The primary activity of the TAG is to develop Architectural
Recommendations. An Architectural Recommendation is one whose
<em>primary</em> 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
<em>primary</em> role is to document cross-technology principles. Like other
groups within W3C, the TAG will follow the <a
href="http://www.w3.org/2004/02/Process-20040205/tr.html#Reports">W3C
Recommendation track</a> process for its Recommendations (including public
draft requirements and Proposed Recommendations to the Advisory Committee);
refer to section 7 of the Process Document.</p>

<h3>Issue Resolution</h3>

<p>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:</p>
<ol>
  <li>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.</li>
  <li>If the TAG agrees by <a href="#majority-vote">majority vote</a>, it
    will 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 <a href="http://www.w3.org/2001/tag/">TAG Web site</a>.</li>
  <li>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 <strong>public</strong>. Short-term issue resolutions
    are subject to appeal by Advisory Committee representatives; refer to the
    appeal process described in <a
    href="http://www.w3.org/2004/02/Process-20040205/acreview.html#ACAppeal">section
    8.2</a> of the Process Document. <strong>Note</strong>: TAG Architectural
    Recommendations are subject to Advisory Committee review by virtue of the
    fact that they involve the Recommendation track process.</li>
  <li>Resolved issues may result in brief statements of architectural
    principle, which should later be incorporated in Architectural
    Recommendations.</li>
</ol>

<h4>Appeals of rejected Member Submission requests</h4>

<p>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.</p>

<h3>Coordination of cross-technology architecture work</h3>

<p>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:</p>
<ol>
  <li>very early review (prior to Last Call) of the deliverables of Working
    Groups chartered to produce Architectural Recommendations;</li>
  <li>coordination with Working Groups that realize only after chartering
    that they are producing Architectural Recommendations.</li>
  <li>establishing liaisons (formal or informal) with groups outside of W3C
    involved in the development of Web architecture; see <a
    href="http://www.w3.org/2004/02/Process-20040205/liaisons.html#Liaisons">section
    10</a> of the Process Document for more information.</li>
</ol>

<p>The TAG is <strong>not</strong> 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.</p>

<h3>Relationship between the Director and the TAG</h3>

<p>Except for hearing appeals of Member Submission requests rejected for
reasons related to Web architecture, the TAG <strong>does not</strong>
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".</p>

<h2><a name="Duration" id="Duration">Duration</a></h2>

<p>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.</p>

<h2><a name="Amendments" id="Amendments">Amendments</a></h2>

<p>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.</p>

<p>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.</p>

<p>Advisory Committee representatives may appeal any revised charter; refer
to the appeal process described in <a
href="http://www.w3.org/2004/02/Process-20040205/acreview.html#ACAppeal">section
8.2</a> of the Process Document.</p>

<h2><a name="Deliverables1" id="Deliverables1">Deliverables</a></h2>

<p>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: <a
href="http://www.w3.org/TR/webarch/"><cite>Architecture of the World Wide
Web, First Edition</cite></a>.</p>

<p>The schedule for these deliverables should be maintained on the <a
href="http://www.w3.org/2001/tag/">TAG Web site</a>.</p>

<p>The TAG should send a summary of each of its meetings to the Advisory
Committee.</p>

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

<h2><a name="Dependencies11" id="Dependencies11">Dependencies</a></h2>

<p>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:</p>
<ul>
  <li>TAG deliverables on the Recommendation track will be subject to wide
    review;</li>
  <li>the TAG may request the expertise of other groups within or outside of
    W3C to resolve issues;</li>
  <li>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.</li>
</ul>

<p>As part of coordination with other groups producing Architectural
Recommendations, TAG deliverables will acknowledge the timing and historical
perspective of existing Web technologies.</p>

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

<h2>Confidentiality</h2>

<p>The following information will be public:</p>
<ul>
  <li>the TAG charter;</li>
  <li>deliverables on the Recommendation Track will be public according to
    the requirements of <a
    href="http://www.w3.org/2004/02/Process-20040205/tr.html#transition-reqs">section
    7.2</a> of the Process Document.</li>
  <li>the archive of public discussion of Web architecture issues;</li>
  <li>status reports at least once every three months, per the <a
    href="http://www.w3.org/2004/02/Process-20040205/groups.html#three-month-rule">Working
    Group Heartbeat Requirement</a> described in <a
    href="http://www.w3.org/2004/02/Process-20040205/groups.html#three-month-rule">section
    6.2.7</a> of the Process Document.</li>
  <li>TAG participant contact information.</li>
</ul>

<p>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.</p>

<h2>Communication</h2>

<p>The TAG will use several mailing lists for its communications:</p>
<ul>
  <li><code>www-tag@w3.org</code>, a public <strong>discussion</strong> (not
    just input) list for issues of Web architecture. The TAG will conduct its
    public business on this list.</li>
  <li>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.</li>
</ul>

<p>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 <a href="http://www.w3.org/2001/tag/">TAG Web site</a>.</p>

<h2><a name="Meetings1" id="Meetings1">Meetings</a></h2>

<p>The TAG meeting plan is as follows:</p>
<ul>
  <li>The TAG will hold a regularly scheduled distributed meeting (at least
    every other week).</li>
  <li>The TAG will organize occasional face-to-face meetings.</li>
  <li>The TAG may organize workshops to explore particular architectural
    issues.</li>
</ul>

<h2><a name="Participation" id="Participation">Participation</a></h2>

<p>The TAG consists of eight elected or appointed participants, and the
Director, who is the Chair of the TAG.</p>

<p>Three TAG participants are appointed by the W3C Team under the leadership
of the Director. Appointees need not be on the W3C Team.</p>

<p>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.</p>

<p>Additional details about elections and appointments may be found in <a
href="http://www.w3.org/2004/02/Process-20040205/organization.html#TAG">section
2.4</a> and <a
href="http://www.w3.org/2004/02/Process-20040205/organization.html#AB-TAG-participation">section
2.5</a> of the Process Document.</p>

<h3>Participant Qualifications</h3>

<p>W3C Members are encouraged to nominate individuals who:</p>
<ul>
  <li>Demonstrate depth of experience in broad areas of Web development; deep
    understanding of the architectural issues surrounding the Web and related
    technologies.</li>
  <li>Are available to spend approximately 25% percent of their time writing
    and resolving issues.</li>
  <li>Demonstrate the ability to resolve disputed technical issues and to
    build consensus.</li>
  <li>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.</li>
</ul>

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

<h2><a name="Voting" id="Voting">Voting</a></h2>

<p>The TAG will observe the standard W3C consensus practices described in <a
href="http://www.w3.org/2004/02/Process-20040205/policies.html#Consensus">section
3.3</a> of the Process Document in developing its Architectural
Recommendations.</p>

<p>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 <a
id="majority-vote" name="majority-vote">majority of the TAG</a>, defined as
more than half of the non-vacant seats on the TAG (e.g., five votes if there
are no vacant seats).</p>

<p>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.</p>

<h2><a name="IPR1" id="IPR1">Patent Policy</a></h2>

<p>The TAG operates under the <a
href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004
W3C Patent Policy</a>. 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 <a
href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-invited">section
3.4 of the Patent Policy</a> and the disclosure obligations described for
invited experts in <a
href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-disclosure-invite">section
6.10</a>. See the <a
href="http://www.w3.org/2003/12/22-pp-faq.html">W3C Patent Policy
FAQ</a> for additional information about disclosure obligations.</p>

<h2>Team involvement</h2>

<p>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:</p>
<ul>
  <li>Maintenance of the TAG home page, mailing list, and archives.</li>
  <li>Organization of meetings (both distributed and face-to-face) and
    publication of meeting minutes.</li>
</ul>

<h2>Summary of special TAG characteristics</h2>

<p>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 <a
href="http://www.w3.org/2004/02/Process-20040205/policies.html#Policies">section
3</a> of the Process Document except in the following cases:</p>
<ul>
  <li>Voting. See previous section on <a href="#Voting">voting</a>.</li>
  <li>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 the Last Call review period of a typical
    W3C Working Draft, to allow for sufficient review.</li>
</ul>

<h2>References</h2>
<dl>
  <dt><b><a id="ref-process" name="ref-process">[PROCESS]</a></b></dt>
    <dd><a href="http://www.w3.org/2004/02/Process-20040205/">World Wide Web
      Consortium Process Document</a>, 5 February 2004.</dd>
</dl>

<h2><a name="acks" id="acks">Acknowledgments</a></h2>

<p>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).</p>
</body>
</html>