Hi Lisa, please read my comments below
Lisa Thurston schreef:
> 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.
>
No, it does not matter, the only problem is that must be standardized,
because "path" is an important item to uniquely identify the location of
a node inside an archetype.
Because, as I understand, in internal_ref situations, the
archetype_node_id is not unique.
Because, in my example, (I go back some days)
(excuse my too simple use of ADL)
contact[0005]..........
.........
addresses cardinality matches {0..*; ordered} matches {
ADDRESS[at0006] matches { -- phone number
contact[0009]..........
.........
addresses cardinality matches {0..*; ordered} matches {
use_node ADDRESS /contacts[at0005]/addresses[at0006]
two paths pointing to the ADDRESS object
/contacts[at0005]/addresses[at0006]
and (as I think we agree which is the good thing (a little below in this email))
/contacts[at0009]/addresses[at0006]
In both cases ADDRESS will have the same archetype_node_id: [at0006]
Maybe I misunderstand some small but fundamentally issue:
The path of a CObject, that is connected with a payload of an
Locatable-Object in the persistence-database is important.
Because, (in my opinion) an application must be able to locate a
Locatable-Object inside an archetype, and how can it do that when it has
no unique identifier pointing to location in an archetype
>> 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.
>
To avoid possible misunderstandings, I think:
/contacts[at0009]/addresses[at0006]
will be the best way to define the path for that object (pointed to by a
internal_ref), I think you agree.
If not, please tell me
>> 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).
>
I think it is a good feature when path's are allowed to be meaningful.
They add information to the system. Too bad if this possibility is not
used, except when there are strong arguments against it.
>> 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.
>
My suggestion is that the path needs to go inside the archetype-slot,
because, it is necessary to locate a Locatable to the right context.
Specially because, more and more small parts of archetypes are used, as
building blocs, the connected Locatables can loose their necessary
context, afterwards.
But this is only a suggestion, I am technician, not a
medical-software-architect (I like to keep it that way)
I understand in so far, that I, for the moment, avoid the use of
Archetype_slots, because, it chances are small that I use them in a way
that will later on appear in the specs, and it is possible to avoid the
use, just a bit hairy <http://catb.org/jargon/html/H/hairy.html>.
Thanks
Bert
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071210/c4b53347/attachment.html>
