Sincere apologies for the delayed response – this came in just as I rushed off to the mountains on leave!
In short: you raise a very valid point and I think this is good behaviour which we should clarify is desirable or at least permitted to implementors. Certainly the logic around
AND for different query parameters doesn’t preclude this, and if everyone is in agreement that this is what we want then we can get onto clarifying this in the docs as a matter of priority.
I think the desired behaviour is that
AND is used for different parameters e.g.
taxonomy_id = 1 AND organization_id = XYZ, while
OR is used for requesting values matching values within a specific parameter e.g.
taxonomy_id = 1 OR taxonomy_id = 2. As far as I’m aware, this is fairly standard practice which I would endorse supporting in the HSDS API specification.
Therefore this request:
would return all services with a
1 OR of
2, allowing you to get all four services you list.
When querying across different parameters, each new parameter is basically an
AND clause in the logic. So this request:
would return all services that have an
XYZ AND a
would return all services with an
ABC, AND have a
2. This can also be represented as:
(organization_id == 'XYZ' OR organization_id == 'ABC') AND (taxonomy_id == 1 OR taxonomy_id == 2)
Would this logic work for you?
There are also some unsupported edge-cases here, but I’d need to know more about your concerns as a developer to determine whether they’re pertinent or not. The functionality outlined above would basically be the limits of the logic in this syntax, and it’d be difficult or impossible to construct more complex boolean requirements e.g.
(organization_id == 'XYZ' AND taxonomy_id == 1) OR (organization_id == 'ABC' AND taxonomy_id = 2)
I believe it’s at this point we’d need to discuss how reasonable it is to ask implementors to support query parameters in more complex formats such as a JSON payload representing the query, such as what occurs in Elastic. I’m not deeply familiar with GraphQL or JQL myself, so they might be appropriate (@rgparkins might know more about this?). In any case, the concern from the standard’s perspective would be how to represent these capabilities using the Open API specification file; as long as we have a shared way of doing that, then it should be reasonable as an approach.
There is also certainly nothing stopping any HSDS developer from also providing additional functionality, they just also need to comply with the expected behaviour outlined in the API Specification; which we’ve now got more clarity on thanks to this engagement