Hi all, I'm coming back to the flattening problem.
I opened an issue for the null parent problem:
https://github.com/openEHR/java-libs/issues/1This is not a blocker but makes
code more complex since parent should be passed as param to each method that
process an archetype node :-/
As for nodeIDs I will go for changing all the nodeIDs on the flattened
archetype and generate a file of mappings to the original codes, this is
because I can't change nodeID format in AOM java-ref-impl adding something to
resolve nodeID collissions. This issue was a blocker on previous tries:
https://code.google.com/p/openehr-archetype-flattener/.
New code with successful flattening algorithm will be on github soon.
--
Kind regards,
Ing. Pablo Pazos Guti?rrez
http://cabolabs.com
From: pazospa...@hotmail.com
To: ref_impl_java at lists.openehr.org; thomas.beale at oceaninformatics.com
Subject: RE: trying to flat archetypes
Date: Wed, 15 Aug 2012 21:19:52 -0300
Hi Rong,
I was revisiting the specs :)I'm working with ADL 1.4, trying to implement a
suggestion from Thomas: to flat archetype slots preserving the original node
ids.To do so, I need to use the archetype id and the node id to avoid node
conflicts, e.g.
source archetype:COMPOSITION[at0000] matches { -- Medication list
...
content cardinality matches {0..*; unordered} matches {
allow_archetype ACTION occurrences matches {0..*} matches {
include
archetype_id/value matches {/openEHR-EHR-ACTION.medication.v1/}
flat archetype:COMPOSITION[at0000] matches { -- Medication list
...
content cardinality matches {0..*; unordered} matches {
ACTION[openEHR-EHR-ACTION.medication.v1.at0000] matches { -- Medication
action
The flat ADL file is generated without problems.
When I try to load the flatten archetype, the ADL couldn't be parsed. I've
tried several
formats:openEHR-EHR-ACTION.medication.v1.at0000openEHR-EHR-ACTION.medication.v1::at0000openEHR-EHR-ACTION.medication.v1_at0000openEHR-EHR-ACTION_medication_v1_at0000openEHR_EHR_ACTION_medication_v1_at0000
I couldn't find a format constraint in the spects. In the grammar page 105
here: http://www.openehr.org/releases/1.0.2/architecture/am/adl.pdfThere is a
constraint for node ids: [a-zA-Z][a-zA-Z0-9_]* V_IDENTIFIER
(the last format I tried seems to be compliant with this constraint but I still
get an exception when parsing pointing to the node with that id).
Maybe there is a different constraint for node ids implemented in the parser?
Thanks a lot!
--
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos
> Date: Mon, 13 Aug 2012 15:26:03 +0200
> Subject: Re: trying to flat archetypes
> From: rong.acode at gmail.com
> To: ref_impl_java at lists.openehr.org
>
> Hi Pablo,
> It's most likely to do with node_id format. The ADL parser on the
> trunk doesn't really support ADL 1.5 yet.
> Cheers,
> Rong
>
> On 10 August 2012 19:16, pablo pazos <pazospablo at hotmail.com> wrote:
> > Hi Rong,
> >
> > Just a related issue:
> >
> > When flattening archetypes, when resolving slots, I use nodeID with this
> > format: archetypeID::atNNNN.
> > That's to avoid collisions between node ids in the root archetype and node
> > ids of archetypes referenced by slots.
> >
> > When I parse the flat archetype I get an error, it seems there is a
> > constraint on nodeID format.
> >
> > BTW: the flattened ADL was generated by the ADLSerializer.
> >
> >
> > Encountered "ISM_TRANSITION [openEHR-EHR-ACTION.medication.v1::at0018]" at
> > line 47, column 21.
> > Was expecting one of:
> > "}" ...
> > "c_dv_quantity" ...
> > <V_TYPE_IDENTIFIER> "<" ...
> > <V_TYPE_IDENTIFIER> <V_LOCAL_TERM_CODE_REF> ...
> > <V_TYPE_IDENTIFIER> "occurrences" ...
> > <V_TYPE_IDENTIFIER> <SYM_MATCHES> ...
> > "use_node" ...
> > <SYM_ALLOW_ARCHETYPE> ...
> > <V_TERMINOLOGY_ID_BLOCK> ...
> > <V_CODE_PHRASE> ...
> > "+" ...
> > "-" ...
> > <V_INTEGER> ...
> > "C_DV_ORDINAL" ...
> > "true" ...
> > "false" ...
> > <V_ISO8601_DATE_CONSTRAINT_PATTERN> ...
> > <V_DATE> ...
> > "|" ...
> > ...
> >
> >
> > I changed "::" to "_" but I get another exception: (I don't know if this
> > exception has something to do with the nodeID format or with an
> > ISM_TRANSITION having a nodeID)
> >
> > Encountered "ISM_TRANSITION [" at line 47, column 21.
> > Was expecting one of:
> > "}" ...
> > "c_dv_quantity" ...
> > <V_TYPE_IDENTIFIER> "<" ...
> > <V_TYPE_IDENTIFIER> <V_LOCAL_TERM_CODE_REF> ...
> > <V_TYPE_IDENTIFIER> "occurrences" ...
> > <V_TYPE_IDENTIFIER> <SYM_MATCHES> ...
> > "use_node" ...
> > <SYM_ALLOW_ARCHETYPE> ...
> > <V_TERMINOLOGY_ID_BLOCK> ...
> > <V_CODE_PHRASE> ...
> > "+" ...
> > "-" ...
> > <V_INTEGER> ...
> > --
> > Kind regards,
> > Ing. Pablo Pazos Guti?rrez
> >
> >> Date: Thu, 9 Aug 2012 09:44:19 +0200
> >
> >> Subject: Re: trying to flat archetypes
> >> From: rong.acode at gmail.com
> >> To: ref_impl_java at lists.openehr.org
> >>
> >> On 9 August 2012 00:14, pablo pazos <pazospablo at hotmail.com> wrote:
> >> > Hi Rong,
> >> >
> >> > Maybe a second pass top-down can set the parent on each node on the
> >> > parser
> >> > code.
> >>
> >> Yes, that's definitely possible. I will give it a try to see if this
> >> really affects others.
> >>
> >> >
> >> > The problem of the path approach is that if a CObject has no nodeID,
> >> > then
> >> > it's path is equal to the CAttribute path.
> >> > When I do an archetype.node(pathToAttribute) that contains a child with
> >> > no
> >> > nodeID, I get the CObject instead of the CAttribute.
> >> > (BTW: I don't know if this is the expected behaviour)
> >>
> >> >
> >> > Related to this, I saw that on ACTION archetypes, there are sibling
> >> > ISM_TRANSITION nodes that doesn't have a nodeID, violating a rule on the
> >> > specs, but it's getting parsed without problems.
> >>
> >> Right. This should be picked up by archetype-validator after parsing I
> >> believe.
> >>
> >> Cheers,
> >> Rong
> >>
> >> > --
> >> > Kind regards,
> >> > Ing. Pablo Pazos Guti?rrez
> >> >
> >> >> Date: Wed, 8 Aug 2012 22:01:22 +0200
> >> >
> >> >> Subject: Re: trying to flat archetypes
> >> >> From: rong.acode at gmail.com
> >> >> To: ref_impl_java at lists.openehr.org
> >> >>
> >> >> Hi Pablo,
> >> >> I am aware of null parent in the aom objects. The thing is before the
> >> >> aom objects are immutable and during ADL parsing all the objects are
> >> >> built from bottom up so there is no possibility to set parent when
> >> >> building the child. Now immutability is not enforced anymore in aom
> >> >> but I still question the virtue of have such cyclic references in the
> >> >> objects.
> >> >> There are other ways of retrieving the parent, e.g. path based
> >> >> approach. so if the use case isn't sufficient strong, I am bit
> >> >> reluctant to implement it. please let me know how you think.
> >> >> Regards,
> >> >> Rong
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130720/9e517381/attachment.html>
