So that we don’t forget, I have created for this.
I am not fussed whether it is prepended or appended, I can see tiny advantages 
for both.
The more interesting question to me is whether this is optional and only added 
when really needed or required.
There is this edge case, but I also wonder if a reasonable query on data would 
be to ask for anything inside a specific slot, no matter what it is filled with 
(as e.g. mandated by Template A vs Template B). This does not really seem to be 
(generally) possible - even if there are not two identical archetypes in 
different slots?


Von: openEHR-technical <> Im Auftrag 
von Thomas Beale
Gesendet: Montag, 22. Oktober 2018 19:00
Betreff: Re: Unique paths for slots problem if slots are filled with same 

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