>>>> [log in to unmask] 30-05-02 14:26 >>>
>You can do the same thing with a result set that you can with other terms.
>(dog or resultSet=1) and (cat or resultSet=2).
I do not think all operations will be allowed on resultsets and you cannot use the above in a distributed query (which is for me very important). Of course the software will be able to deal with these kind of contructions, but I do not see the advantages. It does not increase functionality (the client can reconstruct a new query itself) and it could introduce a potential interoperability problem (not all servers do have to support it)
Maybe it is a matter of taste, but if it is agreed to do it this way, we will implement it this way.
> -----Original Message-----
> From: Theo van Veen [mailto:[log in to unmask]]
> Sent: Thursday, May 30, 2002 8:21 AM
> To: [log in to unmask]
> Subject: Betr.: revised bnf for cql
> This looks looks fine to me. I have one remark, that I
> mentioned earlier but I do not know to what extent that was
> agreement or not.
> I wonder whether it wouldn't be better to leave out the
> result-set out of the query completely and use this as a
> separate parameter in the request because the resultset is
> completely different from indexes. When the resultset is
> being used in a query, the server has to reconstruct the
> complete query anyway. It gives the false idee that you can
> do the same things with a resultset as you can with the other
> indexes. Especially in distributed searching it would be
> nicer when queries to different servers can be identical and
> do not contain elements that are so server specific.
> >>> [log in to unmask] 29-05-02 20:20 >>>
> I've (re-)written bnf for CQL based on recent
> Not that the discussion has been all that useful
> in trying to figure out what people really want
> but it's time to focus on stabalizing this. I've
> put it up at
> This is based on Alan's proposal as well as
> Ralph's earlier work, and the recent discussion.
> Officially, this is the current state of CQL, so
> if there are specifics of this draft that you
> don't like, I'll change it, if you send concrete
> suggestions. It's time to force the issue and
> find out how close we are to some consensus.