- From: Miles Sabin <miles@milessabin.com>
- Date: Wed, 12 Feb 2003 11:59:27 +0000
- To: www-tag@w3.org
Patrick.Stickler@nokia.com wrote,
> > * It doesn't address TimBLs "meta meta" problem.
>
> Not true. MGET has no "meta meta" problem.
Well, I guess we differ here. I thought that TimBLs challenge was a
resonable one and that your response was coherent but unconvincing.
> Can GET return anything other than a representation of the specified
> resource? I don't think it can.
A Meta: request header would provide a way of allowing a client and a
server to negotiate a variation on the normal GET semantics. There's no
obvious _technical_ obstacle to doing this.
> And descriptive knowledge about a resource is not IMHO a
> representation of the resource.
Agreed.
> And what about abstract or non-web accessible resources? If there is
> no representation available, GET will return 404, No?
Sure, but assuming the existence of metadata, that could be returned in
response to a Meta:-qualified GET, eg.,
GET /some-namespace-uri HTTP/1.1
Host: whatever
HTTP/1.1 404 Not found
GET /some-namespace-uri HTTP/1.1
Host: whatever
Meta: application/rddl+xml
HTTP/1.1 200 OK
Content-Type: application/rddl+xml
Meta-Location: http://whatever/whereever/some-namespace-uri
... RDDL stuff ...
Again, there's no _technical_ obstacle to this: I could build a client
and server with this behaviour using standard toolkits today.
> But MGET will return a description (if available) irregardless of
> whether any representation is also available.
Sure, that'd work too, in principle ... but how are you going to get it
deployed?
Cheers,
Miles
Received on Wednesday, 12 February 2003 06:59:59 UTC