>> What you're doing is just what cql.anywhere does -- any index
>> which the database knows about. Right?

> Well, not entirely the same: not all Adlib indexes have to be reflected
> in an SRW index. I would like to add a possibility to search *all*
> indexes, not just all indexes that are exported using SRW..

AHHH! :)  The light dawns.

So your index searches all access points in the database, not all indexes
defined in the CQL mapping for that database.  Yes, you can do this.

So the documentation would be something like:

This index performs all searches available in the underlying
implementation, regardless of whether they are exposed in CQL.


>>> And another question: it's possible (and allowed) to map an index to
>>> more than one context set, right?

>> I don't understand the question?

> This index is reachable using dc.title and bath.title; the title index
> is mapped to more than one context set.

Ahh, yes.
The underlying index is mapped to title indexes in multiple context sets.
They could also be differently named indexes, eg ccg.cardNameString

>>> If I may say so: CQL defines a lot of (fortunately optional) pretty
>>> esoteric stuff like word proximity searches and the prox operator, is
>>> prepared for implementation dependent things like relation modifiers.

>> Esoteric perhaps, but absolutely essential in some disciplines. :)

> \begin{unneccessarily vicious remark} I understand, but indeed only in
> *some disciplines*. Then why did these features end up in the "abstract"
> (using your own words from below) CQL language description?
> \end{unneccessarily vicious remark}

Well, the number of disciplines is actually fairly large.  Anything that
needs to search structure will require proximity searches.  Any sort of
full text search will likely require proximity.  Find me books that have
the words "entity relationship diagram" in them will be a LOT larger than
books that have paragraphs with all those words, but the -record- being
searched is still the book.

For example the ZeeRex context set uses proximity to say:
    Find me servers which support dc.title.

The reason we need proximity here is that there's a context set access
point and a index name access point.  But if you search for set = dc and
index = title, you'll find match dc.creator and heraldry.title.  You need
prox here to say that they both come from one field.

Will most disciplines need boolean modifiers?  Probably not, but aren't
you glad we have them?

CQL is abstract because it is not reliant on the underlying data
representation, unlike XQuery, SQL and most other query languages.


> That's a good argument indeed. I'll try not to whine anymore ;-)

It's all good :)  As EA says,  Challenge Everything.

Rob

       ,'/:.          Dr Robert Sanderson ([log in to unmask])
     ,'-/::::.        http://www.o-r-g.org/~azaroth/
   ,'--/::(@)::.      Dept. of Computer Science, Room 805
,'---/::::::::::.    University of Liverpool
____/:::::::::::::.  L5R Shop: http://www.cardsnotwords.com/
I L L U M I N A T I