Further to my previous email, I believe the original intent of the name attribute is a form caption of an element value, the approach of adding a numeric suffix to provide a unique key is contrary to this original intent. Btw, another example of multiple names values conflict with this unique name rule is multiple alias party-identity occurences, in fact anywhere where you use a coded name such as a lab observation with multiple occurrences. Adding a suffix makes the value different to the code rubric, which frowned upon in terminology circles.
Heath On 11/01/2012 11:25 PM, "Heath Frankel" <heath.frankel at oceaninformatics.com> wrote: > 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/4674a530/attachment.html>
