Re: Making MGET more GET-friendly?

On Mar 10, 2004, at 11:18, ext Dirk-Willem van Gulik wrote:

>
>
>
> On Mar 10, 2004, at 9:52 AM, David Powell wrote:
>
>>>> How about if it was MANDATORY for responses to MGET to have a
>>
>>> s/MGET/GET/ perhaps ?
>>
>> No, I meant MGET here. I was proposing that you could continue to get
>
> Ok - so you still need some code in the agents.

No more so than for GET, POST, PUT, DELETE, etc. etc.

URIQA does not increase implementational burden on the client side.

>
>> the resource using GET http://www.example.com/ex , and that you could
>> get the resources metadata using MGET http://www.example.com/ex , but
>> that the MGET would also return a Content-Location header pointing to
>> http://www.example.com/ex.rdf or
>> http://sw.example.com/metadata.cgi?url=http:%2f%2fwww.example.com%2fex
>> which could then be used by GET requests for agents that didn't
>> support MGET. This would help MGET data to still be part of the wider
>> web.
> ....
>> This still assumes a 1:1 relationship between data and metadata, but
>> it makes getting metadata, and getting remain separate operations
>> which could have independent access controls.
>
> If you assume that - and given the above 1:1; would it not be simpler 
> to simply
> postulate an extra header:
>
> 	Characteristics-Location: http://www.example.com/ex.rdf
>
> in the reply of any GET ? In particular that of the GET of 
> http://www.example.com/ex.
> And making sure you -also- get it when a cheaper HEAD is done ? Or 
> does that
> not accomplish all you want ?

No. It doesn't (for me). Please see the URIQA FAQ about the shortcomings
of the header approach...

Patrick

--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com