W3C home > Mailing lists > Public > www-tag@w3.org > February 2003

Re: Proposed issue: site metadata hook (slight variation)

From: Miles Sabin <miles@milessabin.com>
Date: Wed, 12 Feb 2003 11:59:27 +0000
To: www-tag@w3.org
Message-Id: <200302121159.27940.miles@milessabin.com>

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.


> 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 


Received on Wednesday, 12 February 2003 06:59:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:36 UTC