Re: Identifying Application State

Ashok: thank you very much for posting this announcement. I found two nits, 
both of which I have fixed in place in the HTML:

* The document you checked in was still labeled as an Editor's draft, which 
seems inconsistent with the announcement. I've removed that text and it's 
now listed as a "Proposoed TAG Finding" (not a formal designation in the 
W3C or TAG process, but suggestive of the state of this draft I think)

*  The convention is that the "Latest version" is an undated link. I 
changed that, and also made sure that the version at [1] is the 30 Sept 
2011 version.

Also, the TAG resolution to publish [2] called for review until 15 
November. Specifically:

RESOLUTION: The TAG will publish the "Identifying Application State" 
document as a "proposed finding" by 30 Sept. 2011, and will solicit 
feedback to be due by 15 November. We will bring attention to the draft at 
TPAC and encourage people to send feedback. Unless major concerns are 
raised, goal is to publish a final finding no later than Jan. 2012 F2F.

I'm inclined to leave things as they are with a 28 October target on this 
draft, so that this round of comments will be available ahead of TPAC. We 
should indeed solicit more comments at TPAC, and hold off publication until 
those are available.

So, all set I think.

Thank you.

Noah

[1] http://www.w3.org/2001/tag/doc/IdentifyingApplicationState
[2] http://www.w3.org/2001/tag/2011/09/13-minutes#item05

On 9/27/2011 8: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

Received on Wednesday, 28 September 2011 13:45:30 UTC