- From: Karen R. Sollins <sollins@lcs.mit.edu>
- Date: Mon, 3 Feb 1997 16:09:42 -0500
- To: masinter@parc.xerox.com
- Cc: uri@bunyip.com
From: Larry Masinter <masinter@parc.xerox.com> Date: Mon, 3 Feb 1997 07:26:28 PST Sender: owner-uri@bunyip.com Precedence: bulk There is a proposal to change the definition of relative URL processing from that previously defined in RFC 1808 and draft-fielding-url-syntax around processing of relative URLs that start with semicolons: > Semicolons were introduced to allow elements to be specified by name > rather than position, for spaces which were best seen as matrices > rather than trees. In this case it is only sensible for relative > URls which start with ";" to take a set of attribute values which > are different. This implies > 1. attributes can only occur once (unless you have a syntax for > removing a particular occurrence) and > 2. a missed value is equivalent to an unspecified value (so you can > remove an occurrence by setting its value to empty) > 3. attributes are unordered This is quite attractive, and is important for some schemes. No one seems to implement this currently, though, so introducing it at this point seems like we would at least have to start over at "Proposed Standard", and should only do so if the consensus of the community is that this is the right thing to do. So, do you think this is the right thing to do? Larry Let me suggest that if you really want to support unordered attribute sets as names that you look VERY carefully at why this approach was dropped by the CCITT a number of years ago. Instead they brought us X.500, which is ordered attributes. For a variety of reasons they decided that unordered ones were unimplementable in any efficient way, so you should make the case that their arguments are no longer valid, before jumping off this particular cliff. I've always liked the idea, but I've never been convinced that we could overcome the impracticality of it. Karen
Received on Monday, 3 February 1997 16:10:02 UTC