OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: cql-lite: A specification (and generaliation) of cql-form


Title: cql-lite: A specification (and generaliation) of cql-form

Hi:

I was thinking over the weekend that if we were going to have a queryType of cql-form, say, which would be a strict subset of CQL then we should scope it a little more rigorously.

What I came up with was this:

    * no nested clauses
    * no prefix assignments
    * no modifiers (index, relation, boolean)
    * no sortBy

In fact, this is prescription for a linear CQL without the frills.

I am also minded that this is of more general utility than forms as such, although forms may be the prime motivator for this reduction. And therefore I was wondering if a term such as cql-lite would be more appropriate.

I have attached a document with two BNFs:

    * CQL with modified rules
    * CQL-Lite with collected rules
       
Apart from the obvious changes to remove prefix assignments, modifiers and sortBy, the only rule change was a restriction on 'subquery' to disallow nested queries.

The cql-lite restricted syntax covers all the cql-form requirements, and more, since it also allows for optional index and relation.

I had anyway been wondering if a further extension of the cql-form rules would allow for optional relations (and perhaps indexes). If no relation was specified then default it to '='.

It seems to me that cql-form as I had proposed could perhaps be generalized to cql-lite. That is, we could maybe allow for optional indexes and relations as per CQL (and CQL-Lite).

Another thing I had wondered about was optional booleans. Or at least optional in the form being defaulted to some (declared?) boolean. E.g. if no booleans expressed then by default use AND (or OR, or ...). Now this would seem to be a departure from cql-lite bacause it would require processing.

I haven't really thought this through. I would be in favour of keeping things real simple and just having a single (all purpose) language variant: CQL-Lite. Maybe the optional booleans is a bit too much.

So I guess I would be in favour of having a new queryType of cql-lite which is just an everyday CQL. (And maybe just dispense with the former cql-form notion.)

But there are really two things happening here. One is a language subset for a streamlined linear CQL. The other is for a distributed query syntax. I have to say I don't really know what the respective roles of cql-lite and cql-form are. Is it one and the same thing - or two separate things? Would prefer not to be spawning multiple CQL variants.

Tony


******************************************************************************** 
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is
not the original intended recipient. If you have received this e-mail in error
please inform the sender and delete it from your mailbox or any other storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
liability for any statements made which are clearly the sender's own and not
expressly made on behalf of Macmillan Publishers Limited or one of its agents.
Please note that neither Macmillan Publishers Limited nor any of its agents
accept any responsibility for viruses that may be contained in this e-mail or
its attachments and it is your responsibility to scan the e-mail and
attachments (if any). No contracts may be concluded on behalf of Macmillan
Publishers Limited or its agents by means of e-mail communication. Macmillan
Publishers Limited Registered in England and Wales with registered number 785998
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS 
********************************************************************************

cql-lite.doc



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]