# syntax path, for itemAtPath

**URL:** <https://discourse.openehr.org/t/syntax-path-for-itematpath/14563>\
**Category:** Implementers (archive)\
**Created:** [22 September 2006 20:44 UTC](https://discourse.openehr.org/t/syntax-path-for-itematpath/14563 "2006-09-22T20:44:22Z")\
**Posts on this page:** 17\
**Page:** 1

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [22 September 2006 20:44 UTC](https://discourse.openehr.org/t/syntax-path-for-itematpath/14563/1 "2006-09-22T20:44:22Z")

</div>

Hi, I cannot find how the path in itemAtPath, which is a part of a  
RMObject is constructed.

For example, I have this archetype

PERSON[at0000] matches { -- simple person  
&nbsp;&nbsp;&nbsp;&nbsp;identities cardinality matches {0..\*; unordered; unique} matches {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;PARTY\_IDENTITY[at0001] matches { -- person name  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;name matches {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;DV\_TEXT matches {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;value matches {"legal identity"}  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;details matches {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ITEM\_LIST[at0002] matches { -- item list  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;representation matches {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Cluster[at0003] matches { --  
representation  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;items cardinality matches {\*; ordered}  
matches {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ELEMENT[at0004] matches { --  
first name  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;value matches {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;DV\_TEXT matches {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;value matches {/.\*/}  
and this code  
System.out.println(person.itemAtPath("/identities[legal  
identity]/details|item list|first name"));

It prints: at0004, first name

How is this path constructed?  
Is there documentation about this?

Thanks  
Bert

---

<div class="post-metadata">

**Author:** ![Heath\_Frankel2](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/h/67e7ee/32.png) [@Heath\_Frankel2](https://discourse.openehr.org/u/Heath_Frankel2)\
**Post date:** [24 September 2006 05:45 UTC](https://discourse.openehr.org/t/syntax-path-for-itematpath/14563/2 "2006-09-24T05:45:47Z")

</div>

Bert,  
Read the openEHR Release 1.0.1 candidate Architecture Overview, Section 11.

The archetype path to the first name based this archetype would be:  
/identities[at0001]/details[at0002]/representation[at0003]/items[at0004]

A run-time path would be something like:  
&nbsp;&nbsp;/identities["legal  
identity"]/details["details"]/details["representation"]/items["first name"]

However, I don't think the lines with "representation matches" is correct.  
I suspect it should be "items matches" seeing that details is an ITEM\_LIST.  
Also I think the Cluster needs to declared because it is implicit in the  
ITEM\_LIST. The Ocean Archetype Editor produces a the following line for an  
ITEM\_LIST:

&nbsp;&nbsp;ITEM\_LIST[at0001] matches { -- structure  
&nbsp;&nbsp;&nbsp;&nbsp;items cardinality matches {0..1; ordered} matches {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ELEMENT[at0005] ...

Based on this the representation the path would then be:  
&nbsp;&nbsp;/identities[at0001]/details[at0002]/items[at0004]  
and  
&nbsp;&nbsp;/identities["legal identity"]/details["details"]/items["first name"]

Additionally, you can see some of these predicates are redundant so you  
could simply have:  
&nbsp;&nbsp;/identities[at0001]/details/items[at0004]  
and  
&nbsp;&nbsp;/identities["legal identity"]/details/items["first name"]

Ocean use a combination of archetype and run-time paths in our Kernel and  
query language. For example if there where more than one party identity  
purpose such as "alias" we would have a path of:  
&nbsp;&nbsp;/identities[at0001 and name/value="alias"]/details/items[at0004]

We are also looking at a shortened representation of this combination,  
something like the following:  
&nbsp;&nbsp;/identities[at0001, "alias"]/details/items[at0004]

Your constraint to set the identity name to "legal identity" should more  
correctly be put on the Purpose attribute of PARTY\_IDENTITY. However, this  
name constraint is still valid and useful if you are only ever going to have  
one PARTY\_IDENTITY for the purpose of legal identity so that there is  
decision required about what name to use.

Hope this helps.

Regards

Heath

Heath Frankel  
Product Development Manager  
Ocean Informatics

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [24 September 2006 09:18 UTC](https://discourse.openehr.org/t/syntax-path-for-itematpath/14563/3 "2006-09-24T09:18:04Z")

</div>

Heath Frankel wrote:

> Bert,  
> Read the openEHR Release 1.0.1 candidate Architecture Overview, Section 11.
> 
> The archetype path to the first name based this archetype would be:  
> /identities[at0001]/details[at0002]/representation[at0003]/items[at0004]
> 
> A run-time path would be something like:  
> &nbsp;&nbsp;/identities["legal  
> identity"]/details["details"]/details["representation"]/items["first name"]  
> &nbsp;&nbsp;

we should be implementing paths so that no predicate is needed for  
single-valued attributes, like "history", "representation" etc....

> However, I don't think the lines with "representation matches" is correct.  
> I suspect it should be "items matches" seeing that details is an ITEM\_LIST.  
> Also I think the Cluster needs to declared because it is implicit in the  
> ITEM\_LIST. The Ocean Archetype Editor produces a the following line for an  
> ITEM\_LIST:
> 
> &nbsp;&nbsp;ITEM\_LIST[at0001] matches { -- structure  
> &nbsp;&nbsp;&nbsp;&nbsp;items cardinality matches {0..1; ordered} matches {  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ELEMENT[at0005] ...
> 
> Based on this the representation the path would then be:  
> &nbsp;&nbsp;/identities[at0001]/details[at0002]/items[at0004]  
> and  
> &nbsp;&nbsp;/identities["legal identity"]/details["details"]/items["first name"]
> 
> Additionally, you can see some of these predicates are redundant so you  
> could simply have:  
> &nbsp;&nbsp;/identities[at0001]/details/items[at0004]  
> and  
> &nbsp;&nbsp;/identities["legal identity"]/details/items["first name"]
> 
> Ocean use a combination of archetype and run-time paths in our Kernel and  
> query language. For example if there where more than one party identity  
> purpose such as "alias" we would have a path of:  
> &nbsp;&nbsp;/identities[at0001 and name/value="alias"]/details/items[at0004]
> 
> We are also looking at a shortened representation of this combination,  
> something like the following:  
> &nbsp;&nbsp;/identities[at0001, "alias"]/details/items[at0004]  
> &nbsp;&nbsp;

hm - sounds a bit dangerous - how does the query processor infer what  
attirbute "alias" corresponds to?

- thomas

---

<div class="post-metadata">

**Author:** ![Heath\_Frankel2](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/h/67e7ee/32.png) [@Heath\_Frankel2](https://discourse.openehr.org/u/Heath_Frankel2)\
**Post date:** [24 September 2006 09:59 UTC](https://discourse.openehr.org/t/syntax-path-for-itematpath/14563/4 "2006-09-24T09:59:27Z")

</div>

Tom,  
Re: implementation single value attributes without predicates is what I  
described down further. Is there anything in the specs that state this? I  
don't remember anything in the Architecture Overview section on paths.

Re: the archetype/runtime path shortcut, in discussions with Sam we came to  
the conclusion that these predicates would always be associated with the  
name attribute and that having a predicate like /identities[at0001 and  
name/value="alias"] is rather verbose, especially when you have a full path  
going through sections, entries, events where you end up with 3 or 4  
predicates in one path it is just not workable. I know you would say that  
these are not intended for humans and only for computers but they say that  
about XML and that one of the favourite topics of techies is to argue the  
XML form of some data. Additionally, there will be humans working with  
these, and I and my team have been for several months for several artefacts  
including Queries, Templates and Feeder System mappings. Sure this will be  
reduced as tooling support is increased but there will always be some that  
will want to work with a path or perhaps even displaying one within a tool.  
Our Feeder Source Mapping Tool currently works by displaying paths and some  
don't fit on a 1024x768 screen, that's scary!

Anyway, if the conclusion that the runtime paths will not always be the name  
and there is an exception to that rule for certain classes, I am sure we  
could still use the [archtype\_node\_id, "key"] shortcut if we standardise the  
key attribute on each class. My vote is certainly for name everywhere.

The question I have, is this combination of archetype/run-time path legal?  
It is not currently documented in the Architecture Overview and I think it  
should be. The use of archetype paths are no good for run-time instance due  
to the lack of identifying multiple occurrences while the run-time paths are  
too subjective and will not be semantically interoperable. The combination  
is essential.

Regards

Heath

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [24 September 2006 10:32 UTC](https://discourse.openehr.org/t/syntax-path-for-itematpath/14563/5 "2006-09-24T10:32:13Z")

</div>

Heath Frankel wrote:

> Tom,  
> Re: implementation single value attributes without predicates is what I  
> described down further. Is there anything in the specs that state this? I  
> don't remember anything in the Architecture Overview section on paths.  
> &nbsp;&nbsp;

I think you are right - I will have to look into this....

> Re: the archetype/runtime path shortcut, in discussions with Sam we came to  
> the conclusion that these predicates would always be associated with the  
> name attribute and that having a predicate like /identities[at0001 and  
> name/value="alias"] is rather verbose, especially when you have a full path  
> &nbsp;&nbsp;

I am not convinced by this - there will definitely be predicates  
referring to attributes other than the name attribute..

> going through sections, entries, events where you end up with 3 or 4  
> predicates in one path it is just not workable.

It's just longer isn't it?

> &nbsp;&nbsp;I know you would say that  
> these are not intended for humans and only for computers but they say that  
> about XML and that one of the favourite topics of techies is to argue the  
> XML form of some data.

but a query-building tool will mean that humans indeed never see  
this...or not often (I think paths are more or less readable, in a  
little path-editing tool, just as XML becomes readable when you strip  
the garbage and present it nicely).

> Additionally, there will be humans working with  
> these, and I and my team have been for several months for several artefacts  
> including Queries, Templates and Feeder System mappings. Sure this will be  
> reduced as tooling support is increased but there will always be some that  
> will want to work with a path or perhaps even displaying one within a tool.  
> Our Feeder Source Mapping Tool currently works by displaying paths and some  
> don't fit on a 1024x768 screen, that's scary!  
> &nbsp;&nbsp;

do you mean if they are shown as a single line of text? I think that's  
just a case of a simple path display tool...

> Anyway, if the conclusion that the runtime paths will not always be the name  
> and there is an exception to that rule for certain classes, I am sure we  
> could still use the [archtype\_node\_id, "key"] shortcut if we standardise the  
> key attribute on each class. My vote is certainly for name everywhere.
> 
> The question I have, is this combination of archetype/run-time path legal?  
> &nbsp;&nbsp;

well, there are no "archetype" and "run-time" paths any more in any  
syntax sense - it's all just the one syntax; it's just that the  
predicate is longer for runtime data. I'll have to review the  
documentation to see if it makes this clear enough...

> It is not currently documented in the Architecture Overview and I think it  
> should be. The use of archetype paths are no good for run-time instance due  
> to the lack of identifying multiple occurrences

actually, that isn't true; archetype paths (paths containing only  
[atnnnn] as predicates) are probably likely to be used at least as often  
as ones with longer predicates, since they correctly return all members  
of a container, which is often what you want.

> while the run-time paths are  
> too subjective and will not be semantically interoperable.

How can a path based on the reference model be "subjective"?

- thomas

---

<div class="post-metadata">

**Author:** ![Heath\_Frankel2](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/h/67e7ee/32.png) [@Heath\_Frankel2](https://discourse.openehr.org/u/Heath_Frankel2)\
**Post date:** [24 September 2006 11:46 UTC](https://discourse.openehr.org/t/syntax-path-for-itematpath/14563/6 "2006-09-24T11:46:20Z")

</div>

Tom,

> while the run-time paths are  
> too subjective and will not be semantically interoperable.

TB: How can a path based on the reference model be "subjective"?

The name can be changed at runtime, to anything.

Heath

---

<div class="post-metadata">

**Author:** ![Heath\_Frankel2](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/h/67e7ee/32.png) [@Heath\_Frankel2](https://discourse.openehr.org/u/Heath_Frankel2)\
**Post date:** [24 September 2006 12:20 UTC](https://discourse.openehr.org/t/syntax-path-for-itematpath/14563/7 "2006-09-24T12:20:56Z")

</div>

Tom,

> Re: the archetype/runtime path shortcut, in discussions with Sam we  
> came to the conclusion that these predicates would always be  
> associated with the name attribute and that having a predicate like  
> /identities[at0001 and name/value="alias"] is rather verbose,  
> especially when you have a full path  
> &nbsp;&nbsp;

TB: I am not convinced by this - there will definitely be predicates  
referring to attributes other than the name attribute..

Ok, for more general queries yes, for ItemAtPath it will "normally" be  
archetype\_node\_id and name/value. So a shortcut for this combination would  
be useful. All other attributes can still be done in long-hand.

> going through sections, entries, events where you end up with 3 or 4  
> predicates in one path it is just not workable.

TB: It's just longer isn't it?

Yeah, long than the width of the screen (well pretty close :\>)

> &nbsp;&nbsp;I know you would say that  
> these are not intended for humans and only for computers but they say  
> that about XML and that one of the favourite topics of techies is to  
> argue the XML form of some data.

TB: but a query-building tool will mean that humans indeed never see  
this...or not often (I think paths are more or less readable, in a little  
path-editing tool, just as XML becomes readable when you strip the garbage  
and present it nicely).

Developers will still work with them, designers may not (or shouldn't have  
too), just like XML.

> Additionally, there will be humans working with these, and I and my  
> team have been for several months for several artefacts including  
> Queries, Templates and Feeder System mappings. Sure this will be  
> reduced as tooling support is increased but there will always be some  
> that will want to work with a path or perhaps even displaying one within a

tool.

> Our Feeder Source Mapping Tool currently works by displaying paths and  
> some don't fit on a 1024x768 screen, that's scary!  
> &nbsp;&nbsp;

TB: do you mean if they are shown as a single line of text? I think that's  
just a case of a simple path display tool...

We will use paths all over the place, most of the Ocean tools developed so  
far use them and display them on one line. We have one that has a path in a  
column of a grid with another 5 or so columns including one that contains an  
XPath expression as well. Pretty hard to display a path in a grid without  
doing it in one line. Then we have a tool tip pop up to display the whole  
path because you can't see more than the first predicate and it extends past  
the bounds of the screen/ You don't have much control over some of these  
existing GUI components.

> Anyway, if the conclusion that the runtime paths will not always be  
> the name and there is an exception to that rule for certain classes, I  
> am sure we could still use the [archetype\_node\_id, "key"] shortcut if  
> we standardise the key attribute on each class. My vote is certainly for

name everywhere.

> The question I have, is this combination of archetype/run-time path legal?  
> &nbsp;&nbsp;

TB: well, there are no "archetype" and "run-time" paths any more in any  
syntax sense - it's all just the one syntax; it's just that the predicate is  
longer for runtime data. I'll have to review the documentation to see if it  
makes this clear enough...

Perhaps I need to re-read the latest but the last candidate version I read  
still talked about archetype paths and run-time paths. In fact looking the  
latest on SVN, I see section 11.2.2 discussing Predicate Expressions and  
then section 11.2.4 Runtime Paths and Uniqueness. At least in the former  
you do talk about archetype and run-time predicates (mainly for query  
purposes) but in the later you only talk about using name/value to ensue  
uniqueness (except for integer positions).

BTW, you suggest in your examples that the combinatorial expressions use an  
uppercase 'AND'. In XPath only a lowercase 'and' is legal, at least in the  
XML tools I use. I suggest openEHR paths should be consistent with XPath  
here.

Heath

---

<div class="post-metadata">

**Author:** ![Heath\_Frankel2](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/h/67e7ee/32.png) [@Heath\_Frankel2](https://discourse.openehr.org/u/Heath_Frankel2)\
**Post date:** [24 September 2006 13:02 UTC](https://discourse.openehr.org/t/syntax-path-for-itematpath/14563/8 "2006-09-24T13:02:24Z")

</div>

(Unless constrained by the archetype)

> while the run-time paths are  
> too subjective and will not be semantically interoperable.

TB: How can a path based on the reference model be "subjective"?

HF: The name can be changed at runtime, to anything.

---

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [24 September 2006 13:28 UTC](https://discourse.openehr.org/t/syntax-path-for-itematpath/14563/9 "2006-09-24T13:28:43Z")

</div>

Thank you, Gentleman for your discussion. It is very helpful, the  
documentation also is.

But I have 2 additional questions.

---

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [24 September 2006 19:27 UTC](https://discourse.openehr.org/t/syntax-path-for-itematpath/14563/10 "2006-09-24T19:27:44Z")

</div>

> 1) How does the path "know" what is meant by "legal identity"?  
> 2) Why is a "/" (slash) after /identities[legal identity]  
> and a "|" (pipeline) after details?  
> &nbsp;&nbsp;

The second question I found, it is because everything, in 0.95  
java-kernel inherits from org.openehr.rm.datastructure.DataStructure  
has to deal with public static final String PATH\_SEPARATOR = "|";

thanks  
Bert

---

<div class="post-metadata">

**Author:** ![Heath\_Frankel2](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/h/67e7ee/32.png) [@Heath\_Frankel2](https://discourse.openehr.org/u/Heath_Frankel2)\
**Post date:** [24 September 2006 23:06 UTC](https://discourse.openehr.org/t/syntax-path-for-itematpath/14563/11 "2006-09-24T23:06:42Z")

</div>

Bert  
1) How does the path "know" what is meant by "legal identity"?

> From my point of view, there is no semantics that you can derive from the

name attribute as its value is not reliable, in general. Meaning comes from  
the archetype\_node\_id and in the case of your PARTY\_IDENTITY case it is the  
value of the PARTY\_IDENTITY.purpose attribute. It just happens in your case  
that you have set the name to the same value as what the purpose attribute  
should be and constrained it in the archetype that it will always be that  
value. The name is just for uniquely identifying a node and perhaps  
providing a bit more human friendly display than archetype node ids.  
However in our implementations, the later is being comprised in favour of  
the former, which I think is a problem.

Heath

---

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [25 September 2006 09:11 UTC](https://discourse.openehr.org/t/syntax-path-for-itematpath/14563/12 "2006-09-25T09:11:45Z")

</div>

Heath Frankel schreef:

> Bert  
> 1) How does the path "know" what is meant by "legal identity"?
> 
> \>From my point of view, there is no semantics that you can derive from the  
> name attribute as its value is not reliable, in general. Meaning comes from  
> the archetype\_node\_id and in the case of your PARTY\_IDENTITY case it is the  
> value of the PARTY\_IDENTITY.purpose attribute. It just happens in your case  
> that you have set the name to the same value as what the purpose attribute  
> should be and constrained it in the archetype that it will always be that  
> value. The name is just for uniquely identifying a node and perhaps  
> providing a bit more human friendly display than archetype node ids.  
> However in our implementations, the later is being comprised in favour of  
> the former, which I think is a problem.  
> &nbsp;&nbsp;  
> Thanks Heath, for your explanation, as I understand, this is happens,  
> please correct me if I am wrong. I am all day debugging in Eclipse, and  
> I tell you, it is not a pleasure, it is very unstable for debugging  
> purposes (I am used to better). But I am glad it is possible to debug.

I have a few fractions of the ADL I use in this case, a definition part  
and a ontology part. As you may notice, it is old ADL, but it is what I  
use at this moment, and I can live with that for now.

---

<div class="post-metadata">

**Author:** ![Heath\_Frankel2](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/h/67e7ee/32.png) [@Heath\_Frankel2](https://discourse.openehr.org/u/Heath_Frankel2)\
**Post date:** [25 September 2006 09:24 UTC](https://discourse.openehr.org/t/syntax-path-for-itematpath/14563/13 "2006-09-25T09:24:41Z")

</div>

Sorry Bert, I have no knowledge how the Java Kernel works. My answers were  
based on the my understanding of openEHR paths and the Ocean .NET Kernel  
implementation.

Heath

---

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [25 September 2006 09:35 UTC](https://discourse.openehr.org/t/syntax-path-for-itematpath/14563/14 "2006-09-25T09:35:00Z")

</div>

Maybe Rong is willing to explain this

thanks  
Bert

Heath Frankel schreef:

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [25 September 2006 23:07 UTC](https://discourse.openehr.org/t/syntax-path-for-itematpath/14563/15 "2006-09-25T23:07:52Z")

</div>

Heath Frankel wrote:

> Anyway, if the conclusion that the runtime paths will not always be the name  
> and there is an exception to that rule for certain classes, I am sure we  
> could still use the [archtype\_node\_id, "key"] shortcut if we standardise the  
> key attribute on each class. My vote is certainly for name everywhere.
> 
> The question I have, is this combination of archetype/run-time path legal?  
> It is not currently documented in the Architecture Overview and I think it  
> should be. The use of archetype paths are no good for run-time instance due  
> to the lack of identifying multiple occurrences while the run-time paths are  
> too subjective and will not be semantically interoperable. The combination  
> is essential.

Heath,  
So the question really is: what is an appropriate shortcut syntax for  
[@archetype\_node\_id='at0001' and name/value='something'] isn't it? You  
are suggesting [at0001, 'something']; why not keep the "and"? Is it  
always "and"? Also, I thought XPath used single quotes - do we have this  
wrong in the documentation?

- thomas

---

<div class="post-metadata">

**Author:** ![Heath\_Frankel2](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/h/67e7ee/32.png) [@Heath\_Frankel2](https://discourse.openehr.org/u/Heath_Frankel2)\
**Post date:** [26 September 2006 00:36 UTC](https://discourse.openehr.org/t/syntax-path-for-itematpath/14563/16 "2006-09-26T00:36:37Z")

</div>

Tom,  
Exactly. I don't see any value in keeping the 'and', for uniquely  
identifying a repeating item with the same archetype node id using the name  
value it will always be 'and'.

My XML tools support both single and double quotes for string values in  
predicates.

Heath

---

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [27 September 2006 08:10 UTC](https://discourse.openehr.org/t/syntax-path-for-itematpath/14563/17 "2006-09-27T08:10:32Z")

</div>

> Bert thank you, Gentleman for your discussion. It is very helpful, the  
> documentation also is.

Sorry for the delay, Bert. Please find my comments below.

> ## But I have 2 additional questions.
> 
> Explain:  
> I shortly explain my situation. I am working in kernel version 0.95,  
> because of Time Pressure I cannot change this at this moment. I will in  
> one month, I am looking forward to this moment. But now I cannot, and  
> don’t know if the Java-version 1.0.1 is ready and stable? And there is  
> no persistent-layer, I have to write myself, which is not hard, but  
> within the short time I have not possible for me to do. I have a  
> persistent layer for 0.95 version. That is why I am stuck tot this  
> version right now.
> 
> ## So please allow me a short question about the 0.95 version (after a bit longer introduction).
> 
> Introduction:  
> I indeed use the ItemAtPath-function as a query-language, like this.  
> If it is not the best way to do, please tell me. I am finding out these  
> things myself.

We used this approach to query any single value from RM objects in our application.  
It worked quite well for that purpose. What you want to do is perhaps externalize the  
path so you could keep in sync with the archetype.

> For example, to retrieve a persons first name, I do this
> 
> ((Element)person.itemAtPath(“/identities[legal identity]/details|item  
> list\>first name”)).getValue().toString()

This code looks familiar 😉

> I get the itemAtPath, which is of type Locatable, and I cast it to  
> Element, and from a Element I can ask the value.
> 
> I also use a Object Oreinted query-way, like this  
> for (Iterator it=person.getIdentities().iterator(); it.hasNext(); ){  
> PartyIdentity partyidentity = (PartyIdentity)it.next();  
> for (Iterator  
> it2=((Cluster)partyidentity.getDetails().getRepresentation()).getItems().iterator();  
> it2.hasNext(); ) {  
> Element element = (Element)it2.next();  
> element.getValue().toString()  
> }  
> }
> 
> ## As you will understand, the “path”-way is much more convenient, an additional advantage of the path way is that it can easily be contructed in runtime.
> 
> Question (2 small questions):  
> So the path I query is: /identities[legal identity]/details|item  
> list\>first name  
> As you can see there are differences in the syntax, described in the  
> document. Maybe it is because I use an older kernel-version.

Try to find 0.95 RM specifications, there you will find the syntax for all these  
path and indeed these were slightly different from each other.

Cheers,  
Rong