Hi Bert Bert Verhees wrote: > About your suggestion about the internal_ref I have a remark, because, if > you construct the path like that, and which seems logical, it is not > possible to distinguish in the path, or from the path, that it contains a > reference. > Does this matter? Anything that handles these paths (eg a "Get ADL Node at Path" function) should be able to find the targeted node whether it goes through an ARCHETYPE_INTERNAL_REF or via the more common C_COMPLEX_OBJECTs. > So in my example the path would be: > /contacts[at0009]/contacts[at0005]/addresses[at0006] > Perhaps I misunderstood you. I think it would be /contacts[at0009]/addresses[at0006] because your reference is to the addresses node, not contacts node. > This would suggest that there exists a contacts inside contacts, other > examples (not repeating the same rm-reference) could even be more > confusing. > > So replacing the second contacts by the first is another option, like this > /contacts[at0005]/addresses[at0006] > would become this: > /contacts[at0009]/addresses[at0006] > Maybe in this constructs also are problems of which I haven't thought of, > yet. How are other implementers doing this? > > I wonder, is there no specification/rule about this? Shouldn't there be > one, maybe in the context of having an open standardized platform where > third parties can connect to, and understand the objects they get from a > system? > The relevant documents don't make this explicit to the best of my knowledge. The ADL1 spec has a section on "ADL paths" (http://svn.openehr.org/specification/TRUNK/publishing/architecture/am/adl.pdf section 5.3.7, section 7) and the Architecture Overview mentions paths in archetypes and templates too (http://svn.openehr.org/specification/TRUNK/publishing/architecture/overview.pdf section 10.5). > About the archetype-slot, I will come back to that later. > Maybe it is OK to leave the path just as it is, a path can only be > meaningfull inside a single archetype. Maybe it makes sense to add the > connected arcehtype to the original path of the archetype slot. > While I still don't think there should be paths going inside archetype slots, there is a question of what the path should be when you are talking about a path within a template. This is a bit more complicated to answer because there is no template spec yet, but in general I think the same approach can be taken as with the internal refs.
I have created in-memory flattened AOM representations of templates which add the definition.attributes of the referenced archetype as attributes of a new C_COMPLEX_OBJECT that becomes a sibling of the ARCHETYPE_SLOT. Imagine we did this for a template made from your archetype, with a CLUSTER.address_details.v1 archetype in the details slot. To get to the first item in your address details you'd end up with the path /contacts[at0009]/addresses[at0006]/details[at0001] where the at0001 of details is actually identifying the first one of the items nodes under the definition of a referenced CLUSTER.address_details archetype. Hope that is more helpful than confusing. Lisa > Thanks, > Bert >
