This is a report from the W3C Technical Architecture Group to the W3C membership on TAG activities from December, 2011 through April, 2012.
During the period covered by this report, the TAG held two face to face meetings: 4th-6th January 2012, MIT, Cambridge, MA and 2nd-4th April 2012, Sophia-Antipolis, France .
The next full F2F meeting of the TAG will be held 12th-14th June 2012 4-6 January 2012 at the offices of the W3C in Cambridge, MA.
The TAG holds weekly teleconferences, typically on Thursdays.
TAG election results were announced on 11 January 2012. The TAG welcomes newly elected member Robin Berjon, and welcomes back incumbent member Henry Thompson. TAG members Jonathan Rees and Noah Mendelsohn (chair) were re-appointed by the W3C director. All four will serve on the TAG through the end of January 2014.
That TAG wishes to thank outgoing TAG member Dan Appelquist for his many important contributions to our work.
As discussed in recent status reports, the 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.)
As significant TAG projects are either completed or abandoned, entries are recorded in the work plan, and product pages are updated to indicate the final results of the work. For major projects, announcements of project completions are also sent to public-tag-announce@w3.org and to www-tag@w3.org.
The TAG solicits 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 provide details of the TAG's work during the period covered by this report.
During the period covered by this report, the TAG announced completion of work on three significant projects: its study of Web Application State, its contributions to unifying approaches to encoding data in HTML documents, and its last call review of the HTML5 draft specifications. The following sections provide details on the final results of each of these.
The finding Identifying Application State was published on 1 December 2011, somewhat ahead of schedule. Completion of work on this topic was announced on 1 May 2012.
From the abstract of the 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.
Note: this is the topic that, in the TAG's previous status report, was titled RDFa and Microdata
The TAG's work in this area was initiated due to concerns about incompatible approaches to embedding data into HTML documents. Specifically, the TAG was concerned about the lack of coordination between the approaches outlined in the HTML+RDFa 1.1 Support for RDFa in HTML4 and HTML5 and HTML Microdata. As previously described, the TAG had sent an e-mail suggesting that the W3C create a task force to investigate the possible unification of the proposed technologies. The W3C responded with a plan to initiate an HTML Data Task Force (proposed charter) under the auspices of the Semantic Web Interest Group (SWIG); the HTML Data Task Force was created in mid-September 2011, and was chaired by TAG member Jeni Tennison.
The task force scope was limited to a technical analysis of the relationships between microdata, RDFa and microformats with the goals of:
Discussions took place on the public-html-data-tf@w3.org mailing list and were captured in a wiki, which continues to be available for the community to capture best practice in the use of HTML data.
The HTML Data Task Force identified a number of issues to ease the alignment of microdata and RDFa. Most of these were raised as bugs on the relevant specifications.
Two SWIG Notes were created by the Task Force:
It is hoped that the Microdata to RDF Working Draft will be taken forward to Recommendation when microdata moves forward to Recommendation status, but at this time there is no Working Group in a position to do this.
The TAG resolved on 19 January 2012 that, given the good progress reported above, this project is to be marked as successfully completed. The TAG will continue to monitor developments in HTML data, but has no specific further actions planned.
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 RFCs in their jurisdiction, and indeed several efforts are now underway at IETF to deal with such concerns.
In our last report we indicated that the TAG would undertake a second round of work in this area, producing its own report on issues relating to MIME and the Web, but we have since decided to abandon that second phase of work. On its teleconference of 2 February 2012, the TAG resolved that: The TAG is closing its work on MIME/Web, noting successful completion of 1st round of work. Note also that the Fragment Identifiers and Mime Types product is related to this work.
We do note that work is ongoing in the IETF to produce http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs, the most recent draft of which (http://tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-06) includes updates that address a number of the TAG's concerns.
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. No significant work on that review was done during the period covered by this status report, but we note here that completion of work on this topic was formally announced on 30 December 2011. The TAG will continue to consider issues relating to HTML5 as they arise, and we note that our analysis of HTML/XML Unification is ongoing.
The TAG Work Plan provides a list of ongoing projects, with product page descriptions detailing the goals and status of each. Here we briefly review the status of those designated as highest priority.
For several years starting in 2002, the TAG considered what proved to be a difficult question relating to the proper use of HTTP, if any, for access to information about resources, as opposed to the more common use for retrieval of resource representations. The issue was tracked in the TAG's old issue list under the name httpRange-14, and now in tracker as the TAG's somewhat broader ISSUE-57. In 2005, the TAG gave advice to the community, suggesting the use of HTTP status code 303 to redirect to such descriptive information, thus reserving status code 200 for resource representations.
As noted in previous status reports, the TAG has been working for some time with others in the community to more properly set out the architectural details relating to publication of metadata on the Web.
Over the last few months, the TAG has re-focused more specifically on the details of access to metadata, responding to concerns that the use of status code 303 has not been acceptable to significant segments of the linked data and Semantic Web communities. This recent work has been led by TAG member Jonathan Rees. Building on the earlier analytical work, the TAG issued a call to the community, requesting specific proposals for re-resolving issue httpRange-14, offering a baseline proposal as a point of reference. Several proposals were received, some of them lengthy and detailed, and a great deal of discussion has ensued. The TAG is currently working to compare the characteristics of the different proposals, in the hopes of first achieving community consensus as to what the tradeoffs are, and then if possible, consensus on the best way forward.
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 goals and directions for work in this area have not changed substantially since the TAG's previous report, except that the due date for a Proposed Recommendation has slipped to December, 2012. The deadline was changed in part so that TAG members involved in both projects can devote more attention to work on fragment identifiers; that work will be input to time-critical developments in the IETF. During the period covered by this report, the TAG reviewed in detail draft proposals for a finding in this area.
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:
As described in the product page: "The goal of this work is to describe the contradictions in the definitions between different specifications (such as media fragments and application/xml mime type definition) in the definition of fragment identifiers, to describe any changes to draft documents that are required to manage those contradictions, and to provide some general guidelines to those creating mime type definitions in the future around the interpretation of fragment identifiers." The specific success criteria identified are:
Except as discussed above in the report on Mime and the Web, relatively little progress has been made on this project during the period covered by this report. The TAG has, within the last few weeks, decided to give this higher priority once again, to maximize the opportunity for synergy with related work in the IETF, and we have assigned an action to TAG member Jeni Tennison to prepare a proposal for how best to proceed.
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 produced a draft HTML/XML Task Force Report which the TAG reviewed with Norm Walsh at our F2F meeting in January. Some revisions were made since then, and the TAG expects to meet with Norm to decide next steps at our upcoming F2F meeting in June 2012.
In our last report we described our initial efforts to focus on protecting the privacy of users through minimizing unnecessary data exposure through JavaScript APIs. That work was led by outgoing TAG member Dan Appelquist.
At our April F2F meeting the TAG reviewed a new draft Privacy by Design in APIs: Draft TAG Finding 28 March 2012 prepared by incoming TAG member Robin Berjon. This draft expands the scope of the work to focus not just on minimizing data exposure, but also on other techniques that are proving useful for designing APIs that will protect users' privacy. The TAG also agreed on the 2 Feb 2012 version of the product page as the general plan for moving forward. Robin is working on a 2nd draft of the proposed finding, and the product plans will be updated based on our subsequent review of that.
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?) We are continuing to review proposals for framing a project in this area, but as was the case in our last report, we have yet to agree on a plan.
We reported previously that the TAG is exploring 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. As we previously report, the TAG endorsed the creation of the workshop on domain names and persistence at the 7th International Digital Curation Conference. The workshop was co-sponsored by the World Wide Web Consortium and the Digital Curation Centre. TAG members Henry Thompson and Jonathan Rees attended.
The TAG discussed the workshop results on several occasions, including at our 4 January 2012 F2F. We also reviewed a draft of a TAG product plan, and concluded that further work was needed to refine the plan before deciding whether to adopt it.
Responding to a standing request from W3C CEO Jeff Jaffe, the TAG sent in February 2012 a list of Issues of concern to the TAG, and we responded to some questions and concern that he then raised (see thread following from the Issues List e-mail). We expect to provide such lists to Jeff approximately twice a year.
During this period, the TAG decided not to continue work on the following initiatives:
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 November, 2011, covering the period from May through October 2011.
$Revision: 1.8 $ of $Date: 2012/05/08 20:42:19 $
