RE: Yaron.Redirect.NoRelative

I am not arguing that relative URLs must be banned from everything,
everywhere. I am just asking that relative URL support be removed from the
DAV:RefTarget element used in the MKRESOURCE method.

If there is a scenario where a MKRESOURCE intended to create a redirect
resource cannot properly work without the ability to specify a relative URL
in the DAV:RefTarget XML element then I will withdraw my objection. 

Otherwise, based on K.I.S.S. and my arguments below, we need to pull out
relative URL support in the DAV:RefTarget XML element.

			Yaron

> -----Original Message-----
> From: Clemm, Geoff [mailto:gclemm@Rational.Com]
> Sent: Sun, February 20, 2000 5:54 PM
> To: w3c-dist-auth@w3.org
> Subject: 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 Monday, 21 February 2000 03:19:29 UTC