>> 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.
>> <dateRange>2000 2004</dateRange>
>> 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
> 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
> 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 example, check out the indexes in:
> 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
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.
,'/:. Dr Robert Sanderson ([log in to unmask])
,'--/::(@)::. 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