I need to study this problem a bit more, but having read the posts here, I think the solution would potentially to allow the /optional addition/ of a '::atNNNN' appended to an archetype id at a root point. This means that all current systems and data remain valid. It is better if it is appended rather than prepended because it means the string id always starts with the archetype id (= the case today) and may have something on the end, and that would only be the case for this fairly rare use case. It would also be a fairly simple code upgrade to existing systems.

So I would agree with Diego's syntax below, but say that it is optional, and only required when needed, which appears to be this one edge case. If we can convince ourselves of this, this is a pretty easy change to the relevant template tools and also ADL2.


- thomas

On 19/10/2018 10:44, Diego Boscá wrote:
While I believe we have reproduced this behavior in the OPT management to be compatible with existing tooling, in our typical slot solving methodology (non-template mode) the original archetype slot node_id ends in the new object node_id. Information about which slot was solved in this node ended in a new attribute in the term definitions (we called that attribute 'DCM', but you get the idea). We modified the AOM model to have references to both current archetype and solved archetype in order to avoid node_id collisions in archetype definition time.

I think we have talked before about the need of splitting the archetype_node_id attribute into node_id / archetype_id, which I think would solve these problems. Another solution would be to include always the node id in the node id, even if you are using it to store the archetype_id, so paths would look like

openEHR-technical mailing list

Reply via email to