Re: Content Sniffing impact on HTTPbis - #155

On Sun, 14 Jun 2009, Julian Reschke wrote:
> 
> Under your "definition", the resource is selected based on *both* the 
> URI and the context of the GET request (request headers, point in time). 
> It's *possible* to explain things that way, but it is totally confusing 
> because the *URI* is supposed to be the identifier, by definition. So it 
> seems to me you're creating more confusion, not less.

That's why "URL" is a far better term than "URI". Most of these 
terminology problems were fine until we started taking perfectly good Web 
resource addresses and started treating them like they meant something 
more. URIs in practice don't identify anything; that is a theoretical 
model that simply doesn't match common practice.

Indeed, the spaces where URIs have been used as identifiers have shown why 
having dereferencable identifiers is a bad idea -- for instance they are 
unwieldy, leading to people using techniques like prefixes and prefix 
declarations to avoid the problem; and they invite dereferencing even when 
that isn't necessary, leading to high load for popular identifiers [1].

[1] http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic


> > It is the HTTP and URI specifications that are, IMHO, continuing to 
> > cause confusion by insisting on unfamiliar terminology.
> 
> Unfamiliar to whom?

The vast majority of engineers, including those implementing technologies 
such as HTTP and URIs. By using such confusing abstract terminology, these 
specs contribute to the less than perfect interoperability that has 
plagued the Web for the past two decades.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Sunday, 14 June 2009 08:24:15 UTC