W3C home > Mailing lists > Public > public-iri@w3.org > July 2011

Re: parsing URI (references) according to RFC 3986

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 11 Jul 2011 12:29:21 -0400
Message-ID: <4E1B24E1.7040605@mit.edu>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
CC: public-iri@w3.org
On 7/3/11 2:53 PM, Bjoern Hoehrmann wrote:
>    <!-- document at http://org.example.org -->
>    <base href='http://com.example.com'>
>    <p><a href='http://org.example.org#x'>...</a>
>    <p><a href='http://com.example.com#x'>...</a>
>    <p><a href='#x'>...</a>
>
> If you click the second link so the browser dereferences the URL for a
> retrieval action, and uses the address in the base element as base for
> that purpose, then it would find this to be a same-document reference.
> The first link is different from the base, so it's not a same-document
> reference. The third link would be made absolute using the base element
> so it's like the second link.
>
> Browsers do it the other way around.

Indeed, that was precisely the content of my initial comments in this 
thread.

> For this particular example we could say that you decide whether a re-
> ference is a same-document reference using the document's base address,
> and the base element modifies something like each element's base and
> when resolving something you first make references absolute with the
> element's base and then resolve it using the document's base.

That's an option, yes.  In fact, in some browsers this was in fact how 
it worked historically, when multiple <base> tags were involved....

> Where would that leave us then, though? What's desired is that we know
> for each address that may be relative how to make it absolute and how to
> tell, keeping that model, whether it's a same-document reference (maybe
> we need to have same-fragment references instead?) and we want to spend
> as little effort as possible on providing such definitions explicitly.

Agreed on all counts.

-Boris
Received on Monday, 11 July 2011 16:29:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:14:42 UTC