Retrospective fix for tagging the form of BMM / P_BMM in use today

Implementation Tools
1

A question I originally posed to SEC, but more widely relevant, so moved here…

Due to my lack of proper management of the BMM spec, back in ~2018 when I wasn’t sure if it was being used, I failed to ensure that we created a release of the state of BMM corresponding to a) the code in ADL Workbench (which is known working), b) Archetype Designer, which if I am not mistaken uses Better code based on the same version of the spec and c) Archie.

The version that matters is this one in the BASE component (I added a tag ‘BMM-3.0’ just to not lose it), from 09-09-2018.

Some time later (09-11-2018) I created the LANG component (which we agreed IIRC in a prior Valencia UPV meeting), and moved BMM to it. However, between these two dates, quite a lot of additions were done to it, which the above-mentioned tools don’t need in their current working form.

In retrospect I should have suggested that we create a BASE Release 1.0.4 (or even 1.1.0) on that commit (we had already done 1.0.3), so that it became a visible release on the specs site. However, even if I had done so, we would have this snapshot 3.0 release in BASE, and the current working copy in LANG, where it belongs…

Now that I am about to start working on the Archie BMM code, I would like to establish a release somewhere that it and the other tools implementing BMM can refer to. It’s going to be confusing having this BMM 3.0 sitting in BASE (where it actually is), but to put it in LANG means rewriting history somehow, e.g. maybe creating a branch right from the first commit of LANG and pasting in a copy of this 3.0 form of the BMM from BASE, and tagging that as LANG Release-1.0.0. Note that we have no releases of LANG so far at all (= no tags), so we could do this.

Thoughts (other than ‘what the hell were you thinking?’ …)

2

No problem with that approach.
There are parts of BMM we don’t really support, so I can’t really say which exact version of BMM we are currently supporting. We already added archie as a dependency, so probably we will just swap the BMM parser and use the new one for the RM Archetype generation.

1 Like
3

Oops sorry forgot LinkEHR was using BMM, thanks for reminding me. I’ll need to track down all dependencies on BMM & Archie.

1 Like
4

I guess it’s the P_BMM + conversion to BMM part that matter most here, since the rest is usually internal to applications?
I’ll check later what exactly we support . I think I built up to enums in the P_BMM, but the BMM is a couple of versions behind - the conversion just maps it to the older BMM version.
I do know that the validation checks the bmm version number in the bmm files, and it currently only validates for versions 2.x.

5

Yes, right. The P_BMM model is the one that matters in terms of (not) breaking things. We can be more fluid with the BMM model, which is internal.

The version I want to work on would replace the current .bmm file format (= P_BMM graph dump, in ODIN) with a format more like OMG IDL / Ecore - Xcore. When (if!) I manage to get that happening, it will mean that the main BMM model is the one that defines the true semantics, and the syntax will just be the default serialisation format.

Anyway, in the short term I aim to get the BMM classes in Archie up to this BMM 3.0 level, which is mostly renaming. Hopefully others can help figure out if that will break anything.

6

Archie supports all of the P_BMM model in the BMM-3.0 tag.

The most recent version contains a P_BMM_INDEXED_CONTAINER_TYPE and a P_BMM_INDEXED_CONTAINER_PROPERTY. That is not implemented in Archie, and as far as I can see, it is not yet used anywhere in BMM files. That is not in the tagged version.

As for BMM, that is several versions behind in Archie, but you are working on improving that.

1 Like
7

We do some validation using the BMM. I will check with the team. As far as I know they will adapt quickly to what you suggests.