Changed Reconstitutability, Tempalte id #32
Conversation
| `org.openehr::openEHR-EHR-EVALUATION.diagnosis.*v1.29.0*` | ||
|
|
||
| References with no namespace will remain legal, since there should be no computational impediment to using uncontrolled archetypes and templates, e.g. in an experimental situation. The lack of minor and patch level version numbers should also be legal for non-namespaced identifiers, and be interpreted as meaning `0` in both cases, i.e. `.v1` means `.v1.0.0`. | ||
| References with no namespace will remain legal, since there should be no computational impediment to using uncontrolled archetypes, e.g. in an experimental situation. The lack of minor and patch level version numbers should also be legal for non-namespaced identifiers, and be interpreted as meaning `0` in both cases, i.e. `.v1` means `.v1.0.0`. |
There was a problem hiding this comment.
I would have assumed that .v1 without minor or patch, means "any" minor or patch version, preferably the latest available one. All current archetypes would have a major version only but exist in many minor and patch versions. Maybe I am missing the context, @freshehr may provide better advice.
There was a problem hiding this comment.
This is why I have distinguished between
- an 'archetype reference', which could have 1, 2, or 3 part version id, and if less than 3, it resolves within a given env to the latest matching version available (e.g. v1 might resolve to .v1.4.0 of something) AND
- an 'archetype id', which is a 3-part thing, or else a 1-part thing for legacy artifacts.
There was a problem hiding this comment.
The ‘reference’ still inherits from the ‘id’ right? Should we break that inheritance. To me it implies a ‘reference’ is-a ‘id’, and we don’t want that. https://openehr.atlassian.net/wiki/spaces/spec/pages/2878439483/03.13.25+Template+ID+version+discussion?focusedCommentId=2880700422
There was a problem hiding this comment.
| References with no namespace will remain legal, since there should be no computational impediment to using uncontrolled archetypes, e.g. in an experimental situation. The lack of minor and patch level version numbers should also be legal for non-namespaced identifiers, and be interpreted as meaning `0` in both cases, i.e. `.v1` means `.v1.0.0`. | |
| References with no namespace will remain legal, since there should be no computational impediment to using uncontrolled archetypes and templates, e.g. in an experimental situation. The lack of minor and patch level version numbers should also be legal for non-namespaced identifiers, and be interpreted as meaning `0` in both cases, i.e. `.v1` means `.v1.0.0`. |
I disagree with this change. So suggest to cancel it. We do want (strongly recommend) template IDs to have a namespace but this should be enforced by the adl tooling and CDR (probably depending on DTAP deployment), not at the spec level, for the reason outlined here.
I also don't want to differentiate between templates and archetypes.
We could discuss no longer allowing HRIDs without a namespace (breaking change) but that's out of scope for this PR imho.
|
|
||
| `org.openehr::openEHR-EHR-COMPOSITION.SomeTemplateName.v1.29.0` | ||
|
|
||
| For template IDs, the link:https://specifications.openehr.org/releases/AM/development/AOM2.html#_archetype_identification[HRID format] is mandatory. Older formats that omit the namespace and version are deprecated but still supported for legacy data. |
There was a problem hiding this comment.
Suggest to add:
Older formats that omit the namespace and version or follow a completely different format are deprecated but still supported for legacy data.
There was a problem hiding this comment.
I'm also minded to cancel this change, for now. I think the whole section needs to be reworked once we have a better understanding of the impact of non-namespaced archetypes in transition to ADL2. I think the current text, though not perfect, does support the use of legacy and HRID tempateIds. So ... revisit when we have bottomed out archetypeIds and namespaces?
|
I don’t think we should do this. I think we should make it a recommendation to use namespaces. And makes sure as a community the key tooling ecosystems does this. |
|
@SevKohler @bostjanl-better how do we progress this? Shall we discuss it in the ADL WG (every other Tuesday from 11 November 11am CET). Or can we keep it async in this PR? |
|
ADL WG decided not to change this right now. Because the identification spec is already quite inconsistent with AM2 and BASE, so should be undertaken as a thorough review of the spec. Not as a prerequisite for adl2.4 release. Let's keep it as draft for further use. |
So this is the way forward ? |
Yes let's cancel this change (but keep it as a draft) and revisit as @freshehr suggest in the quote above. |
5 participants
This is a draft PR to raise awareness.
Changes need to be still discussed.
Ping @gardes