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

> Agreed, except that wasn't the argument. The argument for having it is
> to be able to offer a _subset_ of a CQL query to a mere user. The user

Then we end up with profiled CQL as to which bits each implementation has
to support.  CQL Profile, part A level 0:  Must support searchClauses and
Triples.  Level 1:  Must also support prefixes. ... Urgh.


> is able to enter his/her own query in a text field, but if he/she
> doesn't explicitly enter a field themselves there is no way to direct
> them to a _default_ index.

Why not?  That sounds like an interface design issue, not a protocol one.


> Without a default index you'll have to go through each term in the query
> and add index/relation where omitted, skip booleans, other reserved
> words.. It is extra work for the implementor that CQL could solve so
> elegantly.

Assuming that the default index of the client interface is different from
the default index of the server.  And then at the server end it's extra
work for the server implementor to process, as they will probably have to
go through and add in all the defaulted indexes.

"So Don't Do That Then."

Why would a user enter CQL fragments into a search box which has an index
anyway?  Either have them enter the entire query, or have drop downs for
the index and one term per box.


title: [  dc.author any smith ]

What would possess anyone to do that and expect it to work?



> >Unary not: a) is understandable b) is simple and intuitive c) adds to the
> >expressive power of the language as a whole.
> I didn't mean to start a discussion of unary not, really.
> >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."
> So, since "not" operator is not there, you think indexes shouldn't be
> powerful and flexible. You can do better than that:)

My point is that CQL structured terms are less useful than something which
has been rejected for not being useful enough to include.

> >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.

> The end-user doesn't have to understand the whole thing, but a user _may
> enter Q in p.freetext = Q
> where Q is, say,
>        keyword and author=jensen
> or
>        author=jensen and keyword

They might do that, but they could also enter SQL queries or PQF.  If you
want to have an interface that turns SQL, PQF or CQL fragments into CQL
then be my guest, but I don't see that it's necessary for the protocol to
handle it natively.  What if they meant to search for 'keyword and
author=jensen' as a freetext search term? Still need client side logic and
user education.

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