This is a great answer @matijap and you truly show why you are Better 
Response to your two questions:
As I wrote earlier
What I meant by this is :
- To teach the (internal) developers using our backend to use it properly and explain what the expected output will be based on the query they propose. Most developers has very high competence and experiences using SQL. They think AQL is the same - but it’s not. That is confusing and for many disappointing.
- For the core team who has been working with openEHR since 2010 to find out how a given AQL is expected to map into complex hierarchical datastructures and produce the resultset that both a “semi-clinical-tech” and the “high-competent-openEHR-expert” think is correct. Often we find a discrepancy here. I.e. @ian.mcnicoll had some issues accepting the Glasgow Coma Scale example given here. And we, as a community and SEC group, has not yet found a shared solution for the permutation problem as explained here. For the both the latter examples we, DIPS, is working on some assumptions and query logic which seems to solve it. I will share it as soon as I am able to understand what the developers are doing currently (it’s AFAIK heavy stuff, but I think/have heard rumours that the Better guys already has some solution to this).
- And of course the ORDER BY issue like “should there be a default order if no order is given”, how to order data types. And similar to this how to handle NULL when ordering? Do we need some operator to explicit give the AQL engine hints about i.e. NULL FIRST
All the examples above is more informal and descriptive than formal modelling definition. Other might have a different view on this. But I must say for us, DIPS, what is important in short terms is to define the expected rules for the problems raised above. And I can not see how to work with this kind of problems without discussing them. So far my the questions related to ORDER BY has been replied with “this can be fixed in BMM by some infix operators”. That’s fine I think, but for AQL we simply don’t care because the AQL pipeline is extremely handcrafted and optimized for our specific implementation. All wee need is an informal description of what we agree on as a SEC group.
Current use of AQL is limited to query EHR RM based data. I agree with @matijap that we need some clarifications in text which covers the use-cases that customers or clients will face. If we some time in the future will do more work on DEMOGRAPHICS or TASKPLANNING then we may add text to clarify such use-cases. I think @sebastian.iancu will provide some good use-cases for DEMOGRAPHICS and we will eager to learn about their experiences.
And as a final note to self: @Seref - I am sorry for not responding to your initial post in this topic. I think you made a really good start for the discussion. And it was so good that I didn’t have any specific comments to it. It made sense to me