I respectfully, but strongly disagree 
I’ve seen this point made before and I meant to respond then. AQL has the potential to be generic query language to query any underlying model but I’m in favour of defining it strictly based on openEHR terms, based on openEHR EHRs, data types, structures etc.
With my implementer hat on, I would like a query language spec to focus on the language and terms of data that I’m processing. This is why my suggestions for a formal definition of FROM above refer to RM types, their attributes, containment in EHR etc.
I am the one who raised the overloaded semantics of CONTAINS and I’m happy to further specify it but I would rather do that based on more openEHR words, not less.
I made a second pass to simplify my definition but I’m keen to address potential adapters using an openEHR specific terminology and language.
That’s my 2 pennies of course, happy to hear what @bna and @matijap would think.