It seems current templates doesn't have a version, just an id that can be a name (e.g. the Template Designer uses a name for the template_id).
Since we need to manage templates, like we manage archetypes that will change over time, we need an effective way of differentiating 2 versions of the same template.
CR: add a version to the format of the parent OBJECT_ID.value on TEMPLATE_ID, and make that version mandatory in the id. For tooling we might suggest to use "1" as default version, like the Archetype Editor does.
This proposal would be helpful to manage templates, but it could affect wide range of current templates and tools. I think this should be on 1.1.0.
Yes, I think it would need to be 1.1.0 - I'm marking it that way for now.
OET doesn't have a formal versioning mechanism. It has an open "other_details" field that is a key/value mapping. There a version can be stored but informally.
OPT 1.4 also have the other_details key/value mapping, but has the template_id that can be formatted. The Template Designer doesn't apply any format to the template_id. What I'm using is concept.language.version like this: https://github.com/ppazos/cabolabs-ehrserver/blob/master/opts/production/psychotherapy_note/psychotherapy_note.en.v1.opt#L37-L39
BTW, OET is not part of the specs AFAIK, IMO we need to focus on OPT versioning not OET. Different implementers might have their own template source format different from OET. In fact I'm using OET just because the TD works with that, but the TD has a lot of problems and I will switch to other modeling tools as soon as I can.
I am inclined to think that we should just use ARCHETYPE_HRID (the new version of ARCHETYPE_ID) for everything. See https://www.openehr.org/releases/AM/latest/docs/AOM2/AOM2.html#_the_archetype_package
I am not sure that TEMPLATE_ID really has a use. It was added to the model years ago when I thought that Templates would be differently identified.
On the SEC 09/19 meeting we decided to define which fields would be part of the template_id
I can give a reference to the ones we use, full doc is here
We use: concept.language.version
So it is easy to find different versions of the same OPT or the same OPT exported for different languages, like:
An we also use that format for the OPT file name, similar to what we do with archetypes. The idea is to be able to find files easily without looking at the content (as I think is the idea for ADL file names).
Maybe others can think of other fields that might be useful to add.