[OASIS Issue Tracker] Issue Comment Edited: (ODATA-3) Use CQL standard for query instead of odata-specific filter query protocol

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/ODATA-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=30910#action_30910 ] 

Farrukh Najmi edited comment on ODATA-3 at 8/8/12 8:55 AM:
-----------------------------------------------------------

Having looked at the specification at:

[1] http://www.odata.org/media/30002/OData.html#thefiltersystemqueryoption
[2] http://www.odata.org/documentation/uri-conventions#FilterSystemQueryOption

I have learned that ODATA queries indeed do support boolean predicates which was not clear from examples in OData Overview 2012-7-26.pptx file.

Having looked at the spec the ODATA core query syntax seems quite similar in functionality to CQL. Some observation in comparing the  ODATA query syntax with CQL follow:

 * ODATA is a superset of core CQL functionality
 * Additional features include functions that offer more than CQL relations, collection navigation, geospatial support
 * CQL takes a more layered approach where different contexts add additional capabilities where as ODATA query seems to be more flat and monolithic. 
 * ODATA may consider scopying functions and other parts of the query syntax so that profiles may defined extensions that are scoped by the profile (perhaps this is already the case but was not obvious)
 * ODATA syntax uses tokens such as "gt", "le" instead of more natural tokens such as "> "<=". The rationale seems to be that this is better suited for URLs. However, it seems that url endcoding can address that concern
 * ODATA spatial and temporal aspects MUST be aligned with OGC's GML and related standards. TODO comment suggest this is already in the plans

In summary, my big concern (lack of predicate support) is unfounded. My secondary concern over Yet Another Query Language (YAQL), or ODATA cannot profile existing CQL, remains an open question in my mind. I suggest the TC consider this before making a final decision on this issue.

My thanks to Ralf for his kind help in pointing me to the relevant spec documents and for sharing his insights.



      was (Author: farrukh):
    Having looked at the specification at:

[1] http://www.odata.org/media/30002/OData.html#thefiltersystemqueryoption
[2] http://www.odata.org/documentation/uri-conventions#FilterSystemQueryOption

I have learned that ODATA queries indeed do support boolean predicates which was not clear from examples in OData Overview 2012-7-26.pptx file.

Having looked at the spec the ODATA core query syntax seems quite similar in functionality to CQL. Some observation in comparing the  ODATA query syntax with CQL follow:

 * ODATA is a superset of core CQL functionality
 * Additional features include functions that offer more than CQL relations, collection navigation, geospatial support
 * CQL takes a more layered approach where different contexts add additional capabilities where as ODATA query seems to be more flat and monolithic
 * ODATA syntax uses tokens such as "gt", "le" instead of more natural tokens such as "> "<=". The rationale seems to be that this is better suited for URLs. However, it seems that url endcoding can address that concern
 * ODATA spatial and temporal aspects MUST be aligned with OGC's GML and related standards. TODO comment suggest this is already in the plans

In summary, my big concern (lack of predicate support) is unfounded. My secondary concern over Yet Another Query Language (YAQL), or ODATA cannot profile existing CQL, remains an open question in my mind. I suggest the TC consider this before making a final decision on this issue.

My thanks to Ralf for his kind help in pointing me to the relevant spec documents and for sharing his insights.


  
> Use CQL standard for query instead of odata-specific filter query protocol
> --------------------------------------------------------------------------
>
>                 Key: ODATA-3
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-3
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData Protocol v1.0
>    Affects Versions: WD01
>            Reporter: Farrukh Najmi
>
> Currently ODATA defines query protocol that uses query path and options to specify desired data using a filter based approach:
> The following is the example to fetch all movie names in a movie catalog that match the genre 'Adventure'
> GET /v2/Catalog/Genres('Adventure')/Name HTTP/1.1
> The current approach seems to have several limitations:
>  * It cannot do boolean operations to for example match genres of 'Humor' AND  'Adventure'
>  * It creates a strong linkage between a logical schema and a physical schema and exposes this to the query client
>  * It requires too much knowledge on part of the query client and seems complex to use
> An alternative may be to use the Contextual Query Language or CQL [SearchRetrievePt5]. CQL has been around for many years and is in use in diverse communities to provide interoperable access to various data stores.
> CQL provides much simpler more intuitive syntax that does not have the restrictions noted above. Here is a simple example of a complex query for a fictitious MovieCatalog context:
> movie.genre = "history" AND movie.year > 1980 AND movie.year < 1982 AND movie.actor = "*Quinn*"
> It seems easily possible to define a CQL profile for ODATA that would specify how CQL queries are invoked as part of an ODATA RESTFul query. 
> The following is a possible way to express this CQL query in a RESTFUL GET:
> GET /v2/Catalog/search?query=movie.genre = "history" AND movie.year > 1980 AND movie.year < 1982 AND movie.actor = "*Quinn*" HTTP/1.1
> Note above query is shown without the required url encoding for convenience.
> The result would be:
>  * a more functional query protocol
>  * based on existing OASIS specification with established use in several communities
>  * easier syntax for query client
>  * Easier to map to existing data stores with less hardwiring between logical and physical schema
> Some additional points are:
>  * Get by ID does not get impacted
>  * Will need to define a odata context for CQL
>  * ODATA context will define ODATA specific indexes, relations, relation modifiers (options/parameters) etc. to support odata specific features such as functions, operators, granularity of data returned etc. 
> [SearchRetrievePt5]
> searchRetrieve: Part 5. CQL: The Contextual Query Language Version 1.0. 13 April 2012. OASIS Committee Specification 01. http://docs.oasis-open.org/search-ws/searchRetrieve/v1.0/cs01/part5-cql/searchRetrieve-v1.0-cs01-part5-cql.html.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira