Re: ISSUE-81 (resource vs representation)

On Sun, 27 Sep 2009, Julian Reschke wrote:
> Ian Hickson wrote:
> > On Sun, 27 Sep 2009, Julian Reschke wrote:
> > > [...] there are parts of HTML5 which *do* use the traditional definition:
> > > 
> > > "A URL is a string used to identify a resource." -- HTML5, Section 
> > > 2.5.1, <http://dev.w3.org/html5/spec/Overview.html#terminology-0> 
> > > (the fragid may be instable...)
> > 
> > This is actually intended to refer to "bag of bits". It identifies a 
> > bag of bits in the same way that a telephone number identifies a 
> > person. Sure, if you call a number at different times you might end up 
> > with different people, but you're still using a phone number to 
> > identify a person, you just don't know which one until you try to use 
> > the phone.
> 
> It appears that you're saying that the phone number does not really 
> identify a person then.

It gives enough information to obtain a person. (Not enough information to 
unambiguously obtain a _particular_ person.)


> So then, if a resource is a bag-of-bits, what do you call the thing you 
> address with a POST request?

A POST request returns a bag of bits also, so "resource".


> > It may be that you disagree with the meaning used for the word 
> > "identify" here as well; it's being used in the sense of "give enough 
> > information to obtain", not the sense "provide a name for" (the latter 
> > being the meaning often used in Semantic Web circles for the word 
> > "identify").
> 
> I'll try to stay away from that discussion.

Ok.


On Sun, 27 Sep 2009, Maciej Stachowiak wrote:
> > > 
> > > "A URL is a string used to identify a resource." -- HTML5, Section
> > > 2.5.1, <http://dev.w3.org/html5/spec/Overview.html#terminology-0> (the
> > > fragid may be instable...)
> 
> It seems like it would be more painstakingly accurate to say "A URL is a 
> string used to retrieve a resource" or "A URL is a string that provides 
> the address of a resource." But even that is not quite accurate, because 
> in the case of HTTP, it's the full HTTP request (including method and 
> headers) that determines what resource you get, if you take resource to 
> be the concrete octet sequence you get back.

The sentence refers to _a_ concrete octet sequence, not _the_ concrete 
octet sequence. It's not saying that the URL is enough to unambiguously 
name a _particular_ resource, just that it gives enough information to 
obtain _a_ resource.


On Sun, 27 Sep 2009, Julian Reschke wrote:
> Henri Sivonen wrote:
> > On Sep 27, 2009, at 14:18, Maciej Stachowiak wrote:
> > 
> > > It seems like it would be more painstakingly accurate to say "A URL 
> > > is a string used to retrieve a resource"
> > 
> > I think the point of the ISSUE is that the theoretically pure view is 
> > that you can never retrieve a resource but only its representation. 
> > See also the subject line of 
> > http://lists.w3.org/Archives/Public/www-tag/2009Jun/0101.html
> 
> Henri, when you say "theoretically pure view" it almost sounds as a bad 
> thing.
>
> Technical purity is a *good* thing, unless it is in conflict with other 
> design goals. I don't think it is in this case.

It's in conflict with the design goal of using terminology that matches 
what most people think of.

RFC2616's terminology is more abstract than is useful for most Web 
developers, and therefore this kind of terminology confuses people. The 
right thing to do here is to fix the HTTP spec's use of this terminology 
to be more in line with what developers at large use. This is in fact 
basically the same problem as with the term "URL" -- we should update the 
specs that invent these new terms to use the terms people are familiar 
with, so that the specs become more accessible to more people.

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

Received on Sunday, 27 September 2009 18:27:44 UTC