> Hi Bert
>
> First I don't think an archetype path that goes inside an ARCHETYPE_SLOT
> is meaningful because from the point of view of an archetype you don't
> know what (if anything) will go into that slot. For an archetype path
> that goes into a referenced node, I think it is helpful to imagine the
> referenced node being completely cloned and replacing the internal ref
> (after all we are dealing with references to constraints here, not
> references to objects). Then the path should be
> <path_to_location_where_ref_is_created>/<sub_path_within_referenced_node>.
> Does that make sense?
Hi Lisa,
Thank you very much for thinking with me about this. It is important for
me to make a good decision, because, at this moment, these days, I am
working on this.
I think it makes sense, it is in fact what I am thinking, it is just that
I need confirmation if it is OK what I am thinking.
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.
So in my example the path would be:
/contacts[at0009]/contacts[at0005]/addresses[at0006]
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?
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.
Thanks,
Bert
>
> Lisa
>
> Bert Verhees wrote:
>> How is the path to an ArchetypeInternalRef constructed so that it is
>> pssible that it points to some ohter point in an archetype, and at the
>> same time is identifiable as being an unique point in the archetype.
>>
>> For example:
>>
>> I have contacts in an archetype, and these have addresses, for
>> efficiency-reasons the addresses are defined only once in the archetype,
>> like this:
>>
>> addresses cardinality matches {0..*; ordered} matches {
>> ADDRESS[at0006] matches { -- phone number
>> type matches {
>> CODED_TEXT matches {
>> code matches {[ac0006]} -- phone
>> number
>> }
>> }
>> details matches {
>> allow_archetype LIST matches {
>> include
>> id matches
>> {"some.other.archetype.*"}
>> }
>> }
>> }
>>
>> In this case the path to details is:
>> /contacts[at0005]/addresses[at0006]/details
>>
>> Then I have this construct
>>
>> addresses cardinality matches {0..*; ordered} matches {
>> use_node ADDRESS /contacts[at0005]/addresses[at0006]
>>
>> The path of addresses will be in this case: /contacts[at0009]/addresses
>> I will, when I dig into this, also have a details-attribute, but what
>> will be the path then of it?
>> Two simple possibilities have disadvantages
>> - replace the first part of the path, like this:
>> /contacts[at0009]/addresses[at0006]/details
>> - do not replace the first part, which leaves the original path of the
>> item referred in tact.
>>
>> The first seems to have disadvantage that the second part of the path is
>> not a followable path, because it makes a jump somewhere in the middle
>> and has no indication that it does.
>>
>> The second solution as bad, because it makes Items to have a non-unique
>> path.
>>
>> So I prefer the first solution, my question, are there any agreements on
>> this, i did not find them. If there are, please excuse me for not
>> looking at the right place.
>> -------------------
>> I also have a related questions, how to construct a path going into an
>> archetype-slot.
>>
>> thanks,
>> Bert Verhees
>>
>> _______________________________________________
>> openEHR-technical mailing list
>> openEHR-technical at openehr.org
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
> --
> Lisa Thurston
> Phone +61.8.8223.3075
> Skype lisathurston
>
> Ocean Informatics Pty Ltd
> Ground floor, 64 Hindmarsh Square
> Adelaide SA 5000
>
> http://www.oceaninformatics.com
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
