Re: Identifying Application State

We received two comments on the final version version of IdentifyingApplicationState.
See http://lists.w3.org/Archives/Public/www-tag/2011Oct/0105.html
A revised version addressing these comments is available at:
http://www.w3.org/2001/tag/doc/IdentifyingApplicationState-20111130
All the best, Ashok

On 9/27/2011 5:45 AM, ashok malhotra wrote:
> The TAG expects soon to publish a Finding titled "Identifying Application State".  A final draft is now available at [1] for review by the community. We request that you send any comments to the www-tag@w3.org mailing list by 28 October 2011.
>
> From the abstract:
>
>     /"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."
>     /
>
>
> TAG Findings (complete list at [2]) are notes that convey the TAG's opinions on various matters relating to Web Architecture. TAG Findings are not W3C Recommendation-track documents, but the TAG welcomes comments and suggestions on our finding drafts.
>
> Thank you very much.
>
> Ashok Malhotra
>
> [1] http://www.w3.org/2001/tag/doc/IdentifyingApplicationState-20110930.html
> [2] http://www.w3.org/2001/tag/findings