Skip to Navigation | Skip to Content

Ref_impl_Java mailing list archives

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

RE: Adding a new method to the Archetype class


Hi Thomas,

I think I understand your point and Rong's too, but I have some questions to you both.

If one constraint is reused inside the same archetype, all constraints with the same nodeID will be semantically equivalent, is this correct? So, in terms of semantics RM validation against an archetype node it will be the same if I check to one node or another (that have the same nodeID). I think this "post rm creation" kind of validation against an archetype is needed to make semantic interoperability work. May be my solution is not the optimal, but I think some kind of openehr protocol to do this is needed. For Rong's point I suppose that if I have a RM node that don't have a nodeID, this node must be a primitive node, because for ELEMENT, CLUSTER and ITEM_STRUCTURE, ENTRY, SECTION, etc, I think all had to have a nodeID. Correct me if I'm wrong.

Off topic: I've talked to Thomas telling him I've problems with Internal Refs nodeIDs, because when I load an ADL created by the Oceans Archetype Editor using the ADL parser from Java Ref Impl project, the nodeID attribute of the internal refs is null, I don't know if this is a problem with the editor or is a problem with the parser. I can send you my test archetype to help you to take a look to this issue.

Thanks a lot.

Best regards,
Pablo.



Date: Thu, 28 Jan 2010 23:54:11 +0000
From: thomas.beale@oceaninformatics.com
To: ref_impl_java@openehr.org
Subject: Re: Adding a new method to the Archetype class

On 28/01/2010 23:07, Rong Chen wrote:
Pablo,

If each node has a unique id, this would work. But it's not guaranteed
that each node will have a id. Some leaf level nodes do not have any
node id at all. They will have to be located by path e.g.
"/items[at0001]/value"

  


not only that, but some node_ids get legitimately re-used. For example, any archetype with an internal reference will create nodes having the same node id, but different parent paths. And there is nothing wrong with using one node id (e.g. at0004 = systolic pressure) in two places, e.g. a node under another node whose meaning is 'measured BP' and secondly a node under a node whose meaning is 'target BP'.

Paths are the keys in openEHR - they are like pre-coordinated expressions. Have a look at the paths in an archetype like BP or Apgar in the ADL workbench path view.

- thomas beale


Hotmail: Trusted email with Microsoft’s powerful SPAM protection. Sign up now.
_______________________________________________
Ref_impl_java mailing list
Ref_impl_java@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/ref_impl_java