Re: ERB call on addressing

At 08:09 PM 3/24/97 EST, lee@sq.com wrote:
>Gavin says:
>>    http://foo.com/foo.sgml;XML-PTR=ID(A27)?keyword=foo
>And he's right: don't use # or ? to mean something special in URLS
>when they already have meanings...

Huh?  Read the RFC.  To be precise:


In our proposal, we are using an interpretation of '#' and '?' that 
is 100% consistent with it.  Among other things, both the RFC and
the ERB decision are 100% clear that what follows the '#' or '?' is
NOT part of the URL.  The part after the '?' is called a query 
component, and I quote:

  The query component is a string of information to be interpreted by
  the resource.

And I quote again:

 the optional fragment identifier, separated from
 the URL by a crosshatch ("#") character, consists of additional
 reference information to be interpreted by the user agent after the
 retrieval action has been successfully completed.

Also note from the RFC that the ';' "path parameter" is now a 'path
segment parameter':

 The path may consist of a sequence of path segments separated by a
 single slash "/" character.  Within a path segment, the characters
 "/", ";", "=", and "?" are reserved.  Each path segment may include a
 sequence of parameters, indicated by the semicolon ";" character.
 Extensive testing of current client applications demonstrated that
 the majority of deployed systems do not use the ";" character to
 indicate trailing parameter information, and that the presence of a
 semicolon in a path segment does not affect the relative parsing of
 that segment.  Therefore, parameters have been removed as a separate
 component and may now appear in any path segment. 

I think we ought to buy into the web dogma and treat the URL part
of the URL as opaque; including whatever-they-are parameters.

What we're saying is that we provide *one* semantic, namely here's a URL
and here's an Xptr, a resource and a subresource.  Whether or not we
like it, the web has already laid down the law on the process model
mechanics of '?' and '#' - see above.  We want the linkage semantics
without the process model mechanics.  Since there's nothing like this
now on the Web, new syntax seems the only way to go.

Or am I missing something? -Tim