W3C home > Mailing lists > Public > www-amaya@w3.org > July to September 2002

Re: URI base resolution and Content-Location

From: Yves Lafon <ylafon@w3.org>
Date: Thu, 12 Sep 2002 16:44:35 +0200 (MET DST)
To: Irene Vatton <Irene.Vatton@inrialpes.fr>
cc: www-amaya@w3.org
Message-ID: <Pine.GSO.4.44.0209121638110.590-100000@tarantula.inria.fr>

On Thu, 12 Sep 2002, Irene Vatton wrote:

> If I resume the suggested change:
> - a relative link from that page should be resolved as relative to the
> Content-Location
>   instead of the current URI.
> - a Save of this page should use the Content-Location.
Yes (as it will make easier the ETag checking also).

> - a link from another page to that page should use also the Content-Location.
The fact that the other page is served with a Content-Location is
If I take your example:

If you want to link http://www.example.com/D2.htm (that has a specific
semantic), the relative link from D1 to D2 should be
../../../../../D2.htm, regardless of the Content-Location of D2, as
http://www.example.com/D2.htm and
http://www.example.com/news/archived/2002/09/09/D2.htm has a different
semantic. So deferencing the targeted resource is not needed and only the
first two points should be implemented. In fact, just one thing needs to
be modified, the computation of the base URI of the document.

> By example a link from http://www.example.com/D1.htm with the Content-Location
> http://www.example.com/news/archived/2002/09/09/D1.htm to another page
> http://www.example.com/D2.htm with the Content-Location
> http://www.example.com/news/archived/2002/09/09/D2.htm
> should generate the relative link "D2.htm"
> In this case, why not forget the actual requested URI.
As explained in another email, the requested URI has a specific semantic
which may be different from the URI in the Content-Location.

Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."
Received on Thursday, 12 September 2002 10:44:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:30:38 UTC