- From: Yves Lafon <ylafon@w3.org>
- Date: Wed, 19 Feb 2003 16:50:59 +0100 (MET)
- To: Sandro Hawke <sandro@w3.org>, Mark Baker <distobj@acm.org>
- cc: www-archive@w3.org
On Wed, 19 Feb 2003, Mark Baker wrote: > > How would that work? "Accept: application/meta-html" or something? > > Exactly. "meta-html" is still HTML, so should be using the text/html > media type. Conneg is for handling variability in representations, > not variability in resources. The latter is what URIs are for. I use Accept: application/rdf+xml for now, even it we can't restrict semantic to a single mime type. (I don't want to open the issue about what mime type is _really_ ok for a resource, also ;) ) > To Yves; > > Re OPTIONS, that's a good example, but it appears to me (as I've used > it quite extensively), that it falls on the other side of the equation > that evaluates the trade offs with respect to latency. In the uses I > made of it, an extra round trip was a non-starter. Well OPTIONS is intended to be extensible, may have a body both in request and reply (even if it is undefined right now) and is mainly about cummunication options on either the esrver or a specific resource. But what is communication option? In the light of a HTTP URI, which is to me an HTTP view of a more generic object, it is metadata of this particular HTTP view of the resource. Also when you get a representation of the metadata of a resource you only get a facet of it. How the metadata of the HTTP view and the HTTP view of the metadata of this object collide? If they are _clearly_ distinct, then OPTIONS has its use as being part of a subset specific only to HTTP and accessible only via HTTP means. -- Yves Lafon - W3C "Baroula que barouleras, au tiéu toujou t'entourneras."
Received on Wednesday, 19 February 2003 10:51:03 UTC