Include a version() method on TEMPLATE_ID
Description
Attachments
is blocked by
Thomas Beale
Activity
@Severin - I added this page https://openehr.atlassian.net/wiki/x/gIC5qw
which I think more clearly walks through the specifics of what to store in archetype_details/template_id, and what happens as we flip to using ADL2 compositions, where officially template_id is redundant, as it is the template_id that is carried in archetype_details/archetype_Id, and not the archetype_id of the parent COMPOSITION as in 1.4. I don’t think that actually matters too much here but might shape our thinking re the separate discussion on supporting HRID in archetype_details @Sebastian Iancu
I’m quite happy to for anything to be folded into the parent page that you created but I felt we needed to dive a bit deeper with real examples. @Joost Holslag kindly provided an example of an ADL2 composition, which I have attached.
@Joost Holslag about the metadata, it’s the OPT’s header, maybe @Ian McNicoll can share one of his OPTs that has the version there. As an example, I just opened a random OPT and added a fake version and namespace. The problem is that different editors could have different metadata headers (named differently, different formats, and different in terms of which are required or optional, this is what I would like to be mandated by the spec: one way of adding a version and namespace so everyone follows the same rules)
<template xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.openehr.org/v1">
<language>
<terminology_id>
<value>ISO_639-1</value>
</terminology_id>
<code_string>en</code_string>
</language>
<description>
<original_author id="name">Heather Leslie</original_author>
<original_author id="organisation">Atomica Informatics</original_author>
<original_author id="email">heather.leslie@atomicainformatics.com</original_author>
<original_author id="date">2020-08-17</original_author>
<lifecycle_state>unmanaged</lifecycle_state>
<other_details id="licence"/>
<other_details id="version">1.0.2</other_details>
<other_details id="namespace">org.openehr</other_details>
<other_details id="custodian_organisation"/>
<other_details id="original_namespace"/>
<other_details id="original_publisher"/>
<other_details id="custodian_namespace"/>
<other_details id="MD5-CAM-1.0.1">5b4c02e8097ed021f8e3d6580fe7f5a4</other_details>
<other_details id="PARENT:MD5-CAM-1.0.1">05F3E1D9A0891A37F1DD10A47CCFA472</other_details>
<other_details id="original_language">ISO_639-1::en</other_details>
@Joost Holslag for reference:
related 5y old discussion https://discourse.openehr.org/t/rest-call-to-manage-template-definitions/392?u=joostholslag
What @Sebastian Iancu proposes there is another option which is to make the build_id part of the template_id. One challenge for that is build_uid is in AOM2 and that would make base depend on AM, which we probably don’t want. We could move build_uid to BASE.AUTHORED_resource, but would that be a breaking change?
Also it doesn’t help to semantically understand the version. So I’m still with the above described approach.
And a build count depends on the build, not on changes to the template. So structurally and semantically identical templates will have different ‘build_uid’’s. this can be a downside because it prohibits you from making the assumption nothing ‘important’ has changed.
One big advantage is that you don’t depend on correct semantic versioning of the template as an artefact maintained outside your CDR. You just assume there are changes. This could be useful even if we do add full versioning info to the template_id. Because you never know if it’s correctly semantically versioned.
We would need to specify a lexical form for the template_id that includes the build_uid. I seem to remember a ‘+’ symbol after the HRID.version_id(including the build_count, not to be confused with build_uid). But I couldn’t find it when searching for ‘build’ in the AM spec. So I don’t think it’s’ part of the AM spec atm, so I guess we’re free to do whatever. As long as it’s compatible with AOM2.HRID Sebastian has a syntax he uses at code24 which sounded reasonable, I believe a double colon ::uuid after the (free form) template id.
Edit: no longer as convinced that’s the best option
https://specifications.openehr.org/releases/AM/development/AOM2.html#_authored_archetype_class
Details
Details
Reporter
Pablo PazosComponents
Priority
Major
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.