Re: Is this use of BASE kosher?

Daniel W. Connolly (connolly@beach.w3.org)
Wed, 2 Aug 95 20:30:47 EDT

In message <9508022332.AA04749@horizon.math.utah.edu>, Paul Burchard writes:
>"Daniel W. Connolly" <connolly@beach.w3.org>
>> On seeing a <base href="http://here/"> element, the
>> user agent treats http://here/ as the address of that
>> document; hence references to http://here/#fragment
>> _are_ references to the current document.
>
>Well, that's what the simplified summary in the HTML spec says --
>but unfortunately it's wrong according to the more general model of
>relative URLs presented in RFC 1808.

How is it wrong? How is what I've said different from what
you've said below?

>For good reason, RFC 1808 makes *no* requirement that a document
>containing relative URLs be retrievable via *any* URL, much less its
>"base URL". The "base URL", by definition, serves strictly as a
>device for resolving relative URLs imbedded in the document. The
>examples in the RFC amply show the need for this more flexible
>approach.

>It's true that the most common case in Web practice is a document
>obtained via an idempotent URL, having no explicitly specified base
>URL. In that case, yes, retrieval of the base URL is guaranteed to
>yield the same object

"same object"? strange phrasing. In my book, object=resource, and
they're the same if they have the same address/URL/URI, by definition.
"Same entity?" is a more precise question, but the answer depends on
whether the document changes over time etc.

> as that in which the relative URLs are being
>resolved, and the HTML spec's "optimization" of "#name" is correct.
>But otherwise not.

Who said anything about "retrieval of the base URL is guaranteed ..."?
All I said is that the <base> markup provides the base URL used
to turn relative references (including "#name") into absolute URLs.

The point is that you don't _need_ to retrieve a representation of the
resource identified by the base URL: you've already got it!

Dan