On 09/05/2013 10:57 AM, David Moner wrote:
> At the first use_node reference you have to add the target node_id 
> at0007. You don't have to repeat the "items" container attribute at 
> the path, which is substituted by "attribute3", but the target node id 
> has to be used if it is not redefined by a new one, as in the case of 
> "attribute4[at0005]"
>
> [archetype_id]/attribute3[at0007]/items[at0008]/value/value

Yes, I think you are right, David, that seems logical too.
I think you say this because the nodeId of the first following RMObject 
needs to be added, and that is in that case, if not overwritten by the 
use_node, the nodeId in the targetpath.

Thank you very much
Bert
>
>
> 2013/9/5 Bert Verhees <bert.verhees at rosa.nl <mailto:bert.verhees at 
> rosa.nl>>
>
>     On 09/05/2013 09:38 AM, Diego Bosc? wrote:
>>     II would say that you just have to attach the remaining path from
>>     target node to the use_node path, so I would say first option is
>>     the right one
>
>     That seems to me the most logical too.
>
>     Thanks, Diego!
>
>     Bert
>
>>
>>
>>
>>
>>     2013/9/5 Bert Verhees <bert.verhees at rosa.nl
>>     <mailto:bert.verhees at rosa.nl>>
>>
>>         Hi All,
>>
>>         We had a discussion about data-pointds being identified by
>>         archetype-path, not  archetypenode-id.
>>         I agree with that, but I am a bit confused how to do following.
>>
>>         consider following fantasy archetype
>>
>>         ------------------------------------------
>>
>>             Entry[at0000] matches {    -- Encounter
>>                 attribute1 matches {
>>                     SECTION[at0003] occurrences matches {0..1} matches {
>>                         items  cardinality matches {0..*} matches {
>>                             ITEM_LIST[at0007] occurrences matches
>>         {0..1} matches {
>>                                 items existence matches {0..1}
>>         cardinality matches {0..*; unordered; unique} matches {
>>                                     ELEMENT[at0008] occurrences
>>         matches {0..1} matches {
>>                                         value matches {
>>                                             DV_TEXT occurrences
>>         matches {1..1} matches {
>>                                                 value matches {/abc/}
>>                                             }
>>                                         }
>>                                     }
>>                                 }
>>                             }
>>                         }
>>                     }
>>                 }
>>                 attribute3 matches {
>>                     use_node ITEM_LIST /attribute1[at0003]/items[at0007]
>>                 }
>>                 attribute4 matches {
>>                     use_node ITEM_LIST[at0005]
>>         /attribute1[at0003]/items[at0007]
>>                 }
>>
>>         ------------------------------------------
>>
>>         Now I want to know the path in the three ways to the
>>         data-point of value of DV_TEXT
>>
>>         Which one is right, or are all wrong?
>>
>>         
>> [archetype_id]/attribute1[at0003]/items[at0007]/items[at0008]/value/value
>>         [archetype_id]/attribute3/items[at0008]/value/value
>>         [archetype_id]/attribute4[at0005]/items[at0008]/value/value
>>
>>         or we have this (repeat the targetpath also in the path to
>>         the data-point)
>>
>>         
>> [archetype_id]/attribute1[at0003]/items[at0007]/items[at0008]/value/value
>>         [archetype_id]/attribute3/items[at0007]/items[at0008]/value/value
>>         
>> [archetype_id]/attribute4[at0005]/items[at0007]/items[at0008]/value/value
>>
>>         or is it like this (repeat the complete path of the targetpath)
>>
>>         
>> [archetype_id]/attribute1[at0003]/items[at0007]/items[at0008]/value/value
>>         
>> [archetype_id]/attribute3/attribute1[at0003]/items[at0007]/items[at0008]/value/value
>>         
>> [archetype_id]/attribute4[at0005]/attribute1[at0003]/items[at0007]/items[at0008]/value/value
>>
>>         Thanks very much
>>
>>         Bert
>>
>>
>>
>>         _______________________________________________
>>         openEHR-technical mailing list
>>         openEHR-technical at lists.openehr.org
>>         <mailto:openEHR-technical at lists.openehr.org>
>>         
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>>
>>
>>
>>     _______________________________________________
>>     openEHR-technical mailing list
>>     openEHR-technical at lists.openehr.org  <mailto:openEHR-technical at 
>> lists.openehr.org>
>>     
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
>     _______________________________________________
>     openEHR-technical mailing list
>     openEHR-technical at lists.openehr.org
>     <mailto:openEHR-technical at lists.openehr.org>
>     
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
>
>
> -- 
> David Moner Cano
> Grupo de Inform?tica Biom?dica - IBIME
> Instituto ITACA
> http://www.ibime.upv.es
> http://www.linkedin.com/in/davidmoner
>
> Universidad Polit?cnica de Valencia (UPV)
> Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
> Valencia -- 46022 (Espa?a)
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130905/1e5926d8/attachment.html>

Reply via email to