# ADLParser ArchetypeInternalRef

**URL:** https://discourse.openehr.org/t/adlparser-archetypeinternalref/15613
**Category:** Technical (archive)
**Created:** [21 March 2014 10:43 UTC](https://discourse.openehr.org/t/adlparser-archetypeinternalref/15613 "2014-03-21T10:43:02Z")
**Posts on this page:** 3
**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: [21 March 2014 10:43 UTC](https://discourse.openehr.org/t/adlparser-archetypeinternalref/15613/1 "2014-03-21T10:43:02Z")

</div>

Hi,

I think I found something strange in the ADL-parser.

See following ADL:

`attribute3 matches {`  
`use_node SECTION /items[at0001]`  
`use_node SECTION /items[at0002]`  
`}`  
`attribute4 cardinality matches {0..*} matches {`  
`use_node SECTION[at0006] /items[at0002]`  
`use_node SECTION[at0005] /items[at0001]`  
`}`

The nodes where pointed to, exist, they look like this

`items cardinality matches {0..*} matches {`  
`SECTION[at0001] occurrences matches {0..1} matches {*}`  
`SECTION[at0002] occurrences matches {1..2} matches {*}`  
`}`

When I parse this, I come to following questions

At /attribute3, it only occurs once in the Archetype’s-\>pathNodeMap.  
I think that one entry is overwritten by the next, because the path’s are the same  
This is a faulty entry in the archetype.

But /attribute4 is parsed wrong I think.  
It should occur twice in the pathNodeMap because the path’s shoudl be different.  
But they do not. And that is because the archetype\_node\_id is not taken into account.

There should, in my opinion, have been two paths  
/attribute4[at0006]  
/attribute4[at0007]

So if I am right, there is a bug in the code in ADL.jj which parses internal-refs, it should add the node\_id’s

Can someone please comment on this. Repairing may not be that hard

Thanks  
Bert Verhees

---

<div class="post-metadata">

### Author: ![yampeku](https://discourse.openehr.org/user_avatar/discourse.openehr.org/yampeku/32/25_2.png) [@yampeku](https://discourse.openehr.org/u/yampeku)
#### Post date: [21 March 2014 10:48 UTC](https://discourse.openehr.org/t/adlparser-archetypeinternalref/15613/2 "2014-03-21T10:48:49Z")

</div>

I think that could be related to the parser assuming that Internal References have no atxxxx code (which they can according to the specifications)

---

<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: [21 March 2014 13:00 UTC](https://discourse.openehr.org/t/adlparser-archetypeinternalref/15613/3 "2014-03-21T13:00:06Z")

</div>

The NodeId is detected but it was forgotten to add it to the path, like is done in c\_complex\_object. It was taken into account that there can be a nodeId, and it is read also, but it is forgotten to add it to the path, for example, like is done in c\_complex\_object in adl.jj As I expected, easy to repair. The function archetype\_internal\_ref in adl.jj should be rewritten like this. I tested it. I see that I have the right to do so. So I think, I just do so, if someone complains, it is easy to restore the old version. ArchetypeInternalRef archetype\_internal\_ref(String path, CAttribute parent) : { String type; Interval occurrences = new Interval(1, 1); String target; String nodeID = null; } { \<SYM\_USE\_NODE\> type = type\_identifier() [nodeID = constraint\_ref()] [occurrences = c\_occurrences()] { if(path == null) { path = “/”; } else { path += (nodeID == null ? “” : “[” + nodeID + “]”); } } target = absolute\_path() { return new ArchetypeInternalRef(path, type, occurrences, nodeID, parent, target); } } Thanks Diego I see that
