> This approach would have been a mistake because it is limited as to
> what kinds of term structure it can represent.
I did not say that it should replace every type of structure. Just lists
of words since they are used by the "all" and "any" relations.

> 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.)
A special case for linear lists would not remove the ability to support
any of these.

> 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.
I have no problem at all with this. It's very nice, which is why I
thought that a modifier would be better than the "^"-character.

> > > > * 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.
Well it does. If the "relevance" of a record is static, it can be
resorted into another result set. If it depends on the query it can not.

> CQL is a transfer syntax for queries. It expresses in the abstract what
>the client wants to search for [...]
And sorting obviously.

> 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.
I haven't said anything about limiting the expressiveness of the
language. I think that some parts are redundant and I think that some
parts could be made more explicit.

> > > 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.
Ok, I was not asking about the probability of gateways sending queries
to multiple servers. What I meant was this: what is the probability of
the prefix "dc" changing from "dublin core" to "dark custard" when a
client is using a cached explain-record. I have nothing against
*prefixes*, I'm talking about explicitly defining what "dc" means in the
query, instead of just using the definition in the explain record.

> 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.
I'm not a user, I'm an implementor, which means that I have to implement
prefix maps.

Assuming that people will use toolkits is dangerous. Yes it allows the
standard to evolve without everyone having to implement all of it. But
it also allows the standard to slowly get more and more complicated
until no one is interested in implementing it.

There are great toolkits for Z39.50 ... ;)

> > 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.
Ofcourse not.

> The trick is to define it such that the complex stuff only pokes
> its head up when it's actually needed;
I totally agree.

> and I think CQL does a pretty damned good job of that.
I somewhat agree.

Sorry for all the whining, you've all done a great job. Really.

Regards,
  Martin