Many things look good at the demo level.
I prefer writing the specifications in a DSL like BMM and then generate diagrams from it. And not only diagrams but as much of the applications as possible as well.
Edit: Don’t forget about the new features like the Expression language. I don’t see how UML/OpenAPI would be used for that.
I started doing one manually - main difference from generated is that the manual one doesn’t include the included classes, whereas the generated one (at least the copy I took yesterday) contains defs of a lot of includes. This I assume is because the generator tries to build a standalone BMM file, which could make sense in some situations. But for the ITS-BMM, we can just re-use BMMs from other BMMs in the normal way.
The other difference is that there is no official BMM (or UML) meta-model of the expressions yet, so this would be a bit made up.
Anyway, I should have a working BMM for AOM 2.0.6 in a couple of days. Might be useful as a reference to the generated one - including the generator I will eventually write based on the current UML extractor.
I’d have to have a look at its semantics, but every similar formalism (including Eclipse Xcore) I have looked at except OMG IDL, is unable to represent generic types properly, generics through inheritance, and usually doesn’t distinguish types from classes properly. Lambdas are often not first class citizens either. However, Xcore syntax is the kind of syntax we should be aiming for I think. Another reference is SysML2, which is under construction.
I managed to get my serialization working.
Here is one of the classes that gets generated from the AOM:
I cannot test this code since OPT2 are 2.3.0 and my AOM is 2.0.6, but two great persons offered to help me 
There is now an AOM 2.0.6 BMM schema, and some needed includes in the specifications-ITS-BMM repo.
It compiles in ADL Workbench, but that doesn’t guarantee it is correct - there may be remaining errors.
I also have to create AM 2.1.0, 2.2.0, and 2.3.0 BMMs as well, which are incremental changes from this AOM 2.0.6.
But this should get you started.
@NeoEHR In the expression language, it’s very possible that Archie has different implementation classes than the standard - the ones in the standard were changed a couple of times after we had implemented it already. It is possible to make a (configurable) custom json mapping to match the standard in Archie, but that is not done. All the other things of the model should match 100%.
You may want to use the Archie generated BMM if you want to parse the expression language model expressed in JSON.
@thomas.beale The single BMM file is just because I did not want to spend any effort in writing the code to create several BMM files for just the AOM - it did not add anything for me.
Indeed - I was thinking about the design of the UML → BMM extractor, and creating separated files is quite a lot of work, so perfectly comprehensible. BTW I found various errors, which you are probably already fixing, anyway, they’re typical things that occur in these kinds of converters as you work out the details. Specifically:
is_mandatory set on them0..*<xxx, ...> used for ‘ancestors’ not needed, can just be <xxx>P_BMM_SINGLE_PROPERTYscorrect form:
["is_enumerated_type_constraint"] = (P_BMM_SINGLE_PROPERTY) <
name = <"is_enumerated_type_constraint">
type = <"Boolean">
>
Currently generated:
["enumerated_type_constraint"] = (P_BMM_SINGLE_PROPERTY) <
name = <"enumerated_type_constraint">
type_def = <
type = <"BOOLEAN">
>
is_mandatory = <True>
>
There might have been a couple more, but if the above are fixed, the generator will be 97% there.
Thank you! Tried it but it is (probably correctly) including “openehr_base_1.0.4”.
Version generated by Pieter from Archie is including “openehr_base_1.1.0” which is great as I could use it with the newer releases.
I guess AOM 2.2.0 and 2.3.0 will use newer RM releases so that it will be compatible with the OPT2 exported from the VSCode extension.
p.s.
I’m preparing a “thank you project”. It rhymes with BMM => UML 
Yes, that is correct; you will see that there as well. It contains the correct version of the (old) Expression model. It’s not quite complete yet, a bit more to do on it.
The next versions will include openehr_base_1.1.0 and openehr_expression_1.0.4.
I’ll get the AM 2.2.0 and 2.3.0 BMMs up fairly soon.
Note that none of them use RM directly; ADL/AOMs is independent of RM, AOM1.4 had a small dependence on RM types, which I think you probably don’t care about.
Thanks for looking at the conversion results.
Note that this converter is mainly for a limited purpose - just generate something that works, not generating something that’s an optimal hand-coded BMM file. From that perspective:
Hmm, looks like the AOM implementation in Archie is not annotated with @Nullable, unlike the RM. I’ll try to see if I can do this.
From the above perspective, very low priority, but also easy, so I will check if it is.
The , … indicates it is a list, which makes the BMM much easier to convert to correct JSON/YAML and to process with existing tools. Archie can parse the other form just fine, but it will be annoying for anyone else. This is not just the BMM, but the generic ODIN generation of Archie that does this for any single element list. So not sure if I should fix this at all.
Ah, that I will look into. Can be tricky, I hope they do not appear like this in the JSON serialization as well, because then it will be more tricky to fix (will probably need a new configuration parameter to make it backwards compatible on demand, and parse both alternatives?)
if easy to fix I will add it, but otherwise the meaning of the output is exactly the same, so will not matter much.
There are more problems in the generated BMM: for example constraint is not in C_PRIMITIVE_OBJECT. Neither is assumed_value. They are in the subclasses. This is because this is actually a BMM generated from a java implementation of the AOM, where some of these things have to be different to work. That might actually help in code generation, by the way.
Ah yes, I had to put those things in as well. BMM just does replaces of same-named properties, with some conformance checking.
For the ancestors list thing, it’s not wrong, so you might as well leave it in your version.
Ok, so a couple more differences:
TEMPLATE.overlays in the spec, archie as templateOverlays (so template_overlays in BMM). Looks like a mistake on my side in 2016.
C_TEMPORAL. pattern_constraint in spec, patterned_constraint in archie (probably mistake on my side?)
Oh, and:
Ok, fixed some things, and generated the BMM for AOM 2.3.0. Changes:
), such as rm_overlay and constraint binding strengthIssues remaining:
is_prefix.Both are fixable, but will take more time to properly fix, and in the first case will mean some work to ensure backwards compatibility of the JSON output is guaranteed, probably with some extra configuration.
Output is available at aom-2.3.0-generated.bmm · GitHub
Yep i fixed this one yesterday - sorry, I should have written these down. Should be pattern_constraint.
yep - I fixed those, that is incorrect.
yes, otherwise the object does not need to exist.
That appears to be a missing ‘include’ line in the Resource spec - I’ll fix that. (Here it is in the UML site).
That’s a BMM error I missed; will correct.
Ok - corrections to do there as well.
Teamwork rules
Thank you @pieterbos !!!
I got it working.
Did the same changes as for 2.0.6 (removed duplicate classes already in openehr_base_110.bmm):
AUTHORED_RESOURCE
TRANSLATION_DETAILS
RESOURCE_DESCRIPTION
RESOURCE_DESCRIPTION_ITEM
For 2.3.0 I additionally removed:
MULTIPLICITY_INTERVAL
CARDINALITY
These two were “silently” added to the openehr_base_110.bmm when Thomas pushed the added openEHR_am_206.bmm.
I also added missing generic_parameters = <"xyz"> to all root_type = <"INTERVAL">.
Thank you both!!! You two rule 
See the specifications-ITS_REPO now; contains various fixes in both BASE and AM BMMs; also contains a AM 2.1.0 and 2.2.0 BMM. Compiling in ADL Workbench. 2.3.0 coming tomorrow.
I’ve released UML diagrams generated from the specifications. See this post: