This is a report from the W3C Technical Architecture Group to the W3C membership on TAG activities from May through October, 2011.
During the period covered by this report, the TAG held two face to face meetings: 6th - 8th June 2011, MIT, Cambridge, MA and 13th - 15th September 2011, University of Edinburgh, UK .
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.
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.
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:
The TAG has distributed Identifying Application State Proposed TAG Finding 30 September 2011 (http://www.w3.org/2001/tag/doc/IdentifyingApplicationState-20110930.html) for review. Comments are formally due by 28 October 2011, but the TAG will also welcome input arising from TPAC discussions. Assuming no serious problems are found during the review, the TAG intends to publish this as an approved finding no later than the end of our F2F meeting on 12 January 2012.
From the abstract of the proposed finding:
"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."
Comments on the draft finding should be sent to www-tag@w3.org.
TAG member Jonathan Rees has been leading an effort to rigorously explain the nature of agreements on referential use of URIs, and how such agreement are reached. Perhaps the best way to understand the scope of this work is to quote from the 25 June 2011 Editor's Draft Providing and discovering definitions of URIs (http://www.w3.org/2001/tag/awwsw/issue57/20110625/):
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.
Two additional documents have been prepared in support of this work:
This work has been carried out in consultation with the AWWSW task group (http://www.w3.org/2001/tag/awwsw/). The TAG plans to publish its results in this area by July 2012.
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:
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:
During discussions at the Sept 2011 F2F, the TAG agreed to make this a top priority activity for the coming 6 months. Also, a session on this topic has been proposed as a 2011 TPAC breakout.
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.
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:
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.
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:
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.
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.
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.
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.
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."
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 W3C has published working drafts HTML+RDFa 1.1 Support for RDFa in HTML4 and HTML5 and HTML Microdata. The TAG is concerned that both of these specifications provide for embedding data in HTML documents, but they do it using different syntax, and supporting different abstract models. Both of these specifications are published by the HTML Working Group, and the RDFa draft is co-published by the RDF Web Applications Working Group.
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.
The TAG has for several years worked toward providing a comprehnsive architecture for metadata on the Web. As of our Sept. 2011 F2F, we have decided to focus more narrowly on URI Definition Discovery, which emerged as a crucial piece of the larger metadata puzzle. TAG ISSUE-63: Metadata Architecture for the Web and the related ISSUE-62: Uniform Access to Server-provided Metadata remain open, and the TAG may decide at some future date to more actively engage in other aspects of metadata architecture for the Web.
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.
$Revision: 1.19 $ of $Date: 2011/10/28 14:08:58 $
