As we have started to get into the detail of tidying-up the AQL specification and related issues like datatype ordering and comparison rules, there has been a pretty lively discussion here about the best way of documenting the required behaviour of AQL in the context of the openEHR Reference models.
I think we now have to make a decision so that we can make tangible progress. Broadly speaking two approaches have been suggested, and debated.
Define and document the rules and behaviours directly in terms of openEHR classes , inside the current specifications e.g as part of the UML , or indeed defined directly in BMM, using somewhat abstract modelling language
Define and document the rules and behaviours as a separate part of the specification, working much more directly and in human-language terms along the lines that @Seref started here but referring, of course to the existing specifications. I think of this is a document profiling the generic AQL specification for use with openEHR RM - perhaps not the correct use of ‘profile’ but we know that we have to give explicit advice about how AQL should work in openEHR CDRs.
I very strongly favour option 2, and it was my reading of the discussion that this was also the strong preference from the current CDR implementers. The sense I got was that while everyone understood some theoretical benefits from option (1) that none of the current CDR implementations do make use of BMM or intend to do so.
There are, I believe, also disadvantages in making the specifications even more difficult for those looking on from outside. Whilst it may not be important for newbies to understand the AQL spec, we should at least try to make it accessible for those coming into our world. BMM may well be where we head (particularly in the tooling space) but it is not what most CDR implementers seem to need right now.
I think we need to decide - can we get some kind of consensus / decision here?