- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Tue, 11 Feb 1997 18:53:21 PST
- To: "Martin J. Duerst" <mduerst@ifi.unizh.ch>
- Cc: uri@bunyip.com
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.
Received on Tuesday, 11 February 1997 21:54:00 UTC