>>>> [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).
>
>Ralph

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. 

Theo


> -----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.
>
> Theo
>
>
> >>> [log in to unmask] 29-05-02 20:20 >>>
> I've (re-)written  bnf for CQL based on recent
> discussion.
>
> 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
> http://www.loc.gov/z3950/agency/zing/cql.html 
>
> 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.
>
> --Ray
>