RE: Yaron.Redirect.NoRelative

There are many cases where "fixing up the references" is not feasible.
For example, if you are not moving a collection, but rather are creating
an alias for it (e.g. via BIND), then you need references that work
with either of the legal names for the collection.

Since relative references are trivial for a server to implement, and
very useful for many client applications, I believe it is important
for them to be supported.  

Cheers,
Geoff


-----Original Message-----
From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
Behalf Of Yaron Goland
Sent: Friday, February 11, 2000 2:53 AM
To: 'w3c-dist-auth@w3.org'
Subject: Yaron.Redirect.NoRelative


Section 9 of the redirect spec allows for the use of relative URIs in the
reftarget production. Relative URIs are an extremely dangerous feature that
have caused havoc amongst system implementers. Even so, in many
circumstances they offer such a high value that the problems they cause are
worth dealing with. I do not believe that this is one of those
circumstances.
The primary (and in my opinion only) utility for relative URIs is to allow
humans to type in relative URIs so that they can create links and documents
without having to specify their final location. For example, a web site
designer can use Notepad to type in the links for their web page using
relative URLs. That way the web site designer can test out the site in their
test location and not have to go through and change all the links when they
move it to their final destination.
This exact functionality could, of course, be implemented automatically. For
example, Microsoft FrontPage is able to check Office and HTML documents and
identify their links. If an Office or HTML document is moved then FrontPage
will automatically check all the links, see if the move breaks any of them
and if so it will automatically fix them.
Hence the utility of relative URIs is mainly that it saves some humans in
some cases some work. That is, it was easier to implement relative URIs then
to enable all servers to read all file formats and be able to fix links.
There is a second benefit to relative URIs that apply uniquely to protocols
- they save bytes. If one is returning a large number of links that are all
relative to some base one can save bytes by returning the URIs in a relative
form.
The downside to relative URIs is figuring out what the base is. HTTP
provides at least two different mechanisms including the request-URI and the
content-base header. Various data formats then provide their own solutions.
Both HTML and XML have proposals/implementations for what the base should
be. The rules for figuring out the base are complex and rarely implemented
consistently. As the PM for WinInet dealing with the subtleties of relative
URIs was one of the banes of my experience.
What is especially bad is the conflict. If a request has a content-base
header and a base specification in the HTML in the request which one is to
be used? There are rules for figuring this out but they are rarely properly
implemented.
The end result of the confusion is that it is best to avoid relative URIs
whenever possible. 
In the case of WebDAV the human benefits for the use of relative URIs are
obviously irrelevant. Therefore the only argument for the use of relative
URIs is that they save bytes. However given that we are using XML the
bandwidth taken by the URIs is the absolutely least of our problems. As such
when choosing between a simple, easy to process rule "the URI is always
absolute" and a rule that introduces additional complexity for little
benefit "the URI is relative", we should clearly come down on the side of
simplicity.
Therefore I move that relative URIs be removed from protocol elements in the
redirect spec and that section 9 be deleted in its entirety.

Received on Sunday, 20 February 2000 21:06:24 UTC