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. On Oct 1, 2017 4:37 PM, "Bjørn Næss" <b...@dips.no> wrote: > 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 -------- > Fra: Ian McNicoll <ian.mcnic...@gmail.com> > Dato: 01.10.2017 19:05 (GMT+01:00) > Til: For openEHR technical discussions <openehr-technical@lists.opene > hr.org>, sec <s...@lists.openehr.org> > Emne: Re: [openEHR SEC] CONTAINS in AQL > > 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. > > On 1 Oct 2017 at 16:12, <Pablo Pazos <pablo.pa...@cabolabs.com>> wrote: > > Hi all, > > I'm reading through the AQL specs, on this section http://openehr.org/rel > eases/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? > > -- > Ing. Pablo Pazos Gutiérrez > e: pablo.pa...@cabolabs.com > p: +598 99 043 145 <099%20043%20145> > skype: cabolabs > <http://cabolabs.com/> > http://www.cabolabs.com > https://cloudehrserver.com > Subscribe to our newsletter <http://eepurl.com/b_w_tj> > _______________________________________________ openEHR-technical mailing > list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailm > an/listinfo/openehr-technical_lists.openehr.org > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical@lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_ > lists.openehr.org >
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
