Re: Use of ";" in relative URLs: a way out?

Larry Masinter (masinter@parc.xerox.com)
Tue, 11 Feb 1997 18:53:21 PST


Message-Id: <330130A1.7477@parc.xerox.com>
Date: Tue, 11 Feb 1997 18:53:21 PST
From: Larry Masinter <masinter@parc.xerox.com>
To: "Martin J. Duerst" <mduerst@ifi.unizh.ch>
Cc: uri@bunyip.com
Subject: Re: Use of ";" in relative URLs: a way out?

Martin J. Duerst wrote:
...
> Scaling doesn't have to be that much of an issue because it is not
> the responsibility of the generic syntax to decide whether it can
> be solved in a particular case or not. The main question is whether
> there are cases that can deal with the scaling and where it makes
> sense to have attributes unordered, and whether these cases are
> frequent enough or important enough, and/or don't admit a reasonable
> alternative without unordered attributes to justify adding/keeping
> the unordered attributes in the generic syntax.

I think we've established a long-term design goal that the relative/base
calculation should be uniform and not depend on the scheme at all.
So, you're wrong. It _is_ the responsibility of the generic
syntax to either allow for unordered attributes or not.

I don't understand the 'scaling' issue, though. It is a bit
more code in the relative URL calculation: lots more than the
simple string hacking that is possible now. The cost/benefit
is hard to judge, and there are arguments on both sides.

Another way to handle it would not to require the relative
URL calculation to actually remove duplicates.

If the relative URL starts with a ";" the result could be
merely to append the attributes to the existing URL without
removing any other existing attributes. It is then up to the
individual scheme to decide that duplicates should be eliminated.

E.g., a base

imap://hostport/folderpath/uid=message;section=1.2

conjoined with a relative URL
";section=1.3"

results in a URL of

imap://hostport/folderpath/uid=message;section=1.2;section=1.3

which the IMAP scheme defines to be equivalent to

imap://hostport/folderpath/uid=message;section=1.2;section=1.3

so that the generic syntax doesn't say anything about whether
the attributes are ordered or unordered.