- From: Gavin Thomas Nicol <gtn@rbii.com>
- Date: Fri, 29 Mar 2002 23:13:05 -0500
- To: "'www-tag'" <www-tag@w3.org>
On Wednesday 27 March 2002 07:01 pm, Miles Sabin wrote: > To clarify, are you saying that those bare URIs are ambiguous > (between the text and the image) until supplied with some > disambiguator (eg. an Accept: > header in the online case, metadata in the offline case, some other > formal or informal convention, or the use context)? I think the important thing to realise here is that a request is not simply equivalent to a GET+URI pair. Even for GET, the actual request is a far more complicated thing, including all the Accept headers, and in many cases, headers identifying the client platforms etc. This entire thing is the "closure" of the request. Speaking for myself, I think there is a spectrum of cases that need to be considered vis-a-vis resource to representation mapping. If you request the time, you would expect the representation to vary, even if the entire request was exactly the same as an earlier one. On the other hand, if I ask for /foo.xml, using exactly the same request as I did earlier, I would be most upset to get back an image rather than the previously returned XML file. You could argue that the implied contract here is outside the scope of the architecture, but at some point there is a *need* to represent a given resource with a particular set of bits, if only for reification so you can discuss the properties of that representation. Even in loosely coupled systems, sooner or later *something* has to reliably manage the communication protocol... and you can't do that without constraining types/vocabularies to fit the grammar of the protocol.
Received on Friday, 29 March 2002 23:14:41 UTC