Re: Identification of documents in Web applications


On 9 Mar 2011, at 16:44, Noah Mendelsohn wrote:
> On 3/9/2011 11:08 AM, John Kemp wrote:
>> to me, "?" provides arguments that are interpreted relative to the server-side namespace
> In short:
> * We can use # which is not sent to the server, unless HTTP changes.
> * We can use ? results in excess traffic to the servers, unless the user agents change (as they are starting to)
> I think ? is the more appealing long term direction, and should be seriously explored.

Hmm. How you design your URIs should, I think, be based on the kind of information that you want to encode within the URI: if it's hierarchical, it makes sense to use the path; otherwise, particularly if it looks more like property/value tuples, it makes sense to use the query portion. I don't understand why we should particularly pick on the query as an alternative to the fragment identifier? (Oh, I see that in Noah's original suggestion, he did say 'and perhaps other parts of a URI'.)

What we see with hash(-bang) URIs is that web developers are starting to structure them to look like paths or query strings rather than using the traditional "local name" (id) -- they are encoding the same information, but putting it in the fragment identifier to get the performance benefits associated with the fact that changes to the fragment don't cause page reloads.

In the medium/long term, the HTML5 history API [1] meets the goal of enabling web developers to manipulate the address bar and browser history without server access, and it has already been adopted in several browsers.

So what we have to concentrate on, I think, is:

1. Making sure that developers don't do things now and in the immediate future which are going to completely scupper them (and the web) in the long term, which is why setting out some good practice guidelines both for publishers and consumers is important.

2. IF there are likely to be similar issues with non-HTML content (are there?), or IF we think that the HTML5 history API isn't sufficient (isn't it?) then providing an HTTP-level mechanism for saying 'the representation you'll get in response to requests to URIs that look like X are equivalent to what you'll get in response to requests to URIs that look like Y, so don't bother re-requesting URIs that look like X if you already have the equivalent one that looks like Y in your cache'. (Note that this isn't about URI equivalence, but about representation equivalence.)

Those are rather big IFs. I'm not currently convinced we need an HTTP-level mechanism; if we did, perhaps suggesting some pattern around HEAD requests and Content-Location would be sufficient rather than changing how URIs are treated by either the client or server.




P.S. I noticed another example of hash URIs being used on a major website today:
Jeni Tennison

Received on Wednesday, 9 March 2011 20:38:15 UTC