Re: Content Sniffing impact on HTTPbis - #155

On Sun, 14 Jun 2009, Julian Reschke wrote:
> 
> 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.

I'm not arguing that they aren't identifiers, I'm arguing that when you 
dereference them you get an actual concrete resource, and that saying 
that you get a resource representation is pointless and confusing hair- 
splitting which doesn't actually help people understand the specs when 
they implement them, since the thoretical "resource" construct never 
actually needs to be dealt with in practice.


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

I couldn't agree more.


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

By persuing a terminology that encourages people to think of URIs as 
something more than just a way to obtain a bag of bits, we have encouraged 
the kind of usage seen in RDF and Namespaces in XML.

If we just stuck to concrete terms and didn't go off on a theoretical 
tangent distinguishing "resource" and "resource representation", people 
would not be tempted to use that theoretical difference for actual 
purposes.


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

When implementors don't understand the terms used in a specification, they 
start assuming what it means. When faced with two terms that for all 
practical purposes mean the same thing as here, they start inventing 
differences to justify the spec text in their mind. I've seen this over 
and over again.

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

Received on Sunday, 14 June 2009 19:22:28 UTC