Peter, I believe this unique name rule should be reviewed and revoked. It is not formally defined, as indicated in your referenced Jira issue its only stated in the architecture overview in the context of paths which assumes name is the unique within a container. I have other examples where it is desirable to get multiple items with the same node-id but not the entire set and name is the obvious collector. It also causes issues in renamed templated items which you still want to allow more than one occurrence of that item. I believe that path predicates are context specific, some times you may want to use event time or entry uid for example, and should not be dictated by the reference model. Heath On 10/01/2012 10:43 PM, "Peter Gummer" <peter.gummer at oceaninformatics.com> wrote:
> Sebastian Garde wrote: > > > A few other functional properties come to mind such as "type" in > PARTY_RELATIONSHIP ... > > Re "type": This is the same as the property "name" (because of the > type_validity invariant) > > Yes, funny you should mention that, Sebastian, because I discovered > yesterday that this is a bug in the spec. As is well known, the "name" must > be unique among siblings within a container. This uniqueness is > incompatible with the PARTY_RELATIONSHIP "type", because it would be common > for a party to have multiple relationships of the same type. > > http://www.openehr.org/issues/browse/SPECPR-54 discusses this. I had to > find a work around for it in my software. I chose to violate the > type_validity invariant: when setting the type, I append a sequential > number to it to set the name; and I compute the type by stripping the > sequential number off the name. This ensures that the name is unique, while > permitting multiple siblings of the same type. > > - Peter > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120112/ed177110/attachment.html>
