> I've not liked the way the conversation over the last couple of days has
> been going, so I'm happy to see Alan push back towards the middle. I'm
> buried in stuff here and was just too unhappy to reply.
> I want the CQL syntax to be a naively simple as possible, even to the point
> of losing some functionality. (I hope not to, but you need to understand
> where I'm starting from.) I know that the SRW folks will have code between
> their users and CQL and I hear the SRU folks saying the same. But, once
> this stuff is turned loose, there are going to be folks putting up dumb HTML
> forms that poke unmediated queries at our servers and I want them to have a
> chance of working. I also know that there will be programmers hand-crafting
> URLs to poke at us and I don't want to replace the complexity of z39.50 with
> the complexity of CQL. This needs to be a language obvious to idiots.
> I suspect that we're going to have to agree on adding an optional query-type
> parameter so that we can use the appropriate language for the appropriate
> situation. But right now, I want it simple.
> CCL was designed to be the language that end-users got taught to search
> bibliographic utilities. It is simple and embedded, in one form or another,
> in most local library systems. It needs to be our starting place. I've got
> no problem with adding complex syntax to do non-core complex stuff. But I'm
> going to resist tinkering with the base stuff.
But there is no "base stuff". I agree with everything you said but it doesn't
help much. We don't have an unambiguous bnf right now to argue about and I see
this as an urgent problem. It doesn't have to be stable or represent a
consensus, but it should at least be out there. So that I can provide people
(like officials here at LC) with examples strings based on something concrete,
and also so that we can have something concrete to debate.
If you want to quicky write a bnf I'll happily abandon the one I wrote yesterday
and put up yours. The bnf at http://www.loc.gov/z3950/agency/zing/cql.html --
we all appreciate your work in writing it -- but it is badly out of date and
needs to be replaced by one that at least defines the cql string.