Print

Print


On 3 September 2010 13:49, Tim Williams <[log in to unmask]> wrote:
> On Fri, Sep 3, 2010 at 8:01 AM, Mike Taylor <[log in to unmask]> wrote:
>> No, there is no such validator. �That is because the formal
>> specification of CQL was developed separately from, and subsequent to,
>> the actual implementation. �It also has several bugs in it. �All in
>> all, I would advice ignoring the formal specification completely.
>
> Completely? �What reference should would-be implementors use then -
> surely not reverse-engineering a given implementation? �Personally, I
> find the lack of openness in some of the replies here unsatisfying but
> there needs to be a specification reference somewhere, right?

You're right that there ought to be a good specification that you can
rely on.  The reality is that the three main independent
implementations (YAZ, CQL-Java and Rob Sanderson's Python parser) all
support indexName=(a or (c and d)) -- perhaps because they were
written before the grammar was modified to arbitrarily prohibit this
useful construct, I don't remember the history exactly.  The
subsequent widely-used parsers in Perl and Ruby are both ports of
CQL-Java and so also support this construct.

Since then, the formal specification has been further tinkered with, I
think at least in part by people who've not actually implemented any
version of that specification and who have therefore not been in a
position to verify that the modified grammar expresses what it
intends.  The upshot is that, depending on how you look at it, reality
is out of sync with the spec, or the spec is out of sync with reality.




>
> --tim
>
>> On 3 September 2010 12:48, Ricardo Eito Brun <[log in to unmask]> wrote:
>>> Hi,
>>> Regarding this e-mail, to check the correctness of the queries against the specification, is there any "validator" for CQL queries that could be used to check their correctness backed by OASIS, LOC or similar?
>>>
>>> Thanks in advance,
>>>
>>> Ricardo
>>>
>>> -----Mensaje original-----
>>> De: SRU (Search and Retrieve Via URL) Implementors [mailto:[log in to unmask]] En nombre de Mike Taylor
>>> Enviado el: jueves, 02 de septiembre de 2010 22:18
>>> Para: [log in to unmask]
>>> Asunto: Re: Boolean search within an index
>>>
>>> On 2 September 2010 18:12, Tim Williams <[log in to unmask]> wrote:
>>>> I have this need to support complex boolean queries within a field.
>>>> I'd like to not have to repeat the 'index relation' over and over
>>>> within the statement. �Rather, I'd like something like
>>>>
>>>> � title = ((fish OR turtle) AND sea) - though, much more complex -
>>>> and don't want to have to write:
>>>>
>>>> �((title = fish OR title = turtle) AND title = sea)
>>>>
>>>> Logically, it's just projecting the index and relation upon the
>>>> enclosed terms. �Before we depart from the CQL spec I thought I'd see
>>>> if there was a way to get similar 'shortcutting' using build-in
>>>> extension mechanisms?
>>>
>>> Although the formal specification of CQL stupidly prohibits this
>>> useful and unambiguous syntax, most or maybe all actual
>>> implementations support it -- certainly the C/C++ parser in YAZ,
>>> CQL-Java, the Perl CQL::Parser and thr Ruby gem all do. �Have you
>>> tried just going ahead and doing it? �If it's being rejected, what CQL
>>> parser are you using?
>>>
>>>
>>>>
>>>> Thanks,
>>>> --tim
>>>>
>>>>
>>>
>>> ______________________
>>> This message including any attachments may contain confidential
>>> information, according to our Information Security Management System,
>>> �and intended solely for a specific individual to whom they are addressed.
>>> �Any unauthorised copy, disclosure or distribution of this message
>>> �is strictly forbidden. If you have received this transmission in error,
>>> �please notify the sender immediately and delete it.
>>>
>>> ______________________
>>> Este mensaje, y en su caso, cualquier fichero anexo al mismo,
>>> �puede contener informacion clasificada por su emisor como confidencial
>>> �en el marco de su Sistema de Gestion de Seguridad de la
>>> Informacion siendo para uso exclusivo del destinatario, quedando
>>> prohibida su divulgacion copia o distribucion a terceros sin la
>>> autorizacion expresa del remitente. Si Vd. ha recibido este mensaje
>>> �erroneamente, se ruega lo notifique al remitente y proceda a su borrado.
>>> Gracias por su colaboracion.
>>>
>>> ______________________
>>>
>>>
>>
>
>