Re: RFC 2396 revision issue: Query definition

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>

Received on Thursday, 14 November 2002 11:19:56 UTC