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

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

From: <Patrick.Stickler@nokia.com>
Date: Wed, 12 Feb 2003 17:30:29 +0200
Message-ID: <A03E60B17132A84F9B4BB5EEDE57957B01B90B40@trebe006.europe.nokia.com>
To: <JeffreyWinter@crd.com>, <miles@milessabin.com>, <www-tag@w3.org>



> -----Original Message-----
> From: ext Jeffrey Winter [mailto:JeffreyWinter@crd.com]
> Sent: 12 February, 2003 17:15
> To: Miles Sabin; www-tag@w3.org
> Subject: RE: Proposed issue: site metadata hook (slight variation)
> 
> 
> 
>  
> > But there's a crucial difference. My proposal (which is 
> really only a 
> > minor variation on Patricks) uses a _request_ header, to 
> > allow clients 
> > to actively request metadata. The current 
> > distributed-registry proposal 
> > only allows servers to provide unsolicited metadata responses.
> 
> The problem is that if you are using a GET with a Meta: header, 
> then are you really getting a representation of the resource?  It 
> seems to be stretching the semantics of the GET method. 
> 
> Also, how do you PUT/DELETE/POST to that metadata, just using 
> the Metadata: header? It seems morally equivalent to a set 
> of M(XXXX) methods which has the same problem.
> 
> The only issue with having the OPTIONS method return 
> a Meta-Location: header is that it takes multiple requests 
> to obtain the data, an OPTIONS request to get the uri of the 
> metadata, and a GET on that uri to actually obtain it.  I see
> this as both beneficial and necessary.

But it also requires that the body of knowledge have an explicit
URI, which is in two ways unnecessarily inefficient.

One should be able to interact with a server regarding knowledge
known by that server about a resource with only the URI denoting
the resource.

IFF you want to posit another URI to denote that body of knowledge,
you should be able to, but the architecture should not demand it.

Patrick
Received on Wednesday, 12 February 2003 10:30:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:16 GMT