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

["Martin J. Duerst" <[e-mail]>]

On Tue, 11 Feb 1997, Larry Masinter wrote:

> 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.

Larry - I think you didn't follow the discussion closely enough.
Karen was worried about unordered attributes posing scalability
problems for resolution. E.g. you have a matrix space spanned
by 10 attributes, of which five are known, and you try to figure
out where the data is that you are looking for.

Now I just said that that's not a problem for URL syntax, that
just because some spaces that might be denoted by unordered
attributes may have such scalability problems should not
lead to the conclusion to disallow unordered attributes,
because some other schemes might be completely happy with
them.

So we are in complete agreement that relative/base calculation
should be uniform (just some of these calculations won't lead
to reasonable URLs for some schemes because some schemes don't
make use of all the features of generic URLs).


> 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.

Scaling is definitely not an issue for the relative URL calculation.


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

It's easy to see that removing duplicates in the URLs is
no big deal. It wouldn't be a big deal even with an average
URL length of 10K.


> 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

Did you want to make this

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

???

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



Regards,	Martin.