I think that could be related to the parser assuming that Internal
References have no atxxxx code (which they can according to the
specifications)
2014-03-21 11:43 GMT+01:00 Bert Verhees <bert.verhees at rosa.nl>:
> 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
>
> _______________________________________________
> 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/20140321/cefd4734/attachment.html>
