Re: Content Sniffing impact on HTTPbis - #155

Ian Hickson wrote:
> 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.

HTTP URIs are URLs, and URLs simply are URIs that also double as 
locators (see RFC 3986). I don't see how this changes the definition of 
being an identifier at all.

Whether HTTP URLs as identifiers for things like RDF properties or XML 
namespaces is a good idea is an entirely different discussion. Mixing 
those here isn't helpful.

> 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

Again, what does this have to do with the terminology discussion we have?

>>> 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.

Let's agree to disagree on this. But it would be interesting if you 
could back up that claim. In particular, how does the terminology choice 
you are disagreeing with cause interoperability problems?

BR, Julian

Received on Sunday, 14 June 2009 08:50:31 UTC