Hi all,

> >> Errr, no. To clarify: The adlib context-set contains only the bits
> >> that you would prefix with 'adlib.' in the CQL. So for example,
> >> adlib.allIndexes would NOT search dc.title or net.host, but would
> >> search adlib.foo and adlib.bar
Hmm, but cql.anywhere also searches outside of the CQL context set
(which is very logical,
because the CQL ctx set only defines serverChoice and resultSetId, both
of which don't make any sense
when using cql.anywhere), so the CQL context set seems to be a 'magic'
one. Why aren't I allowed
to define a magic 'adlib' context set? Even if I document that in our
Base Profile?

> > Ah. But how do I define it then, in a way that doesn't 'trample' CQL
?
> 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..
 
> > 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?
From the ZeeRex documentation:

<index>
    <title lang="en">Book Title</title>
    <map><name set="dc">title</name></map>
    <map><name set="bath">title</name></map>
  </index>

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

> > Then why won't you allow me to define the adlib context set as: all
> > indexes the exported database knows (natively)? Seems valid CQL to
me..
> Because a context set is very much like a namespace in XML.
> You can't say that <dc:title> is part of the EAD namespace
> any more than you can say that dc.title is part of the CCG context
set.
I understand that, but cql.anywhere does the same.. I want to extend the
indexes that cql.anywhere searches
with all unexported indexes and define that using adlib.allIndexes or
something. I'd just as easy name it
cql.allIndexes but I don't think extending the CQL context set on my own
is a good idea..

> > If I may say so: CQL defines a lot of (fortunately optional) pretty
> > esoteric stuff like word proximity searches and the prox operator,
and
> > 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}

> The main point of CQL as opposed to most other languages is that it is
abstract.

> You're one of the first non Z39.50 people to come to CQL and
> try to write a profile and then come to the group for comments.
I know, I know, it's my own fault :-)

> We want the first context sets and profiles to be as correct as
possible. Because as was found with Z39.50, it
> doesn't really matter what the specification document says if nobody
implements it like that for whatever
> reasons. If the first big SRW/CQL implementations are simply bad,
then it'll be much much harder to keep the
> standard on track, so we have a large large interest in ensuring
things are correct first time.
That's a good argument indeed. I'll try not to whine anymore ;-)

Best regards,

Hedzer Westra, Systems Developer

Adlib | Information Systems
Reactorweg 291
3542 AD Utrecht
Postbus 1436
3600 BK Maarssen
tel: +31-30-241 1885
www: http://www.adlibsoft.com