Re: Use of ";" in relative URLs: procedural issue?

Karen R. Sollins (sollins@lcs.mit.edu)
Mon, 3 Feb 1997 16:09:42 -0500


Date: Mon, 3 Feb 1997 16:09:42 -0500
Message-Id: <199702032109.QAA11993@lysithea.lcs.mit.edu>
From: "Karen R. Sollins" <sollins@lcs.mit.edu>
To: masinter@parc.xerox.com
Cc: uri@bunyip.com
In-Reply-To: <97Feb3.082628pdt."241"@palimpsest.parc.xerox.com> (message from
Subject: Re: Use of ";" in relative URLs: procedural issue?

   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