I have started an ADL 1.4 migration roadmap page. This currently consists of a list of all changes made from 1.4 => 2.0 (as it now is), with an idea of which retrospective interim version (i.e. 1.5, 1.6, 1.7 etc) the change could go in. Although this isn’t the way things are normally done, there is one major advantage: the way things are working now in ADL/AOM 2 are pretty good and have been re-engineered a few times over the ADL ‘1.5’ journey. Putting the final version into these retrospective releases should mean a smoother ride from 1.4.
Who does this affect? Firstly, everyone with 1.4-based tools, openEHR implementations and AQL queries. Secondly, the ISO 13606 revision process - these interim versions are likely to be the best roadmap to new versions of AOM in ISO 13606, if that revision proceeds.
The initial work I have done is to try to include a row for each ADL/AOM 2 change, and assign an interim version like ‘1.5’, ‘1.6’ etc to it. I made some suggestions as to what the interim releases could be:
1.5 - quick wins
1.6 - tuples; remove openEHR special C_DV_QUANTITY etc types
1.7 - differential archetypes and templates
But these are there to be broken.
I have also included some impact headings on the right side of the table.
All of this needs the relevant members of the community to look at it; I won’t be spending much time on it personally, other than to help people understand the technical side of ADL/AOM 2 and what effects it has on specific things.
Hello Thomas and thank you very much for pushing this. As we talked early this year, I think this interim or transitory versions are the way to go before 2.0 is complete.
Personally, and regarding EN ISO 13606, I also think it is the best option for the current renewal process to adopt only small changes that solve limitations or problems of 1.4, and leave the adoption of 2.0 for the next renewal process, once 2.0 has been fully tested through implementations and supported by the industry.
Regarding the contents of each version, we have to study it in detail, but probably the philosophy could be:
1.5: changes that only affect the parser and maybe need adding some support classes to the AOM, but that can afterwards be ignored by systems (e.g. annotations, generated marker, maybe the namespace, …)
1.6: changes that would require that the new edited archetypes have to be “exported” to 1.4 format to work normally (e.g. change domain types to tuples, absence of existence and cardinality or the differential specialization)
1.7: changes that would affect how systems use the archetypes (e.g. unification with templates)
Right - I am thinking only that the ‘1.5’ changes would go into the current 13606 renewal. We need to work on this together to massage it into a list that is doable - what you see now on that page is just my first go. I think these are good ways to look at it. I Iike your 1.6 criterion in particular. I think 1.5 will probably need to support the extended ids though, because the problem of ‘model-clash’ is becoming serious. But - those new ids are in a sense optional, i.e. a system that doesn’t care about them due to be self-contained (which may well be true for some 13606 systems, and maybe some of the openEHR ones as well) won’t feel any impact. my thinking as well, but I’m not sure yet. - thomas