Thank you for finding a way to move to ADL2!
I have only one concern. Using atCodes instead of idCodes is a breaking change for those that already use ADL2/OPT2. Shouldn’t the breaking changes planned for ADL2.4 require to be released in ADL3?
ID_CODE is used in the existing ANTL4 grammar for up to ADL2.3. It will be confusing to use the same grammar for ADL2.3 and the new ADL2.4. It would make sense to have a separate ADL3 grammar without the idCodes.
The existing “official” ADL2 grammars need to change anyway to “remove” the ID_CODE. To further confuse things, there are multiple ADL2 grammars at the moment and some “redefine” idCode:
idCode:
AT_CODE
| ADL14_AT_CODE
| ID_CODE
;
This “solves” the problem of supporting atCode where idCode is expected but it means that the parser must have a handwritten code to check that there are no idCodes used in openEHR-RM based systems (quoted from the ADL2.4 specifications):
- The at-code codesystem must be used for systems that need to be conformant to the openEHR Reference Model (RM).
- The id-code codesystem is recommended for non-openEHR RM information models.
Some tools are already using ADL2.3 with idCodes. I would rather have separate ADL parsers generated from ADL2.3 and ADL3 grammars.
I guess ADL2.4 was chosen because ADL3 is already used but it would be prudent to rename ADL3 to ADL4 and release ADL2.4 as ADL3. Shortcuts are quick but usually cause problems down the line.