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

Re: denotation of http://www.vrc.iastate.edu/magritte.gif

From: Tim Berners-Lee <timbl@w3.org>
Date: Sun, 25 May 2003 18:39:29 +0200
Cc: www-tag@w3.org
To: Reto Bachmann-Gmuer <reto@gmuer.ch>
Message-Id: <745442AC-8ECF-11D7-B84E-000393914268@w3.org>


On Thursday, May 22, 2003, at 22:54 Europe/Budapest, Reto 
Bachmann-Gmuer wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> The document http://www.w3.org/DesignIssues/HTTP-URI has following 
> exercise:
>
>> 2) What does "http://www.vrc.iastate.edu/magritte.gif" identify?
>>
>> (...)
>>    6. A representation as a series of 341632 bits in of a photo of a 
>> painting
>>    7. Validly 4, 5 and 6 but not 1
> According to the document the correct answer is 7
>> 2:7 Note here the web tolerates vagueness along the axis of different 
>> representations of teh same image, but not of semantic level betwen 
>> the image and the pipe.
>
> I'm confused that the URI could identify 6. If the server serving the 
> address is smart enough to return a jpeg insted of gif - if according 
> to the http-accept header my browser is not capable to interpret a gif 
> - - the URI would also identify "A representation as a series of 
> [size-of-jpeg] bits in of a photo of a painting" and the URI is 
> ambiguos.
>
> I think a HTTP-URI should identify a document as the abstract entity 
> that all of the possible result of a http-request represent, that is 
> the document independently of encoding and language.

That is a good way of running a server.  that is what
is represented on our server by the URI without a ".gif".

But it is also very useful to have a URI specifically for the GIF 
version.
So the best is to have both. But use the generic one wherever you can...

tim

> Cheers,
> Reto
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (Darwin)
>
> iD8DBQE+zTkCD1pReGFYfq4RApOMAKCmdlvAAIDJRbVZTybmn0GVLI4UKACgzDnt
> JbOf+nxT4dZ7IyA48VRRpJs=
> =pWZ/
> -----END PGP SIGNATURE-----
>
Received on Monday, 26 May 2003 16:52:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:59 UTC