W3C home > Mailing lists > Public > uri@w3.org > November 2002

Re: RFC 2396 revision issue: Query definition

From: Graham Klyne <GK@ninebynine.org>
Date: Thu, 14 Nov 2002 16:33:26 +0000
Message-Id: <5.1.0.14.2.20021114162633.03dd8340@127.0.0.1>
To: Al Gilman <asgilman@iamdigex.net>
Cc: "Mark Nottingham" <mnot@mnot.net>, "Hrvoje Simic" <hrvoje.simic@zg.hinet.hr>, <uri@w3.org>

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:05 UTC