On Tue, May 21, 2002 at 12:39:49PM +0200, Theo van Veen wrote:
> I am still confused.
> - I remember discussions on the use of quotes but I do not remember
> decisions to move CQL towards CCL.

I cannot remember if a "decision" was officially reached or not (to me,
Ray's web pages are the master copy), but I think it was Ralph that
suggested it and I certainly agreed with the idea of "if we have
exactly the same semantics as CCL, and the CCL syntax is fine, why
not use the CCL syntax instead." If there is a good reason not to
use the CCL syntax, I agree completely we should use a different syntax.

> - In CCL I think we have the same problems with respect to word like
> "and" and "or".

Yes, absolutely. Ignoring CCL, my point was if "and" and "or" are
reserved words in CQL, then they need to be released somehow. Using
quotes seems a logical solution. Feel free to propose other semantics
for what different punctuation should mean in a CQL query. In fact
I would encourage it! It saves time however if the proposal can be
fairly encompassing. For example 'double-quotes should mean string-attribute'
is not enough. Are "and" and "or" reserved words? If so, how to release
the meaning of reserved words? If its also to use double-quotes, then
I dislike it because it means I can only search for "and" with the
string-attribute specified. (I am using this just as an example.)

> We have the opportunity to make a nice clean start with CQL. Let's
> make use of that. I think that "making things different from CCL" is
> not an issue or an argument in itself, but when we try combine the best
> of all worlds in CQL, there might be arguments to use things from CCL.

I agree completely. I don't want to take CCL verbatim. But if there
are good bits, I agree with Ralph (I think it was Ralph!!) who said
'why not steal CCL syntax where appropriate rather than argue over
whether ':' or '~' or '-' is better to separate the index name from
the term'. I agree with this. Most of the CCL syntax is not horrible,
so to reduce time arguing over which punctuation symbol to use, I am
in favor of stealing syntax from CCL when we like the semantics.
Its also more famililar to people (YAZ has something, OCLC has something,
Z39.58 was noised around a bit, ISO8777 is (was?) a standard, we support
it, etc).

But I agree 100% if we need to do something that CCL does not do, or
if CCL does not do it the way we want, then we don't use that bit of CCL.

> I had hoped on a generic approach with standard index names and
> operations (like truncation, completeness etc.) where all the
> "attribute" variants can be constructed in a logical way instead of
> agreeing on names for each individual "attribute" variant. I favour the
> approach in which the server tries to find the best match between how a
> field is indexed and what variant is asked for.

If you have have a concrete proposal, please make it! Your intensions
sound good, but I have no idea how to implement it. I want a concrete
computer algorithm to turn a CQL query into a RPN query with attribute
lists for sending to a Z39.50 target. If you want a proposal where the
CQL->RPN convertion uses 'best match' rules, then can you please propose
a formal model of the data structures the convertion process needs
and the algorithms for converting a CQL input string into a RPN query
with Z39.50 attribute lists etc using that formal model. Without concrete
proposals we are not going to get anywhere.

I am completely against any proposal that says 'here is the legal
syntax of CQL - a CQL->RPN converter should do whatever is best
to satisfy the users need, where the best way to achive this is up
to the implementor'. Any thing left to a specific implementation is
(in my view) completely counter-productive to any standardisation effort.

Alan
--
Alan Kent (mailto:[log in to unmask], http://www.mds.rmit.edu.au/~ajk/)
Project: TeraText Technical Director, InQuirion Pty Ltd (www.inquirion.com)
Postal: Multimedia Database Systems, RMIT, GPO Box 2476V, Melbourne 3001.
Where: RMIT MDS, Bld 91, Level 3, 110 Victoria St, Carlton 3053, VIC Australia.
Phone: +61 3 9925 4114 Reception: +61 3 9925 4099 Fax: +61 3 9925 4098