Robert Sanderson wrote:
>>> Please note that this allows for:
>>> dc.title = (dc.identifier any fish)
>
>
>>> Which to my mind is meaningless and the grammar shouldn't allow it,
>>> but to
>>> Mike's mind is equivalent to just:
>>> dc.identifer any fish
>>
>> Certainly. What else?
>
>
> It's meaningless. It says:
>
> Search for terms in title that are terms in identifier that are fish
What you say is meaningless. Fortunately that's not what it means.
>
>> No. It is also useful when you do
>> my.defaultindex my.defaultop = (q)
>> where q is a sub query. It allows developers or users to supply
>> semantics for _unqualified_ terms - not only the totally useless
>> serverChoice scr.
>
>
> Or ... you just qualify them properly.
> If you know that my.defaultindex exists then you could just put that into
> the slot where the index actually should be.
>
> "serverChoice scr" is not useless, it fills a very real need for
> situations when the agent generating the query does not know the best
> index to search and leaves it to the server to decide.
OK. serverChoice is useful for useless clients:-)
>
>> For example:
>> dc.mydefaultindex any (dc.author = hansen and mankind)
>> which is equivalent to:
>
> ... the much simpler ...
>
>> dc.author = hansen and dc.mydefault.index any mankind
And ((((((a))))))
is more "complex" than
a
and yet we allow it - even if it may seem stupid.
Prefixes for CQL are also unncessary. They do not add semantics.
Everything can be expressed without them.
>> You have rejected the proposal and useful construct a number of times.
>> Don't tell me you don't want fix the defect because it is difficult to
>> implement :-)
>
>
> Nope. I don't want it because it only adds complexity, not power. Adding
> it does not add any new possible queries. Everything could be expressed,
> more easily if sometimes more verbosely, using the existing rules.
Everything could be expressed. Sometimes with great difficulty. A client
that wishes to avoid serverChoice would have to include a built-in CQL
parser and add "mydefaultindex mydefaultop" to all unqualified terms. In
my mind, such "replacement" would require a "real" CQL parser. Simple
substitution won't do.
Interestingly some of you guys want to be able to apply index+relation
to queries in _some_ cases - thereby further adding complexity to the
grammar.
What would XML be like - without scoping and namespaces?
Like this
<ele xmlns="a">
<ele xmlns="a">
<ele xmlns="b"/>
<ele xmlns="a"/>
<ele xmlns="a"/>
<ele xmlns="a"/>
<ele xmlns="a"/>
</ele/>
</ele/>
Instead of this:
<ele xmlns="a">
<ele>
<ele xmlns="b"/>
<ele/>
<ele/>
<ele/>
<ele/>
</ele/>
</ele/>
> It's useful to you because your PQF allows it and hence your server allows
:-)
PQF allows the attributes to be stated everywhere. So either way a
conversion would work CQL->PQF (close-to-term or scoped). So not a
problem for PQF.
PQF, like many other languages and formats has a way to declare things -
using well known scope rules. Nothing new here.
> it. But I struggle to see any situation when it is useful in the real
> world over actually spelling out the clauses properly.
I'll give you a real application quiz:
Extend your XLS stylesheets (SRU) in a way which allows someone to enter
CQL and sends to server a query where unqualified terms are converted to
another default than serverChoice+scr.
Like prefix definitions I see index+relation as _declarations_ that
preceed a (scoped) sub query. If that sub query happens to define or
redefine that, fine.
/ Adam
>
> Rob
>
> ,'/:. Dr Robert Sanderson ([log in to unmask])
> ,'-/::::. http://www.o-r-g.org/~azaroth/
> ,'--/::(@)::. Dept. of Computer Science, Room 805
> ,'---/::::::::::. University of Liverpool
> ____/:::::::::::::. L5R Shop: http://www.cardsnotwords.com/
> I L L U M I N A T I
>
|