Re: URL-Reference / "empty URL" question

[Foteos Macrides <[e-mail]>]

Larry Masinter <[e-mail]> wrote:
>>  <A NAME="top">Top<A>
>>  ....
>>  <A NAME=link-1" HREF="http://a.host/a.file.html"    >link one   </A>
>>  <A NAME=link-2" HREF="http://a.host/a.file.html#top">link two   </A>
>>  <A NAME=link-3" HREF="#top"                         >link three </A>
>> 
>
>> (At least with the Lynx code currently under development,) activating
>> ("following") link-1 will result in a new network request.  Activating
>> link-3 will not, but will just change the view of the current document,
>
>> The question is, what happens with link-2 - should following it result
>> in a new request, as for link-1, or just repositioning within the
>> already loaded document as for link-3?
>
>We actually discussed this at length, and came to the design that
>we intended to write, where (as you assert) link-2 is similar to
>link-1 and not link-3, and should cause a new "dereference".
>
>The way I think of this, link 3 doesn't
>doesn't refer to "the resource at the URL of this document" but really
>"my local copy in this here buffer, file://localhost/blah/".
>
>I haven't figured out how to make this any clearer in the draft, though.
>
>> My reading of the draft is that they do not resolve to the same thing,
>> and that implementing things this way (first "resolve" a given
>> URL-Reference into a "full" URL-Reference with a non-empty absolute
>> URL, then do all further processing with that) actually contradicts
>> the draft - although it probably is used by a lot of implementations.
>
>Are you sure? I suppose we need to survey interoperable implementations
>to see.

	It appears that Roy does not have the time to address these
questions which Klaus directed toward him, and I am concerned that
Larry's reply may be a misleadingly affirmative answer about apples,
for a question about oranges.

	In the case where someone has made a local copy of a document
originally accessed via an http URL, and added a:

	<BASE HREF="http://host/foo/blah/original.html">

tag so that partial references in it will be resolved versus the
original http URL for the document, the local copy will be accessed
via a:

	 file://localhost/somewhere/mycopy.html
	 
URL.  If it contains a "lone fragment" reference:

	<A HREF="#top">Return to top of document.</a>

according to the draft it should be resolved as (current document)#top
which in this case is:

	file://localhost/mycopy.html#top
	
When accessing the local copy via a file URL, activating that link will
cause the currently deployed browsers to simply change the "view" of
(current document), a.k.a, file://localhost/mycopy.html, without making
another retrieval.  In contrast, if the "lone fragment" were resolved
versus the base, it would have become:

	http://host/foo/blah/original.html#top

causing the browers to seek the original to make a needless retrieval of:

	http://host/foo/blah/original.html

and on receipt, render it again, and make the view begin at the point
indicated by a <A NAME="top">Top</A> in it.

	That rule to resolve versus (current document) rather than the
base makes good sense in this case, as well as homologous cases in
which the position indicated by the "lone fragment" applies to the
currently displayed document (and most likely also in the document
pointed to by the base, by why get it again simply to change the
"view" rather than the actual document), so I hope this rule will we
adopted by all browers.

	In the case for which the current document is retrieved via an
http URL, there is no file://localhost/... formally associated with it.
The browser may or may not be maintaining a local cache, and if it is,
the local copies would be associated with references based on its cache
access rules in relation to http://host/foo/blah/original.html.  You
would still want to resolve "lone fragments" versus that (current
document) URL, but if there is no BASE nor http header or META
equivalent indicating a different base, you could get the same thing
if a path also were in the partial reference, or if it where an
absolute URL with the fragment appended. 

	Klaus' interpretation (and Larry's seeming affirmation of it)
amounts to the rule that the "lone fragment" should be resolved as:

	(cache reference)#top

not just:

	(current document)#top

and Klaus has added code to keep track of how each reference with a
fragment was resolved, i.e., whether or not if was a "lone fragment"
in the HTML markup, and if so always use that information to bypass any
associated cache directives, rather than bypassing them on the basis
of whether the actual URL (without a fragment) corresponds to that of
the currently displayed document.  I find it very difficult to believe
that Roy intended to take it that far, and doubt that any currently
deployed browser has (aside from the Lynx working code to which Klaus
alluded).

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 [e-mail]         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================