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. I think a key aspect is that those mechanisms I mentioned are
outside the scope of HTTP-based access, and therefore shouldn't need to
trigger the kind of discussion to which you refer, and which I agree are
not necessarily useful in the current context.


>> Personally, I've not been worried by it either. However, we have seen 
>> that some other people are bothered by the apparent ambiguity, and 
>> this was my attempt to see if there was a way to satisfy them.
>>   
> 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.

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

Best wishes
Rhys

Received on Tuesday, 2 October 2007 08:37:43 UTC