Do we have conflicting definitions for versioning in archetype node ids?

Specifications ADL
1

As per LOCATABLE’s archetype_node_id definition:
Common Information Model

Always in the form of an at-code, e.g. at0005

then we say (a few lines below:)

At an archetype root point, the value of this attribute is always the stringified form of the archetype_id found in the archetype_details object

huh? what happened to “always” above?

following type of archetype_details (ARCHETYPED)

archetype_id has type ARCHETYPE_ID

and it says

Lexical form: rm_originator '-' rm_name '-' rm_entity '.' concept_name { '-' specialisation }* '.v' number

so that’s v0,v1,v2… which is what we see in the wild all the time.

Except, archetype identification document says that

​version_id        =   release_version [ extension ] ;
   ​release_version   =   major_version '.' minor_version '.' patch_version ;
   ​major_version     =   { V_NUMBER } ;
   ​minor_version     =   { V_NUMBER } ;
   ​patch_version     =   { V_NUMBER } ;
   ​extension         =   version_modifier '.' issue_number ;
   ​version_modifier  =   '-rc' | '-alpha' ;
...

the above is from section 4.2 and down the document, we see
openEHR-EHR-EVALUATION.diagnosis.v1.1.5

So do we do semantic versioning or not? and the lexical from above does not include optionality for release_version so it appears to be fully semver.

I was asked the simple question about whether or not archetype node ids follow semver and I could not give a good answer, so I’d appreciate some help here :slight_smile:

2

Probably we should adjust some of the language, but the scheme (which I think everyone is used to for a long time) is:

  • node ids (at-codes, or in ADL2, id-codes) on the non-root nodes
  • archetype_id (stringified) on the root nodes.

What you quoted from the Identification spec is for ADL2, and I am not sure how much will ever get retro-fitted to AD1.4 - it’s mainly down to CKM and other tooling I guess, as well as back-end EHR systems. Archetype Designer is only showing .v0, .v1 etc - not sure what it has inside.

The ‘new’ structural definition of Archetype ID is the ARCHETYPE_HRID class, currently maintained in the AOM2 spec (here), but it should really be in the base.identification package.

So for ADL 2 archetypes, the answer is yes (semver); for ADL 1.4 in most usages, it is no.

BTW, there is a section near the end of the Identification spec on ‘referencing’ i.e. how we should correctly reference archetypes in data.

As always, proposals to improve any of this are welcome.

3

Thanks Tom. The point I missed is the difference between ADL2 and ADL1.4 . I don’t have the setup in place now but I’ll do a shutgun surgery at some point to send a pull req. to emphasise we’re talking about adl2, which may not even be necessary, because it may simply be the case I missed what’s right in front of my eyes.