On 03/21/2014 11:48 AM, Diego Bosc? wrote:
> I think that could be related to the parser assuming that Internal
> References have no atxxxx code (which they can according to the
> specifications)
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<Integer> occurrences = new Interval<Integer>(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
>
>
> 2014-03-21 11:43 GMT+01:00 Bert Verhees <bert.verhees at rosa.nl
> <mailto: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
> <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
> 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/79a153c0/attachment-0001.html>
