(Sorry to have got to this so late -- fortunately, it turns out that
Rob said nearly everything I would have said.  One or two small
matters remain, though.)

> Date: Tue, 20 Apr 2004 23:44:43 +0200
> From: Martin Malmsten <[log in to unmask]>
>
> > > "A B C" --> [A, B, C]
> > > "\"A B\" C" --> ["A B", C]
> >
> > In CQL?
>
> Yes!

This approach would have been a mistake because it is limited as to
what kinds of term structure it can represent.

Once you make a special case for linear lists, you then face the
problem of how to represent a structure that is (for example) a
polygon outline, a passage of music or a ten-thousand node chemical
formula.  (Don't say that no-one would use these as a search term:
they are all in use in real, live Z39.50 services.  SRW/U's take-up
would be severely limited if it did not support these cases.)

Since we clearly couldn't pre-hoc invent CQL-level syntax for all the
different possible kinds of search-term different application
communities might come up with, we went the other way: search terms
are strings, and the precise interpretation of that string is
controlled by a relation modified (using the obvious defaults so that
this stuff doesn't come into play unless it's needed).  So there is
nothing to stop me defining a qualifier set with relation modifiers
such that the following queries are all equivalent:

        title = "dinosaur"
        title =/silly.termsAreBackwards "ruasonid"
        title =/silly.onlyUseSecondWord "fruit dinosaur bash chicken"
        title =/silly.pigLatin "inosaur-day"
        etc.

The advantage of this approach is that it is arbitrarily extensible by
individual application communities without their needing to get
permission or registration from the core SRW group.

(By the way, that's also a large part of the reason why qualifier-set
prefix mapping is necessary.  So that anyone can make up qualifier set
in a space that they own instead of having to get a central body to
grant them a unique prefix.)

> > > * the "relevant" term funtion
> > > How can the term function order the result set? What happens if two
> > > terms have the "relevant" term function?
> >
> > Then the relevancies are merged, and the resultset re-sorted.
>
> Doesn't that imply that how "relevant" a record is has to do with
> the record only, and not the query?

No, it doesn't imply _anything_ about server-side implementation, and
that's deliberate.  CQL is a transfer syntax for queries.  It
expresses in the abstract what the client wants to search for; and
it's up to the server to implement that in the best way it can.  Do
not underestimate the diversity of IR servers.

That is why CQL contains a lot of stuff that you consider "not
necessary".  No, it's not necessary for your application; maybe not
even for any application that you can imagine.  But for someone,
somewhere, the ability to _express_ that query _is_ necessary.  Even
if no server can't honour the request today, it's still important that
the query can be expressed.

> > Prefixes are useful in the following situation:
> >
> > You have a gateway which sends the same query out to multiple
> > servers, which may or may not use the same default names for
> > context sets.
>
> But what is the probability of this actually happening?

1.

> Everyone is forced to implement it, the CQL looks hideous.

In 99% of cases, you won't need to use an explicit prefix-map in a CQL
query.  Most CQL users could go through their entire lives knowing
nothing of prefix mapping and being none the worse off for it.  If
that's you, then just ignore.  Pick one of the free CQL parsers that's
available and never use its prefix-mapping ability.

But in 1% of cases where it's necessary, it is _totally_ necessary.

> Date: Wed, 21 Apr 2004 00:37:50 +0200
> From: Martin Malmsten <[log in to unmask]>
>
> > One of the reasons behind the SRU variant is to allow thin (also
> > know as dumb or brain-dead) clients.
>
> Well, search+retrieve should be a no-brainer, at least on the client
> side.

Not always.  There is certainly a place for very simple S&R, but many
applications require something much more sophisticated.  We may not
define a protocol or query language that rules those applications
out.  The trick is to define it such that the complex stuff only pokes
its head up when it's actually needed; and I think CQL does a pretty
damned good job of that.

 _/|_    _______________________________________________________________
/o ) \/  Mike Taylor  <[log in to unmask]>  http://www.miketaylor.org.uk
)_v__/\  "Could Marconi have invented the radio if he hadn't by pure
         chance spent years working at the problem?" -- Monty Python's
         Flying Circus.

--
Listen to my wife's new CD of kids' music, _Child's Play_, at
        http://www.pipedreaming.org.uk/childsplay/