Mandate support for a core set of RQL operators when implemented in a Query API

[andrewbonney]

At present the Query API spec provides a recommended set of operators to implement when using the optional RQL support in the spec. It has been suggested that this is strengthened to be a mandatory set of operators which must be present if RQL support is implemented.

This is being tracked on the AMWA Basecamp but is being recorded here for completeness.

[andrewbonney]

As part of this update it has been noted that the currently suggested 'sort()' operator could cause conflicts with the paging mechanism, causing it to be non-deterministic. This may need adding to the list of operators which are highlighted to explicitly not be implemented.

[andrewbonney]

Should also consider use of 'select()' to reduce the fields returned in cases where clients don't require them, and potentially a form of 'rel()' to search within foreign keys, for example:

/flows?query.rql=rel(senders,matches(transport,urn%3Ax-nmos%3Atransport%3Artp))

[garethsb]

See https://github.com/AMWA-TV/nmos-receiver-capabilities/issues/16 for a demonstration of how RQL can be used to implement a useful range of complex queries based on proposed BCP-004-01 Receiver Capabilities to identify the matching Senders. They require that the Query API implement:

• the appropriate Query API-specific semantics for RQL property names like 'label' and, using the '.' syntax, like 'api.endpoints.host' for querying in objects and arrays (as already recommended in Advanced (RQL) Queries to match the Basic Queries syntax)
• a core set of RQL call-operators including and, or, in, eq, ge, le, count, and rel with the appropriate Query API-specific semantics to use identifier property names like 'flow_id' as relation names (cf. the suggested list of operators in the spec, Advanced (RQL) Queries - Constraints)
• RQL explicitly-typed values for a couple of NMOS types, e.g. rational:30000%2f1001 for 30000/1001