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

**Category:** [ADL](https://discourse.openehr.org/c/adl/40)
**Created:** 2020-10-27 12:04 UTC
**Views:** 486
**Replies:** 2
**URL:** https://discourse.openehr.org/t/do-we-have-conflicting-definitions-for-versioning-in-archetype-node-ids/1063

---

## Post #1 by @Seref

As per LOCATABLE's archetype_node_id definition:
 https://specifications.openehr.org/releases/RM/latest/common.html#_locatable_class
> 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 :)

---

## Post #2 by @thomas.beale

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](https://specifications.openehr.org/releases/AM/latest/AOM2.html#_archetype_hrid_class)), 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.

---

## Post #3 by @Seref

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.

---


**Canonical:** https://discourse.openehr.org/t/do-we-have-conflicting-definitions-for-versioning-in-archetype-node-ids/1063
**Original content:** https://discourse.openehr.org/t/do-we-have-conflicting-definitions-for-versioning-in-archetype-node-ids/1063