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

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)
https://specifications.openehr.org/releases/RM/latest/common.html#_archetyped_class
archetype_id has type ARCHETYPE_ID
https://specifications.openehr.org/releases/BASE/latest/base_types.html#_archetype_id_class
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
https://specifications.openehr.org/releases/AM/latest/Identification.html#_versioning

​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:

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.

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.