On Thu, Sep 26, 2002 at 11:19:53AM -0400, Ray Denenberg wrote:
> I'm in favor of moving forward, quickly,
> with some form of the proposal on the table.
>
> --Ray

I agree - I would rather see a proposal finished that I don't like
than not see a proposal. So feel free to ignore my opinions (or take
them into account but make a decision not in line). I don't think you
will ever get complete consensus.  If it gets things moving, I am happy
for multiple '='-style operators.  I have been convinced CQL is
designed for advanced users. SQL for example is not trivial either.
Humans can enter SQL, but its not for novices.  I think its reasonable
to pitch CQL at the same level.

Overall I think I have also been convinced that the grammar should be
tight and formal (eg: I think I would like quotes around all search
text - you can never omit them). CQL is a search language for experts
and probably computer programmers (people turning other web form
queries into CQL for example), and so would benefit by following standard
programming language style grammars (limited set of reserved words,
aritrary text in string literals). I am also happy with pattern characters
being inside string literals (as previously agreed to) and using \ to
release things. Again this is a common thing done.

Need to decide if reserved words and index names are case sensitive
(dc.title = DC.TITLE = DC.Title?).



I still like the idea of having some sort of extensible notation for
introducing other attribute combinations. Eg: how to do fuzzy matches?
Or a GEO profile search? I am happy for CQL to have a set of operators
hard coded to specific attribute lists ('>', '<=' for example will be,
so happy to allow '=*' or whatever too). But what about other combinations
such as a 'within-region' for GEO? I don't think can have operators defined
for all possible attribute lists, so some extensible scheme would be good.
Eg:

    dc.title = @fuzzy("center")
    dc.title/fuzzy = "center"
    dc.title:fuzzy = "center"

I think someone suggested the ':' notation once before. That is,
an index name followed by zero or more ':modifier's.
Hmmm - should I dare suggest the following? Only have '=' but allow
modifiers for all of the different attributes?

    dc.title:any = "a b c"
    dc.title:any:stem = "a b c"
    dc.title:all = "a b c"
    dc.title:rel = "a b c"     (relevance)
    dc.title:str = "a b c"     (string)
    dc.title:lt = "a b c"
    dc.coverage:boundedby = "12.3 32.4 52.3 90.1"

Better is probably to define '=*'/'=^' whatever to be the same as the
':all' modifier. That is, allow short cuts for common things, but which
are semantically equivalent to a long form. (XPath for example
defines /child::foo to be the same as /foo - common things have
a short hand notation, where there is an equivalent long hand
with some sort of consistent notation - "/ axis :: qname" in the case
of XPath.)



One other area that I wonder if needs clarifying is if I type

    dc.title =^ "a b c"

then do we need to define what makes up a word? For example, is it
white space separated? What about punctuation? How many words in
the following?

    dc.title =^ "a,b!c. e/f;g"

Maybe it does not need clarifying - CQL just sends it through the the
Z39.50 server and the server breaks it into words.
But if any operators where going to generate AND, OR, PROX style Rpn
nodes from one input string, then a definition of a 'word' would have
to be specified. So I guess its better to avoid this and so avoid
the problem altogether. (That is, never require CQL to split one
literal string in a query into multiple strings to send to a server.)
Word breaks are of course even harder in Chinese, Thai, etc.
Hence I believe PROX like operators should be outside of string literals
(which is probably the current intent anyway).

Actually, PROX nodes are at the level of AND and OR arnt they (in the
RPN). So you any probably need to do

    dc.title = "a" PROX dc.title = "b"

(where 'PROX' is whatever the prox operator is.) RPN does allow

    dc.title = "a" PROX dc.contributor = "b"

where the PROX is for example 'ELEMENT'. PROX does not mandate the
attribute lists for terms be the same, so CQL should probably not
mandate this. Sound reasonable.


Alan

ps: Gee, I can ramble on a bit can't I? Sorry.