Skip to content

Changed Reconstitutability, Tempalte id #32

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
SevKohler wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

Changed Reconstitutability, Tempalte id #32

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 6 additions & 1 deletion docs/Identification/master07-referencing.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -351,8 +351,13 @@ With the more sophisticated identification system described here, these archetyp

`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`.
Copy link
Copy Markdown
Member

@gardes gardes May 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

@wolandscat wolandscat May 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

@joostholslag joostholslag May 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

@joostholslag joostholslag Nov 11, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.
Copy link
Copy Markdown
Member

@gardes gardes May 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

@freshehr freshehr Nov 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?


This requirement is introduced to allow compositions to clearly reference a specific version of the template and to facilitate transformation to ADL2. The template ID must be provided at the point of composition validation.
=== Supporting Archetype-based Querying

Querying of data in openEHR systems is assumed to be based on archetype 'path-sets', i.e. the set of paths extracted from an operational (flat-form) archetype. The paths are a slight simplification of standard X-paths. Two querying methods have been described to date, AQL and a-path, both making this assumption (see {openehr_query_aql}[The Archetype Querying Language (AQL)^] ).
Expand Down