[OASIS Issue Tracker] Commented: (CAMP-42) Spec should say how to limit/specify the scope of returned data

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

    [ http://tools.oasis-open.org/issues/browse/CAMP-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=32236#action_32236 ] 

Jacques Durand  commented on CAMP-42:
-------------------------------------

It seems we are trying to strike a balance between raw query result and its post-processing by a full blown JSON query language such as Jaql.

First, I'd suggest that we also allow for the full-blown option, which means we standardize at minimum the invocation of  known 3rd party languages for post-processing of the initial resulting resource/collection.
E.g.: 
?jaql=<the name of a Jaql pipe definition that would be pre-loaded>
(we could also consider ?jaql={inline Jaql function defining such a pipe} )

As for the intermediate approach described by Alex, I'd only suggest to clearly separate the query parameter(s) that (1) have a filtering function in terms of eliminating some of the collection items, and (2) the query parameter(s) that "project" filtered data in form as a view (add or remove some attributes/values) of each collection item. Our current SelectAttr is doing (2). 

For (1):  instead of:
 ?attributeRegex=a.* (everything matching regex a.*) 
I'd use a unique, more explicit keyword (already used in languages like Jaql and Pig Latin) like:
?filter=regex(...)
and also reuse the "filter" keyword for other filtering:
?filter=a>15

For (2):  instead of:
?attributes=a,b,c
I'd use a unique, more explicit keyword more in line with similar operations offered by above languages like:
?project=a,b,c
or
?generate=a,b,c


> Spec should say how to limit/specify the scope of returned data
> ---------------------------------------------------------------
>
>                 Key: CAMP-42
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-42
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Task
>          Components: Spec
>            Reporter: Alex Heneveld
>            Assignee: Alex Heneveld
>
> Currently the spec only dictates requests whose response is an entire Resource object.  These Resources could be very large however, and it is wasteful for everyone to send the entire object if, as will commonly be the case I expect, the client is only interested in a small piece of the Resource.
> This spec should define how a client can restrict a query to selected items of the Resource.  This should include:
> * filtering: selecting a specific key or restricting to a set of keys
> * pagination: selecting a specific element or range of elements (where a key's value is of type list)

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