Re: RFC 2396 revision issue: Query definition

Al,

I've no argument with what you say.

The URI spec rightly deals with the common ground between client and 
server, and in that there is no need for issues of "URIs are a language for 
building service-variant key expressions" -- you said it:  these are 
service variant.  Also, there's no need to deal with shades of requesters 
intent "to discover resources by their properties than to recover a 
resource by name".

I'm not denying the existence of these other issues, just saying they're 
not needed as a defined part of the protocol between client and server, so 
to make their semantics part of the URI spec is unnecessary complexity.

#g
--

At 11:19 AM 11/14/02 -0500, Al Gilman wrote:

>At 09:25 AM 2002-11-14, Graham Klyne wrote:
>
>>I assumed that the query was semantically indistinguishable from the rest 
>>of the path -- part of what Hrvroje said? -- how they are interpreted is 
>>entirely up to the software the provides access to resources for the 
>>indicated authority.  Anything more, I think, is just a convenient 
>>convention, and not bound to anything fundamental in the nature of form of URI.
>>
>>E.g. I think a web server could legitimately serve *files* with names 
>>(and corresponding URIs) that just happened to contain substrings that 
>>look like URI query elements.
>>
>>Hence, in the general case, reordering of queries must be regarded as 
>>significant (i.e. different URIs), even though some severs may choose to 
>>return values that are invariant under reordering of same.
>
>We have to look at URIs from two sides:
>
>On the client side, it is a nearly-opaque key string.  It has articulable
>parts, at least up to scheme + everythingButTheScheme.  The usage of the
>?query part syntax is consistent [across both http: and mailto: schemes]
>in creating another consistently modal and modally consistent zone in the URI.
>
>On the server side, however, URIs are a language for building service-variant
>key expressions.  Our URI thingie has to work as a language for this
>purpose.  In a sense they're all expressions in a query language.
>
> From the server side view, at least, it is important to note the following
>difference between path segment parameters and the searchPart following the
>'?'.   A path segment parameter is an aside; you can after this assert another
>parameter or come back and assert another path segment.  When you hit the
>'?' you know that there are no more path segments to come.  You can close
>positional association and be assured of named association for the factoids
>that follow.
>
><end of that thread/>
>
>At a yet higher level, it should be realized that from a semantic
>perspective, when one uses a search URL it is more to discover resources by
>their properties than to recover a resource by name.
>
>The properties used here are colloquially-based, not controlled by the
>creator of the units of resource discovered.
>
>The sense of a query is invariant, regardless of whether it is presented to
>Alta Vista or Excite.  Or at least more same than different.  Different
>services may satisfy the query better and worse, but the question is
>essentially the same.
>
>Al
>
>>#g
>>--
>>
>>At 11:34 AM 11/13/02 -0800, Mark Nottingham wrote:
>>
>>>It would be nice if this could be addressed in some fashion. Thanks for
>>>bringing it up, and summarizing the history so nicely (I wasn't aware of
>>>the previous discussion).
>>>
>>>
>>> > My ideas on redefinition: query should be "identifying the resource
>>> > within the scope of that scheme and authority" just as the path is. The
>>> > difference between the components may be in ordering: while the path
>>> > segments must be in strict order (defining the path through a
>>> > hierarchy), query segments may be in arbitrary order, like "parameters"
>>> > or "switches". Information in query segments may also be optional and
>>> > generally more detailed than the path segments [1].
>>>
>>>Those feel like guidelines more than hard semantics; IIRC, the main
>>>distinction between URI path segments and URI parameters is that
>>>parameters aren't ordered, so that aspect doesn't distinguish queries.
>>>
>>>Perhaps what does distinguish queries is that while they are used in
>>>identifying the resource, they aren't used directly in
>>>locating/dereferencing it; just as fragment identifier semantics are
>>>interpreted on the client side in the scope of the resource's
>>>representation, so queries are interpreted on the server side in the scope
>>>of the located resource (which may be a new concept).
>>>
>>>I haven't worked through the ramifications of this; just food for thought.
>>
>>-------------------
>>Graham Klyne
>><GK@NineByNine.org>
>
>-------------------
>Graham Klyne
><GK@NineByNine.org>

Received on Thursday, 14 November 2002 11:44:15 UTC