Notes on "Identifying Application State" 30 Aug 2011 Draft

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 Thursday, 8 September 2011 02:42:40 UTC