well, things like this we have discussed before, but they belong in the realm of semantic interpretations of the data, not the mechanical act of getting it out of the persistent store. So further filtering or other smart behaviours based on the content / values has to be in a layer above, which today no-one has, and for which we have not even a draft spec. From @ian.mcnicoll’s point of view, these kinds of things are burning clinical safety priorities (I agree); it’s just that you can’t achieve all levels of semantics in the one layer of functionality.
Now, you could achieve some (all?) of these kinds of things with rules, e.g. a rule that states something about draft VERSIONs. What AQL would then need is a generalised notion of such rules, so that any such rule could be written. These rules can be simple to start with. But it would be wrong (again) to embed in the spec statements like ‘if the data model of the query is openEHR RM, and the data item is inside an instance of VERSION class that has draft=true, then don’t return the object’ or whatever.
Instead, the AQL spec should have a general capability to post process (or maybe inline process) some rules that might knock out certain query results if a general pattern is matched (e.g. the content was inside some container considered ‘incomplete’ or ‘draft’). The notion of draft or incomplete is a general one; how openEHR RM or any other model marks its content as draft or incomplete is a model-specific thing. So somewhere in an the query processing process, a ‘remove draft data’ filter is activated, and it will have to look up the appropriate rule that that do this for the data at hand.
These sorts of things are somewhat sophisticated, but never have to be know by query authors, only query engine implementers (probably < 10 people in the whole world). For authors, an engine that knows how to remove or include ‘draft’ info on a switch just does so magically.
Right. As we infer the general rules / semantics, we can put them into the AQL spec. While we don’t know what the general case is, we don’t put anything (certainly not specific references to particular models or classes).
In general, I think any shared specification should only be the general case ‘rules’ (structures, whatever) that have been inferred by study of specific systems and contemplation of known theory. In other words, normal scientific method. A specification (i.e. a language, model etc) is just today’s version of a general theory about some topic.
So the bottom up approach here is that the AQL spec is anaemic on a lot of semantics, but that with the experiences to date, we can slowly start determining the general formulation of various features (CONTAINS, projections, draft content inclusion …) and when we agree on them, we add them in. Before we have them, the community is still experimenting, and we don’t know what the general formulation that can be put into the spec is. Again, normal experimental science approach.
owww, such a warm message … let me hug you! 
