To: fielding@avron.ics.uci.edu
In-Reply-To: fielding@avron.ics.uci.edu's message of Fri, 28 Oct 1994 19:45:44 -0700 <94Oct28.194601pdt.2765@golden.parc.xerox.com>
Subject: Re: Relative URL draft 01
From: Larry Masinter <masinter@parc.xerox.com>
Message-Id: <94Oct29.130656pdt.2760@golden.parc.xerox.com>
Date: Sat, 29 Oct 1994 13:06:50 PDT
> A URL is "absolute" if it
> can be interpreted consistently and unambiguously, with global scope,
> independent of any other URL.
I think it is possible for this document not to seem to override or
modify the URL document. In any case, you shouldn't need to have to
redefine what [2] has defined, but merely define something new. Why
don't you just remove this sentence.
> This document describes the syntax and semantics for "relative"
> Uniform Resource Locators (relative URLs):
I think part of the problem is that we're calling these things
'relative URLs', but they're not actually URLs all by themselves.
RRLs?
> a compact representation
> of the location and access method for a resource available via the
> Internet relative to an absolute base URL.
But they aren't really a representation of the location and access
method etc. They're a compact representation of a transformation of
one URL that will yield another, related URL for a related resource.
> A primary use for Uniform Resource Locators is to embed them within
> a document (referred to as the "base" document) for the purpose of
> identifying other Internet-accessible resources.
Whether this is 'a primary use' (how many primary uses are there?),
what's relevant is that this is a common use. It's probably necessary
to explain more concretely the term 'base', if this is intended to be
the definition.
> This is
> particularly true of hypertext documents, where URLs can serve as
> the identifiers for hypertext link destinations.
The referent of 'this' is fuzzy to me, and the truth of it isn't what
you're trying to get at.
I think using "Sometimes URLs are used embedded within a document, to
identify other resources. For example, in hypertext documents, URLs
can be used as the identifiers for hypertext link destinations."
> It is often the case that, where a group or "tree" of documents
> serves a common purpose, the vast majority of URLs within those
> documents point to locations within that tree rather than outside
> of it.
In fact "It is often the case that a group or "tree" of documents have
been constructed to serve a common purpose, and the vast majority of
..."
> Similarly, documents located at a particular Internet site
> are much more likely to refer to other resources at that site than
> to resources at remote sites.
This may be true, but I'm not sure why it is different enough from the
previous case to call it out specially. After all, this introduction
is merely to motivate the need for relative RRLs. Maybe we don't have
to be convinced.
> Absolute URLs contain a great deal of information which may already
> be known from the context of the base document's retrieval,
> including the access scheme, network location, and parts of the
> URL path. In situations where the base URL is well-defined and
> known to the parser (human or machine), it is useful to be able to
> embed a URL reference which inherits that context rather than
> re-specifying it within each instance.
I think you could usefully elide 'to the parser (human or machine)'.
> In addition to the space saved, relative addressing of URLs allows
> document trees to be partially independent of their location and/or
> access scheme.
Surely, the utility of eliding the information is greater than merely
saving space. Rather than limiting the point, why not omit "to the
spaced saved"?
> For instance, if they refer to each other using
> relative URLs, it is possible for a single set of documents to be
> simultaneously accessible and, if hypertext, traversable via each
> of the "file", "http", and "ftp" access schemes. Furthermore,
> document trees can be moved, as a whole, without changing any of
> the embedded URLs.
> Experience within the World-Wide Web has
> demonstrated that the ability to perform relative referencing is
> necessary for the long-term usability of embedded URLs.
I think 'necessary' is a bit strong. I think you've already explained
the utility of allowing relative pointers, and this is just redundant.
>2. Relative URL Syntax
> The syntax for relative URLs is the same as that for absolute URLs
> [2], with the exception that portions of the URL may be missing, and
> certain path components ("." and "..") have a special meaning when
> interpreting a relative URL path.
I think this is misleading. The syntax for relative RLs is not very
much like the syntax for many 'absolute URLs' such as "news:" and
"gopher:" schemes. Rather, relative RLs have a special syntax that
allows their interpretation as a modification of a 'base URL'.
> Although this document does not
> seek to define the overall URL syntax, some discussion of it is
> necessary in order to describe the parsing of relative URLs.
I don't think this is necessary, and gets you into trouble.
> 2.1. URL Syntactic Components
> The relative form relies on a property of the URL syntax that
> certain characters ("/") and certain path segments ("..", ".") have
> a significance reserved for representing a hierarchical space.
I think that "." and ".." as path components (should) have no
significance except in relative RLs. The simplest way to say this is
that relative RLs work in conjunction with base URLs that reserve "/"
for hierarchical components, ";" for object components, and "?" for
query syntax.
(out of time for now... I'll send more later.)