AQL question about predicates

Specifications AQL
1

Could path predicates be used to filter on other attributes than archetype ids and node ids? For instance, is this valid?

SELECT c FROM COMPOSITION c [uid/value='_this_is_a_version_id_']

Note: testing that on EHRScape, I get 400 Bad Request with no error message, and on Ethercis/EHRBASE I get 400 and an antlr exception “Could not process query, reason:org.antlr.v4.runtime.misc.ParseCancellationException: AQL Parse exception: line 1: char 29 mismatched input ‘uid’ expecting ARCHETYPEID”

Or the only way of doing such thing is by using a condition in the WHERE?

SELECT c FROM COMPOSITION c WHERE c/uid/value = '_this_is_a_version_id_'

By looking at the spec (Archetype Query Language (AQL)), it seem to be valid by using “standard predicates”.

2

It should be valid. It’s quite common to use name/value predicates, for instance, to filter localized/translated instances of COMPOSITIONs. However, it might be limited by vendor support.

3

I agree, in theory they should be valid but it would be helpful to establish some reasonable minimal expectations cross-implementer for a few high-value examples, as there are potentially unlimited options.

And they should be available on FROM and CONTAINS

SELECT c FROM COMPOSITION c [uid/value=‘this_is_a_version_id’] CONTAINS OBSERVATION o[name/value = ‘My lovely blood pressure’]

Ian

4

Yes, that kind of predicate are “node predicates”, I guess my example falls under “standard predicates”. I guess some implementations support node and archetype predicates.

Also, it seems the current grammar doesn’t support the standard predicates. Maybe the grammar should be updated.

5

It seems the current “standard predicates” could be defined over any attribute (path to it) on the root type where the predicate is applied. Not sure if this needs to be constrained. IMO specifying paths over RM classes should be cross-implementation valid.

Also consider we are currently discussing about adding “type checking” for AQL expressions and formally defining operators for each simple data type, with that in place, then the “standard predicates” will work securely on any type with any comparison operator.

But for now, to be consistent, I think we need to improve the grammar to allow “standard predicates”, since that is specified but the current grammar doesn’t seem to support it.