Re: RFC 2616 vs. AWWW

>On Oct 11, 2007, at 4:19 PM, Pat Hayes wrote:
>
>>URI1  the first URI
>>endp    the http endpoint identified by URI1
>>URI2   the URI to which endp redirects URI1
>>redir   the http endpoint identified by URI2
>>potato  the potato which (we all know) URI refers to
>>
>>Then the following should hold, according to http-range-14:
>>
>>URI1 refers to potato
>>URI1 identifies endp
>>URI2 identifies redir
>>URI2 refers to endp (since endp is an 'information resource, the 
>>kind that HTTP1.1spec is talking about, so reference and 
>>identification coincide here)
>>
>>and, hopefully, endp emits representations which explain the first 
>>of these facts.
>
>Do you mean that URI2 refers to redir?

YES. Aaargh. Sorry, fingers running away from my brain. What an 
unfortunate mistake, ouch. Here's what it should say:

URI1 refers to potato
URI1 identifies endp
URI2 identifies redir
URI2 refers to redir (since redir is an 'information resource, the 
kind that HTTP1.1spec is talking about, so reference and 
identification coincide here)

>Otherwise "reference and identification coincide here" doesn't seem 
>to hold, as the way you have stated is
>URI2 identifies redir and URI2 refers to endp
>(unless endp and redir are the same thing)
>
>A few other questions.
>
>1) Could you repeat here the definition of "identify" that you use 
>or point me to something that defines identify in the way you use 
>it?  I think I'm ok with "denote"? I wasn't able to figure out what 
>identifies means from the relatively few references to the term 
>identify or identifies [1,2] in the http spec.

I'm using 'identify' to mean what I previously called 'accesses', ie 
X identifies Y when the Web protocols will take your request to Y 
(and expect it to deliver some response) when you try to GET X. This 
seems to have been the universal meaning of 'identify' in all the 
technical literature until fairly recently, and certainly in RFC 
2616; and it is the sense that is still widely used by those more 
concerned with architecture than philosophy.

To be honest I'm not *exactly* sure what kind of thing Y is here, at 
one point I was told it was an http endpoint but others have said 
not. In my naive way I think of the typical Y as being a website or a 
webpage.

>Given the http definition of resource: "A network data object or 
>service that can be identified by a URI, as defined in section 3.2. 
>Resources may be available in multiple representations (e.g. 
>multiple languages, data formats, size, and resolutions) or vary in 
>other ways."
>
>2) Would it be fair to assume that the class "data object" and 
>"service" are disjoint classes. (something can't be a data object 
>and a service at the same time)

I have no idea, to be honest. Maybe services are mediated by data 
objects? I guess Ive been reading the intent of this to be that the 
authors wanted to cover both static things like html web pages and 
also dynamic things like webcams and RSS feeds, is all. The REST 
model covers both.

>3) Given (2) Is there any way for me to tell, absent some assertion, 
>whether a URI identifies or refers to a data object or a service?

Well, again, with my (limited) understanding of the distinction, one 
way might be to do a diff on two files got by successive GETs (?) But 
I bet this isn't what you meant :-)

>4) Is it just me, or is the following nonsensical? "a service may be 
>available in multiple representations" (obtained by substitution of 
>"resource" by "service" sanctioned by "resource: A network data 
>object or service".)

I don't think its *nonsensical*. I can imagine an RSS feed that 
delivers English and French versions of everything, for example, 
depending on content type negotiation.

>5) "emits" isn't part of the http spec [3].

OK, sorry I was speaking informally. By "X emits Y" I meant, Y is a 
(REST-)representation of X returned in response to an HTTP GET 
request to X.

>Given that, this account doesn't acknowledge any relation between 
>either of the URIs, and the resource of which the representations 
>"emitted" are made available of. So we have a dangling resource, as 
>it were.

? I guess I don't follow you here. True, endp is kind of 'dangling' 
in that its URI doesn't let you get 'at it' directly, because it 
refuses to send back representations of itself in response to a GET. 
But isn't this exactly the situation whenever a 303 is used?

Pat


>
>[1] google: "site:http://www.w3.org/Protocols/rfc2616/ identify"
>[2] google: "site:http://www.w3.org/Protocols/rfc2616/ identifies"
>[3] google: "site:http://www.w3.org/Protocols/rfc2616/ emits"


-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Friday, 12 October 2007 15:04:31 UTC