Re: URL-Reference / "empty URL" question

Daniel LaLiberte <liberte@ncsa.uiuc.edu> wrote:
> > On Wed, 14 May 1997, Larry Masinter wrote:
> > 
> > >   "the copy of the content that is being viewed now"
> > > 
> > > Let's give it its own URL scheme
> > >    "this:"
> > > where the scheme-specific part of "this:" is
> > > empty.
>
>Doesnt the empty URL "" work just as well?  Experience shows that
>if you have an anchor such as <A HREF="">this document</A> it goes
>to the same document that it is contained in.
>
> > I'm not sure, but I seem to detect in some of the comments
> > in this thread a question as to why there could be a need
> > to move inside a document without every refetching it (from
> > the cache or wherever).
>
>Moving within a document without refetching it is an orthogonal issue,
>I think.  It is closely related to the browsing history issue.

	Yes, that's the point.  HREF="" resolves to the current
document's actual URL (without a fragment, if one was present in
the link via which the request yielding the current document was
made)  HREF="#fragment" is HREF="" + HREF="#fragment" yielding an
absolute URL with the current document's actual URL, not the base
(which may be different), plus the #fragment "instruction" to the
client (not to be included in any request sent to a server, or
conversion to file system specs for retrieval from disk.

	However, most deployed browsers resolve HREF="#fragment"
versus the base.  That needs to be changed.  In most cases the
absolute URL from resolving versus the base also points to a document
with the NAME-ed reference pointed to by the #fragment, so there's
little "backward compatibilty" to worry about if the new URL draft
pushes for this implementation.  The freeware Mosaic and Lynx v2.7
have implemented it, so the "at least two implementations" requirement
is met as well.

	But there's no need to introduce a "this:" or "goldalhistory:"
internal URL concept into this:

	The equivalent of that it has existed since the outset of the
Web via the procedure of comparing the actual URL (without the fragment)
to that of the currently displayed document.  When FORMs came into being,
a comparison of any POST content was made as well.  If, by those checks,
the resolved reference proves to be the currently displayed document,
then the browser simply changes the view as indicated by the fragment
reference, without making another request, or considering any cache
control directives associated with the document:  It's dealing with
"history", not "cache" by virtue of that comparison.

	But the same should apply no matter how the "URL#fragment"
was resolved.  If the URL (plus any POST content) corresponds to
that of the currently displayed document, it's a history/view, not
cache control issue.

	Moreover, if there is POST content and they differ, then
whether or not the resolving was done based on an HREF="#fragment",
they are different on those grounds, and cache control, not just
history/view considerations do apply.

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

Received on Wednesday, 14 May 1997 16:21:43 UTC