W3C home > Mailing lists > Public > www-tag@w3.org > September 2011

Re: Notes on "Identifying Application State" 30 Aug 2011 Draft

From: ashok malhotra <ashok.malhotra@oracle.com>
Date: Fri, 09 Sep 2011 05:47:48 -0700
Message-ID: <4E6A0AF4.3070100@oracle.com>
To: www-tag@w3.org
Noah:
I have responded to (most of) your comments and checked in a new version at
http://www.w3.org/2001/tag/doc/IdentifyingApplicationState-20110910.html
I hope we can approve this in Edinburgh.
All the best, Ashok

On 9/7/2011 7:42 PM, Noah Mendelsohn wrote:
> Ashok,
>
> Overall, I think your draft [1] is excellent, and very close to publication-ready. I would particularly like to thank you again for the hard work that's gone into reflecting, in this draft as well as other recent ones, my concerns about "?" vs. "#" and about identification of documents as well as states.
>
> The following are, for the most part, editorial suggestions, but first the few substantive comments (numbers refer to sections in the document)
>
> Substantive Comments
> --------------------
>
> I think the following are, with one possible exception, easily resolved with very localized changes. For most, I've proposed alternate text:
>
> 2.1.1 "Thus, there is no conflict if the content URI contains a fragment identifier that is the same as the fragment identifier in the original URI. "  This seems to say that there's no conflict if the HTML contains an ID that would be resolved if the Javascript were not to run, while the same fragment identifier resolves to something else (the point in the video) if Javascript is run. Seems like a conflict to me. In fact, section 6 says it's a conflict. Suggestion: just leave out the sentence quoted above. Or maybe I've misunderstood the intention, in which case I suggest you reword.
>
> 2.1.2 "It shows that in a world of dynamic documents, the traditional fragment identifier need no longer be an idref value that addresses an existing node in the serialized HTML making up the HTTP Response. " It seems that somewhere here you should note that this practice, while popular and indeed sanctioned by this finding, is not at the moment covered by the appropriate normative specifications. Suggest you include a reference to Section 6 for more details.
>
> 3. "This is a problem because if you use these facilities your website will not work correctly with IE9 or Opera, or at least not yet" Suggest: "This is a problem because if you use these facilities your website will not work correctly with >older browsers or (for now) with IE9 or Opera.< I think older browsers are at least as much a problem as IE9 or Opera, with all respect to both of those. Editorial: should we spell out Internet Explorer each time, or at least do it once and introduce the abbreviation: "Internet Explorer 9 (IE9)".
>
> 7. (Conclusion section): "the need has arisen to identify application states that are reproducible and can be shared. " I would prefer: "the need has arisen to identify application states that are reproducible and also to identify individual documents, such as maps or emails, managed by Web applications.  Such identifiers must be shareable and, where appropriate, usable for linking on the Web. " Reasons: 1) we make the case that documents as well as states require identification 2) I think linking is an important goal for these identifiers, especially when the referents are documents.
>
>
> Editorial
> ---------
>
> 1. "Nearly twenty years later, the Web has built a strong set of conventions around how URI parameters are used." Two concerns: the previous sentence referenced RFC 3986, but it's not 20 years since that was published; also, I'm not sure it's good English to suggest that a "Web" can "build" something. Suggest: "Nearly twenty years after the Web was first made available, conventions for use of such URI parameters continue to evolve."
>
> 1. "The Web is beginning to discover and codify " -> "Users of the Web are beginning to discover and codify..."
>
> 1. "In this document we use the term "URI" to include URLs, URIs and IRIs." -> "In this document we use the term "URI" to include URLs (as used in the HTML5 specification), and IRIs." (Reasons: 1: URL is no longer a current term in normative specifications such as RFC 3986, but it is used in HTML5 in ways covered by this draft 2: it's not coherent to say that the term URI includes URIs.
>
> 2.1.1 "in this case, the JavaScript embedded in the HTML Response processes the portion" -> "in this case, the JavaScript embedded in the HTML Response, processes the portion" (add comma after Response...also, not sure Response should be capitalized)
>
> 2.1.1 "usecase" -> "use case" (note section title "2. Use Case Scenarios", including the space
>
> 2.6 "Note that this idiom also creates significant hurdles for non-mouse users of the Web." The intention is clear, of course, but "non-mouse users of the Web" almost suggests that there are rodents that do use the Web. :-) Anyway, I think this is clumsy. Maybe: "Note that this idiom also creates significant hurdles for users of assistive technologies or other automated means of page navigation."
>
> 3. "the entire URI is transmitted the server and it can respond in a manner tailored" -> "the entire URI is transmitted the server>, which< can respond in a manner tailored" Reason: anticedent of "it" was ambiguous.
>
> 3. "The methods, history.pushState() and history.replaceState() are relatively new and browser uptake is changing as we speak."  We're not "speaking". Suggest "...are relatively new, and deployment of browsers with this capabilities will take time."
>
> 4. "usecases" -> "use cases"
>
> 4. "the server can decide, based on the client's capabilities. how to respond." Typo: should be a comma after "capabilities"
>
> 5. "The questions that this document addresses is:" This would be fine, except that the whole rest of the para is talking about retrieval of documents, so "this document" is a bit ambiguous. Also, questions is plural, so I suggest: "The questions that this >finding< addresses >are<:"
>
> 5. "the back button works correctly. " Should be a question mark at the end "the back button works correctly? "
>
> 5.1 I'm fine with the intended message, but the wording seems unnecessarily confusing. I don't have a simple alternative just now, but I think some editorial work would improve it.
>
> 5.2 "Users of a Web application must be able to discover the URI for a given document" -> "Users of a Web application must be able to discover the URI for a given document >managed or displayed by that application<". I think we want to emphasize that the case in question is: a container application is managing or displaying multiple documents, and we are encouraging that each be identified with and accessible via its own URI.
>
> 6.1 "All media type specifications and registrations, especially new types," -> "All media type specifications and registrations, especially >for< new types,"
>
>
> [1] http://www.w3.org/2001/tag/doc/IdentifyingApplicationState-20110830.html
>
Received on Friday, 9 September 2011 12:48:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:39 GMT