Where to find AOM2 BMM for the latest stable release (2.3.0)

[NeoEHR (Borut Jures)]

@thomas.beale

There is now an AOM 2.0.6 BMM schema

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

[thomas.beale]

@NeoEHR

Tried it but it is (probably correctly) including “openehr_base_1.0.4”.

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.

[pieterbos]

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:

@thomas.beale

all (?) properties seem to have is_mandatory set on them

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.

@thomas.beale

cardinality only needed when it is something other than 0..*

From the above perspective, very low priority, but also easy, so I will check if it is.

@thomas.beale

the old form of list <xxx, ...> used for ‘ancestors’ not needed, can just be <xxx>

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.

@thomas.beale

Boolean properties have ‘is_’ missing in the name (see below ex.)

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?)

@thomas.beale

• the converter currently outputs a complex type structure for ?all P_BMM_SINGLE_PROPERTYs

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.

[thomas.beale]

@pieterbos

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.

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.

[pieterbos]

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?)

• in the spec, several C_PRIMITIVE_OBJECT subclasses have default_value is mandatory. I do not think it should.
• in the spec, C_TERMINOLOGY_CODE.constraint is mandatory. Should it be?
• the class RESOURCE_ANNOTATIONS cannot be found in the specifications
• in base BMM, resource_description.details is mandatory, in the specification, it is not.

[pieterbos]

Oh, and:

• ARCHETYPE_HRID.namespace is incorrectly mandatory in the base 1.1.0 BMM

[pieterbos]

Ok, fixed some things, and generated the BMM for AOM 2.3.0. Changes:

• the changes in AOM 2.3.0 (obviously ), such as rm_overlay and constraint binding strength
• fixed the STRING and BOOLEAN type so it is now String and Boolean
• cardinality no longer present for lists if >=0
• All optional fields should no longer appear as mandatory
• it now outputs type= instead of type_def= for simple properties

Issues remaining:

• Archie outputs in both JSON and this BMM boolean fields in the AOM without the is_prefix.
• It still contains some (but not all) classes also present in base

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

[thomas.beale]

@pieterbos

patterned_constraint

Yep i fixed this one yesterday - sorry, I should have written these down. Should be pattern_constraint.

@pieterbos

C_PRIMITIVE_OBJECT subclasses have default_value is mandatory. I do not think it should

yep - I fixed those, that is incorrect.

@pieterbos

in the spec, C_TERMINOLOGY_CODE.constraint is mandatory. Should it be?

yes, otherwise the object does not need to exist.

@pieterbos

the class RESOURCE_ANNOTATIONS cannot be found in the specifications

That appears to be a missing ‘include’ line in the Resource spec - I’ll fix that. (Here it is in the UML site).

@pieterbos

in base BMM, resource_description.details is mandatory, in the specification, it is not.

That’s a BMM error I missed; will correct.

@pieterbos

ARCHETYPE_HRID.namespace is incorrectly mandatory in the base 1.1.0 BMM

Ok - corrections to do there as well.

Teamwork rules

[NeoEHR (Borut Jures)]

@pieterbos

Output is available at aom-2.3.0-generated.bmm · GitHub

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

[thomas.beale]

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.

[NeoEHR (Borut Jures)]

@NeoEHR

p.s.
I’m preparing a “thank you project”. It rhymes with BMM => UML

I’ve released UML diagrams generated from the specifications. See this post:

Generating UML diagrams from specifications

I heard @thomas.beale mentioning his wish to have diagrams generated directly from the computable specifications. This might enable him to skip using UML tools that he doesn’t like. I’ve created a simple UML diagram generator and browser. Sample class with enum: [c-terminology-code] Larger diagram: [task-plan] You can also create your own custom diagrams: (Recreation of “The Archetype Package Overview” found at specifications site) [uml-custom-diagram] Thanks to @pieterbos and @tho…