Re: Site metadata; my preference

On Wed, 12 Feb 2003, Mark Baker wrote:

>
> Wow, step away from your email for a few hours, and whammo ...
>
> My preference would be for an optional response header, "Metadata" or
> some such, returned via GET and HEAD.
>
> I don't like MGET for the reasons explained in the TAG finding on
> "URIs, Addressability, and the use of HTTP GET";
>
>   "Safe operations (read, query, view, ask, lookup, etc.) on HTTP
>    resources SHOULD be implemented using GET because that allows the
>    result documents to be identified by URI, while using POST does not."
>     -- http://www.w3.org/2001/tag/doc/get7#principles-summary

Well, it's not that true. Take the OPTIONS method. It is clearly meta
information about what HTTP methods are allowed on this resource (or
should I say this HTTP facet of a resource) OPTIONS _is_ safe, so _should_
be done using GET?
Take also the PROPFIND case in WebDAV, as it is about metadata, should it
be replaced by GET/PUT ?

> I don't like GET+Meta because I feel it violates a good practice
> suggestion of Webarch;
>
>   "Consistent representations: It is confusing and costly when, for a
>    given URI, representations vary in unpredictable ways."
>     -- http://www.w3.org/TR/webarch/#pr-rep-ambiguity
>
> And moreover, if representations were to vary in the way that GET+Meta
> requires, that suggests to me that we're dealing with two resources, not
> one.  Hence my preference for the response header solution, which uses
> two URIs.

And why, instead of adding a new HTTP method or header, why not simply use
content-negotiation? the meta-info will have its own ETag (provided ETages
are consistent in the server), its own URI. Even if it is automatically
generated (see XMP extraction of a JPEG or whatever format).

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."

Received on Wednesday, 19 February 2003 05:03:20 UTC