RE: HTTP Endpoints and Resources

Hello Rhys,

> -----Original Message-----
> From: Rhys Lewis [mailto:rhys@volantis.com] 
> Sent: 02 October 2007 09:37
> To: Williams, Stuart (HP Labs, Bristol)
> Cc: 'Pat Hayes'; Booth, David (HP Software - Boston); 
> 'Technical Architecture Group WG'
> Subject: RE: HTTP Endpoints and Resources
> 
> Hello Stuart 
> 
> > I think that I allowed in the [*] labelled footnote that  you could
(if 
> > your really wanted to) assign these things URIs either as a  means
of 
> > reference or as a means of access (or
> > both) - I just don't feel compelled to do so and infact feel that 
> > speaking of them will lead to more confusion rather than less. I
think 
> > that I might also reject a position that there necessarily is an 
> > http:resource in the 303 case (named or
> > not)  - I think you'll get into a whole lot of futile argument about

> > whether a response comes from a webarch:resource, an http:resource;
a 
> > web cache; an origin server; a proxy etc. Viewing all responses as 
> > coming from web infrastructure (which may or may not have interacted

> > with the referenced webarch:resource) is surely a whole lot simpler
a 
> > picture than imagineering loads of fine-grained web infrastructure 
> > components.
> 
> I didn't express a desire to do this, just that I could see 
> ways of it being done.

Fair enough... 

<snip/>

> > I take it that that you are refering to the "...that which is
accessed 
> > is different to that which is denoted..." meme.
> 
> Yes.
> 
> > I think that can be satisfied by regarding all responses as being
> > provided by web infrastructure - requests are made of the web, 
> > responses (if any) are provided by the  web. Some responses arise
due
> > to interaction with the resource; others do not.
> 
> Um, now we might only be discussing the number of Angels on 
> the tip of this particular pin. Do you mean the 
> http:resource? If so, I think we are saying the same thing.

No... I mean the intended (by the owner/baptiser/deployer of) referent
of the URI - a webarch:Resource a.k.a  a thing.

> >> Except that to describe the fragment id approach to
non-information 
> >> resources you do have to be absolutely explicit about the
associated 
> >> http:resource that provides the response.
> > No you don't... you have to be absolutely clear about the way URI's 
> > are handled for the purposes of access, that the fragment part is 
> > 'broken off', placed in the back pocket for later use, and that 
> > subject of an access attempt is whatever is referred to by the 
> > remainder of the URI (the racine as David tends to call it).
> 
> Really? It seems to me that you have to say something about 
> the http:resource that is identified by the racine. 
                            ^^^^^^^^^^
Hmmmm....
	"identified" meaning "referred to" or "denoted by" ?
or	"identified" meaning "access using" ?

I read the former... which I take to be the webarch:Resource ie. a thing
referred to by the URI.

> For 
> example, it needs to exist if this approach is going to give 
> useful results. Isn't that the same as for the http:resource 
> that gives back the 303?

The thing referred to by the racine... in order for the <doc#term>
approach (as I think Dan refers to it) to be useful, retrival attempts
on <doc> need to either result in a webarch:Representation (2xx) of
<doc> that has something to say about <doc#term> or.... lead (via 3xx)
to a webarch:Representation that has something to say about <doc#term>.


> Best wishes
> Rhys

Regards,

Stuart
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks
RG12 1HN
Registered No: 690597 England

Received on Tuesday, 2 October 2007 09:52:45 UTC