Administration and participation

Meetings

The next full F2F meeting of the TAG will be held 4-6 January 2012 at the offices of the W3C in Cambridge, MA, and several TAG members will participate in the W3C Technical Plenary that's planned for Santa Clara, 31 October through 4 November 2011.

The TAG holds weekly teleconferences, typically on Thursdays.

Membership changes

There were no changes to the TAG's membership during this period. An election will be held starting in November 2011 to fill the seats of two TAG members whose terms are expiring (Dan Appelquist of Vodafone and Henry Thompson of University of Edinburgh); the incumbents may choose to stand for re-election. The terms of appointed members Jonathan Rees and Noah Mendelsohn (chair) also expire at the end of January, and the Director will later announce his decision regarding appointments to those positions.

New TAG Work Plan Page

The TAG has introduced an additional means of tracking and making available for public review information about the TAG's most important work items.
The new TAG Work Plan (http://www.w3.org/2001/tag/products/index.html) page contains tables listing the TAG's most significant projects, and some others as well. For each project, the table indicates which TAG member(s) are leading the effort and summarizes the dates for upcoming checkpoints.

For most projects, a link is also provided to a product page that describes in much more detail the project's goals and specific success criteria, gives additional information about deliverables and dates, provides links to pertinent drafts, etc.
Sections are also provided that give brief listings of major projects that have been completed or abandoned.
As the TAG's overall priorities and detailed plans change,
the pertinent description pages are revised (links are generally provided to earlier dated versions of each page, from which it
is possible to determine how plans have changed, and whether earlier
commitments have been met.)

The TAG solicts suggestions as to how it can most effectively
contribute to the success of the Web and the W3C, and also on details
of the TAG's project work.
Anyone interested in the TAG's
work is encouraged to consult the
TAG Work Plan page and the detailed project descriptions linked from it.
The TAG also continues to use the W3C Tracker system to track Actions assigned to particular TAG members and technical Issues of concern to the TAG. The TAG makes occasional use of Tracker's Product capability, but that has been found insufficiently flexible for our needs, and has mostly been
replaced, for the TAG's purposes, by the Work Plan described above.
Short-term work is typically managed using Tracker Actions only.

The following sections discuss each of the TAG's highest
priority projects:

"As the Web has evolved from a Web of documents to a Web of applications, techniques for designing applications so that application state and document views of application state can be identified and bookmarked have evolved correspondingly. Originally introduced as a static "fragment identifier" to identify locations in a document, the hash sign, #, is now being used to identify application states as well as in other interesting ways, for example, by SVG and PDF to select from and render documents and as arguments to Web applications that are interpreted by JavaScript. Fragment identifiers are used to provide several different kinds of parameters to the client-side application, such as the actual URI of a video to be played to a video player, or the position and zoom to a map. In many widely deployed browsers, changing the scheme, path or query string in a URI causes an unconditional page reload, but changes to the fragment identifier do not: the characters in the URI bar after the # can be changed without incurring the overhead of reloading the page. Applications and toolkits using fragment identifiers in this way often go to some effort to maintain a history and make sure the back button works as expected. Accessibility and search can, however, be compromised, because without running JavaScript, the URI has no meaning. Such uses of the "fragment identifier" have interesting and different properties, and the usage differs from the way it is described in existing specifications. Recently added functionality in [HTML5] (history.pushState() and history.replaceState()) allows browser history to be changed without causing a page reload thereby providing an alternative to the use of fragment identifiers to identify application state.

Many Web applications are used to present or edit documents. Such applications should be designed so that the documents are readily identified with URIs that can be used for linking from other Web pages or transmitted in e-mails or used in copy/paste situations.

This document explores the issues that arise from these new uses of fragment identifiers and attempts to define best practices. We argue that, in many cases, the use of query parameters along with the new HTML5 functionality mentioned above is preferable to fragment identifiers to identify application state."

The specification governing Uniform Resource Identifiers
(URIs) [rfc3986] allows URIs to mean anything at all,
and this unbounded flexibility is exploited in
a variety contexts, notably the Semantic Web and Linked Data.
To use a URI to mean something, an agent (a) selects a URI,
(b) provides a definition of the URI in a manner that
permits discovery by agents who encounter
the URI, and (c) uses the URI.
Subsequently other agents may not only understand the URI (by
discovering and consulting the definition) but may also use
the URI themselves.

A few widely known methods are in use to help agents provide
and discover URI definitions,
including RDF fragment identifier resolution and the HTTP 303
redirect.
Difficulties in using these methods
have led to a search for new methods that
are easier to deploy, and perform better,
than the established ones.
However, some of the proposed methods introduce new problems, such
as incompatible changes to the way metadata is written.
This report
brings together in one place information on current and
proposed practices, with analysis of benefits and shortcomings
of each.

Publishing and Linking on the Web

The TAG has noted with concern a number of legal issues that have arisen
relating to Web publishing and linking.
For example, there is a question of whether including in one Web page a link to a second Web page can or should, for legal purposes, constitute a (re)publication of that second page.
Such publication might have implications relating to copyright infringement, libel, etc.

The TAG has neither the legal expertise nor the responsibility by charter to form legal opinions or proposals, but we may be able to play a role in helping those who make laws or set policy to better understand the way the Web works, to use technical terminology that is appropriate and sufficiently unambiguous, and to be informed about the potential practical consequences of decisions they are weighing. As an example, a hypothetical law restricting the copying of copyrighted information might unintentionally prohibit the deployment of Web caches, and thus seriously impact the performance of the Web. Also, non experts are easily confused by the differences between links included in anchor tags (I.e. <a href="..">), which typically have to be explicitly dereferenced, versus references in other tags (e.g. <img src="...">) which are automatically transcluded into the referencing document.

The following extract from the product page explains the scope and planned deliverables for this work:

Goals

The goal of this work is to promote understanding between those who draft, approve, and enforce laws relating to copyright and publishing with the technical community responsible for Web technologies and their use. Specifically, we will:

Clarifying the ways in which the Web's technical facilities operate to store, publish, and retrieve information

Clarify pertinent terminology that's used by the Web technical community, and where pertinent, clarify points
of confusion with respect to similar terminology used elsewhere (esp. in the law)

Clarify the technical and operational impact that results or would result from current or potential
legislation that might be drafted to restrict publishing, linking, or transformation on the Web.

Mime and the Web

We previously reported on work that the TAG is doing to
deal with inconsistencies in the use of MIME for the Web vs. for its original
application to e-mail, etc. In late 2010, Larry Masinter prepared what has since evolved into Internet Draft: MIME and the Web (draft-masinter-mime-web-info-02) (http://tools.ietf.org/id/draft-masinter-mime-web-info-02.html),
which explores some of the issues, and which suggests development of a new Best
Common Practice for registration of Internet Media Types and Charsets,
and Larry has been working with the IETF on these
issues.

One of the goals for this effort by the TAG was to ensure that the IETF
is aware of concerns relating to BCPs and RFPs in their jurisdiction, and indeed several efforts are now underway at IETF to deal with such concerns (see the product page for a partial list).
The TAG considered these activities at its recent F2F Meeting in Edinburgh.

Larry Masinter has begun the task of drafting a report or finding
that will summarize the TAG's positions in these areas, focusing particularly on the use of registries for, e.g. media types. Publication of the
finding is scheduled for December, 2011.
We note that the TAG's earlier work on sniffing also relates crucially
to the role of media types in Web architecture, but work on sniffing
has moved to IETF for the forseeable future.

Fragment identifiers and Mime Types

The TAG has been working during the past few months to resolve concerns
relating to the use of fragment identifiers in RDFa and for
other Semantic Web applications.
RFC 3986 states: "The fragment's format and resolution is therefore dependent on the media type [RFC2046] of a potentially retrieved representation".
In the case of RDFa in text/html, the pertinent media type is RFC 2854 which specifies "For documents labeled as text/html, the fragment identifier designates the correspondingly named element"; for XML documents, and thus for application/xhtml+xml RFC 3023 suggests XPointer as a likely fragment syntax.
The usage in RDFa appears to be inconsistent with both of these specifications.

The TAG's work in this area is divided into several significant threads:

The TAG is considering the specific case of RDFa, and is discussing whether
changes might be needed to the RDFa specifications, or to others, to support the
fragment syntax and semantics proposed for RDFa. Discussion of this is ongoing.

HTML5 Last Call Review

As discussed in several previous status reports, the TAG has over the past several years devoted significant effort
to review of draft HTML5 specifications, and has worked with the HTML working group to resolve a number of concerns.
Over the summer we completed our review of the HTML5 last call documents, and so for the moment HTML5 review has been
reprioritized as a lower priority activity for the TAG.
We continue to actively pursue some particular HTML-related issues, such as the functional overlap between Microdata and RDFa; the TAG will continue to track HTML5-related developments, and will re-engage with higher priority as circumstances warrant.

Other TAG Work

The sections above discuss the projects that are or were designated his top priority for the TAG during this period. Information on other tag activities is available in the Other Active Projects section of the TAG Work Plan. Here we provide additional information on a few these activities:

HTML / XML Unification

In a previous report, we announced that the TAG opened an issue: (ISSUE-67: HTML and XML Divergence), and that we were
creating an informal group to explore improved architectural synergy between
XML and HTML5.
Several experts from the HTML and XML communities are participating,
and we are particularly grateful for the contributions of former TAG member Norm Walsh, who is volunteering the considerable time and effort required to
chair the group.

The group is currently in the process of finalizing a draft of a report, and the TAG expects to review that in detail when it is
ready.

Data Minimization in Web API Design

The TAG is working on a draft
Data Minimization in Web APIs (http://www.w3.org/2001/tag/doc/APIMinimization.html)
articulating the
principle of data minimization when it comes to the design of Web APIs. This
approach to the design of APIs minimizes the amount of extraneous data with
a goal of improving user privacy. The TAG is interested in feedback in this
approach, especially any data or studies which might demonstrate the
effectiveness of this technique in enhancing user privacy and security.

Future versions of HTML

At the recent F2F meeting in Edinburgh, proposals were made
to initiate TAG work to consider architectural issues and
desiderata relating to future versions of HTML.
The TAG has not yet decided whether to invest significant effort in
this activity, but we welcome suggestions from the community regarding
HTML.next technology, and also regarding the role of the TAG.

Web Application Storage

In addition to the relatively short-lived "state" discussed above, Web applications also make use of facilities such as SQL stores or HTML5 Web Storage to preserve data between browser sessions.
The TAG is beginning an effort to explore best practices for use of such storage, and for using (when appropriate) URIs to identify the information stored, and is considering
the pros and cons of maintaining local/remote transparency (consider an e-mail application: should the e-mail be accessed using the same URI, regardless of whether the access is to a server, or to a copy of the e-mail in local Web storage?)
As was the case with our last report, relatively little progress on this was made during this period, but we expect to refocus on this once the client-side state finding
is closer to final publication.

Persistence of identifiers

The TAG continues to explore steps that the W3C might take to facilitate the use of URIs, and in particular http-scheme URIs, as
stable identifiers that can be relied upon to remain associated with the intended resource over a very long period of time.
Such stable identifiers are required, for example, for references to scholarly publications, for use in libraries, etc.
For a variety of reasons, URIs are perceived not to have the required characteristics today. Well known issues relate to the
way in which the DNS names are assigned and reassigned, the lack of a means of assigning such a DNS name for more than a few years at a time,
etc.
At it's recent F2F in Edinburgh, the TAG resolved "to endorse a workshop proposal on domain persistence for IDCC11 on 4 or 8 December. This probably means no more than that the workshop publicity would include some form of attribution to the TAG. This is contingent on suitable approval from and coordination with W3C staff."

W3C Web Architecture Pages

The W3C is building a set of pages that are intended to provide
a high level introduction to Web Architecture concepts; these pages are linked from http://www.w3.org/standards/webarch/.
At the recent F2F meeting in Edinburgh, several TAG members took actions
to draft content that might be suitable for inclusion in these pages.

The TAG believes that having two such overlapping specifications is
detrimental, and so it has opened bugs against both of them (Bug 13100 and 13101), requesting
that the responsible working groups attempt to provide a more unified approach to meeting the needs of all users.

The TAG also sent an e-mail suggesting that the W3C create a task force to investigate the possible unification of the proposed technologies.
The W3C responded that it intends, as an initial step, to initiate an HTML Data Task Force (proposed charter) under the auspices of the Semantic Web Interest Group (SWIG); the task force will be chaired by TAG-member Jeni Tennison.

HTTP Semantics

The TAG has for several years informally managed a subgroup known as AWWSW (Architecture of the World-Wide Semantic Web) that met by phone and using e-mail. Significant progress was made by that subgroup in formulating a formal semantics for HTTP in particular, and on related issues. At its June 2011 F2F, the TAG decided to discontinue formal tracking of AWWSW.

The Technical Architecture Group (TAG) was created in February 2001. Three TAG participants are appointed by the
Director and five TAG participants are elected by the Advisory Committee. The
mission of the TAG is stewardship of the Web architecture.
Included in this mission is building consensus around principles of Web architecture, resolving issues involving Web
architecture, and helping to coordinate cross-technology architecture developments inside and outside W3C.

Details on TAG activities can be found from the
TAG home page and from the TAG's Work Plan. The TAG
meets weekly via teleconference and several times each year in person.
Summaries (such as this one) of the TAG's activity are provided periodically to the W3C Advisory Committee, W3C working group chairs,
and to the public TAG mailing list (www-tag archive). The TAG welcomes public discussion of open
issues, as well as proposals for new issues, on that same list.
The TAG's previous status report
was published in April, 2011, covering the period from January through April 2011.