- 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