# \[openEHR SEC\] CONTAINS in AQL
**URL:** https://discourse.openehr.org/t/openehr-sec-contains-in-aql/16580
**Category:** Technical (archive)
**Created:** [1 October 2017 15:11 UTC](https://discourse.openehr.org/t/openehr-sec-contains-in-aql/16580 "2017-10-01T15:11:11Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [1 October 2017 15:11 UTC](https://discourse.openehr.org/t/openehr-sec-contains-in-aql/16580/1 "2017-10-01T15:11:11Z")
Hi all,
I’m reading through the AQL specs, on this section [http://openehr.org/releases/QUERY/latest/docs/AQL/AQL.html#\_containment](http://openehr.org/releases/QUERY/latest/docs/AQL/AQL.html#_containment) it is mentioned that CONTAINS is from parent to child.
Most examples there show COMPOSITION CONTAINS ENTRY. In a case that there is a SECTION in the middle, should AQL be always COMPOSITION CONTAINS SECTION CONTAINS ENTRY?
Before reading this specific point I was thinking that CONTAINS allowed to look anywhere on the COMPOSITION tree, semantically looking for “child or descendant”, instead of just “child”.
If we have only direct “child” references, having a small tree of SECTIONs can make queries more complex, like COMPOSITION CONTAINS SECTION CONTAINS SECTION CONTAINS SECTION CONTAINS ENTRY …
Would it be useful to have that kind of “child or descendant” containment operator added to AQL?
What do others think?
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [1 October 2017 17:00 UTC](https://discourse.openehr.org/t/openehr-sec-contains-in-aql/16580/2 "2017-10-01T17:00:35Z")
Hi Pablo,
The contains statement is intended to pick up any descendent and this is how it is implemented by marand ocean and Ethercis.
This works down to cluster level and I suspect to element if we had any element archetypes.
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [1 October 2017 17:24 UTC](https://discourse.openehr.org/t/openehr-sec-contains-in-aql/16580/3 "2017-10-01T17:24:42Z")
Hi Pablo,
CONTAINS is like the '//' operator in Xpath - it's matches the thing on the right hand side, anywhere under the object on the left hand side.
So doing COMPOSITION CONTAINS OBSERVATION and similar things is normal.
The AQL documentation may need to be fixed.
- thomas
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [1 October 2017 19:36 UTC](https://discourse.openehr.org/t/openehr-sec-contains-in-aql/16580/4 "2017-10-01T19:36:43Z")
Yes - this is the way DIPS openEHR server works as well.
For Composition we match any descendant . Any structure which matches will be valid no matter how deep the location is.
For Folder we have another case. There we only match the first level . This must be treated differently since we for Folder navigate through object references.
Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA
-------- Opprinnelig melding --------
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [2 October 2017 04:05 UTC](https://discourse.openehr.org/t/openehr-sec-contains-in-aql/16580/5 "2017-10-02T04:05:43Z")
Perfect!
I think the spec needs to clarify this. The only place that the relationship involved in CONTAINS is mentioned seems to be here:
“Since archetypes are in hierarchical structure, AQL has a containment constraint which specifies the hierarchical **relationships between parent and child data items**.”
And only mentions parent-child, that can be interpreted as direct child. It would be good to add the semantics of CONTAINS explicitly as parent to child-or-descendant.
“descendant” is not mentioned in the current spec.
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [2 October 2017 07:27 UTC](https://discourse.openehr.org/t/openehr-sec-contains-in-aql/16580/6 "2017-10-02T07:27:37Z")
PR time! Pablo, can you raise a PR for this change?
thanks
- thomas
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [4 October 2017 05:11 UTC](https://discourse.openehr.org/t/openehr-sec-contains-in-aql/16580/7 "2017-10-04T05:11:15Z")
Done!