Reviewing the Archetype.java code, calling Archetype.node(path) will never return a CAttribute node, it only returns CObjects. I think this is a bug because IMO node() should return any kind of ArchetypeConstraint.
Parent: value /content[at0006]/data[at0007]/events[at0002]/data[at0003]/items[at0004]/value
/content[at0006]/data[at0007]/events[at0002]/data[at0003]/items[at0005] ELEMENT
This is a fix for issue #1. Seems to work ok and there are no broken tests.
Below is my test, se "parent" is the CAttribute corresponding to each CObject in the archetype.
You'll see that some paths for CAttributes are the same as the CObject path, this case is when a CObject doesn't have a nodeID. This can be an issue when traversing an archetype, see http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2013-August/008023.html
Reviewing the Archetype.java code, calling Archetype.node(path) will never return a CAttribute node, it only returns CObjects. I think this is a bug because IMO node() should return any kind of ArchetypeConstraint.
Carga desde: archetypes\composition\openEHR-EHR-COMPOSITION.signos.v1.adl / COMPOSITION
This is my test archetype:
archetype (adl_version=1.4) openEHR-EHR-COMPOSITION.signos.v1
concept [at0000] -- Signos language original_language = <[ISO_639-1::es]> description original_author = < ["name"] = <"">
definition COMPOSITION[at0000] matches { -- Signos category matches { DV_CODED_TEXT matches { defining_code matches {[openehr::433]} } } context matches { EVENT_CONTEXT matches { other_context matches { ITEMTREE[at0001] matches {} } } } content cardinality matches {0.._; unordered} matches {
ontology term_definitions = < ["es"] = < items = < ["at0000"] = < text = <"Signos"> description = <"Registro de signos">