Robert Sanderson wrote:

>>>>If people want 1.1 finished soon, I raise the option of leaving out
>>>>indexes on parenthesis groups for post 1.1 to allow people to think
>>>>
>>>>
>>>Yes please.
>>>
>>>
>
>
>
>>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.

>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.
>
>
LOL.
   dc.title = title no cat
then..

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

>a right answer but to me (who's fairly technical) that answer is not
>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.
>No gain.
>
>
I take it you partner didn't understand Mike's example

title = ((dinosaur and bird) or dinobird)

as well, then..

>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.
>*[1])
>
>... 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).

>(The semantics are understandable, but the idea is to have a useful but
>understandable to novices language.  Describing how to resolve which
>index is in effect is more difficult).
>
>The proposal in my view doesn't gain us anything and loses both
>readability and understandability.
>
>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...

-- Adam

>Rob
>
>1:
>
>And then we need to decide the scope of term describing relation modifiers:
>
> dc.date any/iso.YYYYMMDD ( dc.author =/cql.string "fish" and "20030224" )
> geo.location within/geo.box/geo.pointFormat  ( ... )
>
>Please No!
>
>--
>      ,'/:.          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
>
>
>