Re: HashInURI

Thank you, Ashok.  Here are my comments on the draft [1].

Main comments
=============

***Are query strings server-side? Are Fragids client-side?***

The draft has at least one fundamental conceptual flaw, in my opinion, 
which is the unsupported contention that query strings in a URI are a 
server-side construct.  I don't see anything in RFC 3986 [1] to support 
that, and indeed I think that what's crucially interesting about the Google 
maps case is that both server- and client-side logic are aware of and act 
on the association of URIs with query strings to resources.  The pertinent 
text from RFC 3986 is:

    "The query component contains non-hierarchical data that, along with
    data in the path component (Section 3.3), serves to identify a
    resource within the scope of the URI's scheme and naming authority
    (if any).  The query component is indicated by the first question
    mark ("?") character and terminated by a number sign ("#") character
    or by the end of the URI."

I don't see any mention of servers there; the can and are constructed, 
parsed and interpreted by clients as well, and all of that is crucial to 
our story.

Indeed, fragment identifiers are only client-side in a limited sense:  in 
the case where an HTTP interaction is performed, the fragment identifier is 
indeed not included in the Request-URI.  That said, it's also likely true 
that servers are in many cases aware of the association between fragment 
identifiers and the resolution of those identifiers with respect to served 
representations. Indeed, this is why servers can often supply to the client 
Javascript logic that acts on just such associations.

I think it is important to be much more careful, especially with respect to 
the implication that query strings are server-side.  What's interesting is 
that they can be either or both.

That being the case, you should more carefully explore the pros and cons of 
the choices made in Google Maps (client and server aware of ?) vs. GMail 
(you assert, and I assume it's true that GMail uses #-only, and thus 
implicitly has no way to identify an individual email to the server).

***Incorrect rationale for why Google maps uses ?

In section 2.2 you say:

"The URI that Google Maps creates for the displayed map has a long 
server-side parameter but no fragment identifier. This is because the maps 
are images and must be fetched from the server. If the maps were drawn 
using vector graphics, some of the scrolling and zooming could have been 
done on the client."

I'm not convinced that reasoning is correct.  If you look at the logic in 
Google maps, it's more subtle than that.  The URI to which you refer may be 
sent to the server, but the response is typically not either map images or 
vectors; it's Javascript logic.  That Javascript logic in turn has 
knowledge of the map, the zoom level, etc. (as far as I know), and uses 
that logic to do multiple individual GETs for tiles of the map image. 
Those tiles are then assembled by the client to make what the user believes 
is the representation of the original URI.  I believe that this same logic 
could equally be applied to vectors, and indeed I believe >it is< for 
things like the blue lines representing driving directions, which seem 
pretty clearly to be rendered by the client, over the assembled map image 
tiles.

Google maps is, for all these reasons, a terrific example, but I think you 
need to look more carefully at what it does, what that implies about query 
strings in URIs, and what Good Practice would be.

***Section 2.1.1 implies that if it's happening, it's good

Section 2.1.1 correctly points out that in many cases (e.g. CNN video), the 
clients are interpreting fragids is a manner that is not what one would 
expect from the declared Content-type of text/html.  So, these applications 
seem to be in violation of the applicable specification, yet the tone of 
the current draft is: "yes, well, so?".  I think that if the TAG issues a 
Finding or Recommendation in this space, we need to come out strongly in 
favor of a Web in which specifications matter:  if the applications are 
broken, fix them (at least usually);  if the specifications are no longer 
meeting the needs of the Web, fix them.  Either way, we should decide on a 
path forward.

Less significant comments
=========================

*** The status of document says this is a 30 Nov. "Working Draft".  I don't 
think the group has agreed to publish this as a formal WD, and in any case 
we did not do so on 30 Nov.  Please update the status to be correct.  I 
personally would prefer to see this cleaned up somewhat, and then perhaps 
formally published.

*** Partly because I think ? is as important to client-side identification 
as #, I would prefer to change the title.

*** I didn't really understand the explanation in section 2.5.  I suggest 
making that clearer.

I have a number of editorial comments as well, and I'll try and get them 
typed in at some point too.  Thank you.

Noah

[1] http://www.w3.org/2001/tag/2010/11/HashInURI




[1] http://www.ietf.org/rfc/rfc3986.txt


On 11/28/2010 3:02 PM, ashok malhotra wrote:
> I just checked in http://www.w3.org/2001/tag/2010/11/HashInURI
> This is a combination of Raman's hash-in-url writeup and my earlier writeup on
> Client-side Storage. Please review and comment.

Received on Thursday, 16 December 2010 15:59:25 UTC