Date: Wed, 9 Mar 94 21:07:35 CST
Message-Id: <9403100307.AA15523@boombox.micro.umn.edu>
From: "Mark P. McCahill" <mpm@boombox.micro.umn.edu>
To: hoymand@joe.uwex.edu, timbl@www0.cern.ch, uri@bunyip.com
Subject: Re: The use of "?" in URLs
In message <9403092241.AA13129@joe.uwex.edu> Dirk Herr-Hoyman writes:
> At 4:16 AM 3/9/94 -0600, Mark P. McCahill wrote:
> >In message <9403091022.AA08523@ptpc00.cern.ch> writes:
> >
> >I think we are left with deciding if "?" should be mandated as the seperator
> >for search terms across all URLs. I can live with whateve the consensus for
> >this is...
> >
> >...but, I'm trying to figure out how this would work with a URL for an SQL
> >database server. Presumably, you would want to allow the user to enter
> >search terms for several fields in the SQL database. Would that imply that
> >you use "?" many times within the URL? How would you denote the field names
> >for each of the fields that the user might enter n search terms for? I'm
> >having a hard time seeing how the "?" convention Tim is talking about will
> >work with a URL pointing to a relational database; but an SQL URL is
> >something that would be nice to accomodate without breaking the general
> >mandates of seperator formats for URLs.
> >
> In the HTML+ spec (28-oct-93, pp 34) I see a URL used to fill out forms.
> The search part looks like
>
> ?name.x=2&name.y=29
>
> This might work.
The trouble with syntax arguments is that there are lots of ways of expressing
the same thing... and while a generalized syntax is seductive, it is also a
sure way to get into trouble in the long term.
If I underestand your example, the "&" is used as a seperator between fields
after the initial "?" (the seperator for the search terms). The arguments for
requiring all URLs to use "?" as a search term seperator looks even less
attractive in light of the HTML+ use of this syntax, because smart clients
have to know that
What follows the "?" are the search words that a user entered
UNLESS
There is an "&" somewhere after the "?", in which case what
follows the "?" is in the form field_name = search_terms
These two cases will require different handling in the client, so Tim's
suggestion that smart client will let the user enter their own search terms
looks problematic unless the clients know about both forms of the "?" search
syntax. Alas, the HTML+ form isn't mentioned in the draft URL document... so
how is a client writer to know that they may have to handle two different
cases?
Since the client is going to have to know in detail how to retrieve items
using the access method, it is simplest to treat the parameter package for a
given access method as something opaque and private to the access method...
in which case it doesn't make sense to require the same seperator characters
across access methods.
> In fact, won't we need something like this for ASK+
> blocks?
>
I guess I should add another example to the gopher section of the URL to
make it explicit how this is handled. I'll post yet another revision of the
gopher serction of the URL... but I won't try to mandate that other
services that need to have multiple fields for searches use the same syntax
as Gopher+ URLs uses. It is simply not going to be possible to have a single
syntax for searches for all possible internet searches.
> I have seen some more complex syntax being thrown around on the Z39.50
> list, but I'm not up to speed on it. Could someone in the know, like John
> Curran, comment on whether there might be something there we could use?
>
Lots of folks are going to need a way to specify fields, but how they do it
should not necessarily be the same. It is not a good idea to mandate the same
structure for the parameter package for different types of URLs... among other
things, if you get the mandated structure wrong, all the URLs will that use
the structure have to be changed to the new, improved structure. It is also
hard to predict what sorts of parameter packages you will need for services
that have not yet been defined, so it is easy to get it wrong.
SUMMARY:
A couple arguments have been advanced to support the idea to "?"
as a seperator for all URLs that support search terms:
1.) This is the way we been doing it so far...
Counter argument:
We haven't created enough URLs to be sure this syntax is going to work in all
cases; it is dangerous to extrapolate from our limited experience.
2.) We can easily map from one service to another since the services have
a common syntax for referring to searches...
Counter argument:
You could do the same mapping (where it makes sence) by converting between
the private syntax of various access methods.
3.) Using the same syntax for searches across different services makes it
easier for the smart client to know when the URL refers to a search.
Counter argument:
The client still has to know the details of how to dereference the URL,
and unless we are really careful, clients can misinterpret search URLs
as we find we need a richer syntax. The HTML+ forms example illustrates
this.
4.) Maybe we can twist the "?" syntax to accomodate searches that need to
specify multiple fields for searches
Counter argument:
If we don't define all variants of the twisted "?" syntax, clients are
going to misinterpret new versions of the URL. We don't know enough to
define a universal search synatx at this point, so enforcing a common
search syntax on all URLs will probably lead to broken clients.
I'm finding it hard to get excited about requiring all URLs to use "?"
seperators for search terms.
Mark P. McCahill
gopherspace engineer/University of Minnesota
mpm@boombox.micro.umn.edu
612 625 1300 (voice) 612 625 6817 (fax)