That is one of the issues with AQL, one thing is to support the syntax, another thing is to have compatible query engine implementations, even if the semantics are correctly interpreted for each operator, data results might differ. But we are also having different interpretations of the operators, and also different levels of support of the AQL syntax itself.
My interpretation of this situation is we are on a starting point of a wider use of the query specs, we will have inconsistencies between implementations and maybe in a couple of years we will have a clear spec for the full AQL syntax (with extensions), the internal query engine architecture, and the result sets. On Tue, Aug 21, 2018 at 2:28 PM, Birger Haarbrandt < [email protected]> wrote: > Hi Thomas, > > from my perspective, this approach (by not being explicit about the RM > classes (and semantics) that need to be supported by the Contains keyword) > led to a situation in which two vendors (Marand and DIPS) can claim that > they have a valid implementation of openEHR but are not compatible. I can't > even tell if Marand (not support Folders at all) or DIPS (using > questionable overloading of the semantics) is more right or wrong with > their approaches on this matter... > > Birger > > > Am 21.08.2018 um 17:04 schrieb Thomas Beale: > > Hi Birger, > > Note that no openEHR RM types (COMPOSITION etc) are part of the AQL spec - > they are just used in examples. AQL doesn't actually know anytthing about > particular types. Seref's intention is that it stays this way, and his > proposed function, or some other equivalent resolver mechanism would be a > generic addition to AQL that would, for openEHR structures be used for > FOLDERs containing refs to COMPOSITIONs (actually VERSIONED_COMPOSITIONs), > and also any other similar situation (e.g. in the demographic model). > > - thomas > > > On 21/08/2018 15:52, Birger Haarbrandt wrote: > > Hi Seref, > > while I understand your argument regarding overloading of definitions (and > I agree with your reasoning), I see a clear need to not treat folders as > second class citizens in openEHR. Not including Folders in the official AQL > spec and leaving this to vendor-dependent functions will not be helpful to > allow portability. Especially, as the use of folders (especially when it > can contain data in an ITEM_STRUCTURE) is becoming a common pattern to > represent episodes of care. > > Cheers, > > -- > > > > _______________________________________________ > openEHR-technical mailing list > [email protected] > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org > > > -- > > > > *Birger Haarbrandt, M. Sc. Peter L. Reichertz Institut for Medical > Informatics (PLRI) Technical University Braunschweig and Hannover Medical > School Software Architect HiGHmed Project * > Tel: +49 176 640 94 640, Fax: +49 531/391-9502 > [email protected] > www.plri.de > > _______________________________________________ > openEHR-technical mailing list > [email protected] > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org > > -- *Ing. Pablo Pazos Gutiérrez* [email protected] +598 99 043 145 skype: cabolabs Subscribe to our newsletter <http://eepurl.com/b_w_tj> <https://cabolabs.com/> http://www.cabolabs.com https://cloudehrserver.com
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
