>> I think that's exactly what cql.anywhere means.  Search all indexes
>> that you know about, but you can't be expected to search indexes that
>> you don't know about.


> Okay, okay, you're right. I was just being lazy; iterating *all* indexes
> is easier than iterating over all
> CQL-linked indexes. I'll create an adlib.allIndexes index for the
> current behaviour, and program cql.anywhere
> like it should be.

So adlib.allIndexes will search all indexes in the adlib context-set, yes?


>> We actually started this process a month or two back, but got
>> sidetracks -- or maybe mired in excess complexity.
> Are there any concrete results from that discussion, or was it just
> that: a discussion?

Nothing concrete, I think Mike's comment about being mired in complexity
is a good summary of why it fell down.

>>> - The 'encloses' and 'within' operators are implemented using the
>>>   Adlib WHEN operator. Some examples:

>> dc.date within "2000 2004"
>> -> Does the record contain a date between (inclusive) 2000 and 2004

> I'll add a modifier: within/adlib.range=exclusive (or inclusive -
> default, rightexclusive, leftexclusive).
> Makes everybody happy, right? ;-)

If you think that your customers will use the modifier, then go right
ahead :)  (I find it easier to just change the dates by one)

>> foo.rangeOfDates encloses 2002
>> -> Does 2002 fall within (inclusive) the date range in the record.
>> <record>
>>  <dateRange>2000 2004</dateRange>
>> </record>
>> would match the encloses query.

> No they don't. I'm a bit confused now about encloses works. In the
> manual they're not really well defined, if I may say so. If encloses
> specifically needs a two-dimensional index and a single search term,
> Adlib can't support it. But Mike's example (the one which results in the
> empty set) seems to suggest otherwise..

Encloses needs an n dimensional index.  You could also say that a point in
space is enclosed in a volume, or time/space if you want 4 dimensions.

I think Mike's examples were due to not understanding the WHEN operator
exactly, but he at least agreed with my examples.
(Which is good, because I propsed the within and encloses distinction
originally)

> So it's perfectly possible to have a cql.word indexed title, and no
> cql.string index available for the same field.

Right.  It'd be very strange to have a string indexed dc.description, for
example.

> semantics, but then I'd have to throw an error message on every query
> that makes me imply cql.string where the index is actually word, and
> vice versa..

That's exactly what it should do.

> And there's no way to report the index type in a ZeeRex record. I
> already asked our customer whether this is a problem for them but didn't
> hear back from them yet.

You can include a configInfo section within the index, and give the
relations and/or relation modifiers that are available.

This lets you say that you support within for dc.date, but only cql.word
for dc.description.

For example, check out the indexes in:

http://srw.cheshire3.org/services/l5r


> I've extended the profile with a new concept: a prox implementation, as
> far as Adlib can implement it. I'm very curious if any of you can accept
> me defining it the way I did :-) Adlib can't support any of the prox
> functionality as described in the CQL context set..

(Goes to read attachment)

> Then there's still one option question about CQL context set modifiers:
> how do I type check number & isoDate searches? I can either infer those

In my opinion you can determine the structure of the term as you wish,
unless the client has specifically told you the structure to use with a
relation modifier.

   dc.date > "2004-12-25"
is a perfectly obvious query without any further tokens.

   dc.title > "Jaws!"
on the other hand is not obvious (string or word?), but you can still
determine it as you wish.  If the client wanted a string style comparison,
then it should have asked for it specifically.

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