> >>What are people afraid of? Is it difficult to implement? Difficult to
> >>understand? Difficult to describe?
> >Yes to all of the above.

> >dc.title = ( dc.author = fish )
> >I see no reason to make that legal as dc.title is just a waste of time,
> >making the query less readable for no gain.

> You don't like the notion of default index. I see.

If it's a protocol language:  The few bytes saved are not worth the
   expense.

If it's not a protocol language:  The human readablity/understandability
   expense is not worth it either.


> >dc.title = (fish or cat)

> >I see no reason to make that legal either, as we can do:
> >    dc.title any "fish cat"
> >and have the same result for no gain.

>    dc.title = title no cat
> then..

'not' can't be expressed in a single relation, correct, but the other
three booleans can. Gain is very very small.  The same style of argument
applies to a unary not operator, which we also don't have.
(not title = cat)

To express (not title = cat), we need to fall back to ridiculous
expressions like:
  myset.matchesEverything=1 not title = cat

Unary not: a) is understandable b) is simple and intuitive c) adds to the
expressive power of the language as a whole.

But we don't have it.  I put forwards that Unary not is a better candidate
for inclusion than CQL structured search terms.  I'm not saying we should
have it, I'm saying that we've rejected it /and/ it's a better candidate
for inclusion.

> >dc.title = (dc.author any fish or cat)
> >Is just ugly.  Is cat searched in author or title?  Yes, I'm sure there's

> I can't believe you don't know the scope of dc.author in the query
> above. Does that mean you wouldn't whether 'cat' is author search below?
>    dc.author any fish or cat
> If yes (you're in doubt), then words fail me.

author scopes only its own searchClause, title scopes cat.
My point was that just quickly looking at it, it's hard to see the right
answer and would be much worse in a long query.  For someone new, it's
not obvious, especially as prefixes bind more tightly:

  >foo=baz foo.title = (>foo=bar foo.title = bar or foo.title = bar)

Yes it's understandable, but complex for no real gain.

> >readily apparent.  To my partner (who's not technical at all, but
> >understood Mike's CQL tutorial in one reading) it would be totally opaque.

> I take it you partner didn't understand Mike's example
> title = ((dinosaur and bird) or dinobird)
> as well, then..

I told her to ignore it as it's not official CQL, but she probably
understood it. With no other indexes then it's understandable, it's when
you add the new indexes, relation modifiers and such like that it becomes
complicated.


> >It's harder to implement ...
> >(you need to constantly check the type of 'term' when processing and
> >resolve clauses/booleans/strings, rather than knowing they'll be strings.
> >And then we need to decide the scope of term describing relation modifiers:

> > dc.date any/iso.YYYYMMDD ( dc.author = "fish" and "20030224" )
> > geo.location within/geo.box/geo.pointFormat  ( ... )

You agree, I take it?


> >... harder to understand ...
> >(try describing dc.title = dc.author = fish to someone who's not
> >technically inclined, rather than dc.author = fish and seeing which they
> >grasp)
> >... and harder to describe ...

> I'm sure Mike will give it a try! Again, the fact that some queries are
> difficult to read is not an excuse for limiting the ease of use for
> building end-user interfaces (which will collect information from
> various entries and build resulting CQL queries).


I don't buy it.  Most interfaces will need some term processing or user
education.  Apart from index = (a not b), everything else can be expressed
in a single searchClause anyway.  Constructing queries is easier than
understanding the rules, IMO!  One right way to do things, not many.


> >I don't mind if Indexdata's parsers implement it, but I am not going to
> >try and describe why such queries should be legal to end users of CQL,
> >who are supposed to be not technical people.

> Which (again) puts us to the issue for CQL. I thought it was a protocol
> language rather than an end-user language. It is a language that aim for
> easy_implementation_ of end-user interfaces...

I thought it was a protocol /and/ end user language:

"CQL's goal is to combine the simplicity and intuitiveness of google
searching with the expressive power of the Z39.50 Type-1 query."

This is not simple, nor intuitive, nor does it add any expression
which couldn't previously have been described. Unary Not would better fill
all of these goals, but has been rejected in the past.

Rob

--
      ,'/:.          Dr Robert Sanderson ([log in to unmask])
    ,'-/::::.        http://www.o-r-g.org/~azaroth/
  ,'--/::(@)::.      Special Collections and Archives, extension 3142
,'---/::::::::::.    Nebmedes:  http://nebmedes.o-r-g.org:8000/
____/:::::::::::::.
I L L U M I N A T I