Relax unique name rule in LOCATABLE

Description

Currently LOCATABLE.name values are specified to be unique across sibling LOCATABLE instances e.g. ELEMENTs/CLUSTERs under a CLUSTER, also in the demographic model.

This doesn't correspond well with numerous real world situations.

Activity

Show:
Thomas Beale
September 28, 2015, 4:04 PM
Edited

I've checked the specs, and the only mention of the 'uniqueness' rule is the text at the end of section 11.2.4, i.e. what you see here http://www.openehr.org/releases/BASE/latest/docs/architecture_overview/architecture_overview.html#_data_paths_and_uniqueness

I presume we want to remove these paras, and possibly add a para that just makes it clear that non-uniqueness is OK? That assumes that we don't implement SPECPR-91.

Heath Frankel
November 18, 2015, 11:14 PM

Although I am happy with the paragraph that indicates that "uniqueness of property values of sibling nodes is not required" but to and in-lei of any other means "the only guaranteed unique paths are those based on positional predicates". However, there are still paragraphs that lead to the use of unique names. Although this may be one option I would prefer I would also like to see an alternative approach such as using the LOCATABLE.uid attribute to ensure there is no bias.

openEHR ADM
November 18, 2015, 11:25 PM

Heath, do you mean you effectively want to make the statement in the spec something like:

to properly guarantee unique sibling nodes in a standard way, the uid attribute should be populated.

?

That's probably technically true (if that's what you mean), if we don't trust ../items[3]/events[1]/items[14] kind of paths (i.e. we don't trust ordering).

But I wonder if we should jsut steer clear of saying anything about how to make a unique path in Release 1.0.3, and make some more concrete statements in Rel 1.1...

Heath Frankel
November 19, 2015, 1:01 AM

I would accept the "steer clear" approach or the suggestion to use uid (or name) when it is necessary to have unique paths, but these are implementation decisions.
As we know there are also use cases where we don't want unique paths and want to get collections of multiple occurrences of the same named element.

Perhaps we can provide more guidance in a future release.

Thomas Beale
November 19, 2015, 9:27 AM

TB: fix para at file:///C:/dev/openEHR/specifications-publish/specifications-BASE/docs/architecture_overview/architecture_overview.html#_name_based_predicate
and file:///C:/dev/openEHR/specifications-publish/specifications-BASE/docs/architecture_overview/architecture_overview.html#_data_paths_and_uniqueness

BL: Marand uses UIDs

HF: say that different attributes could be used - name; uid (preferred); otherwise = positional.

Bjorn: name values may be language dependent, not reliable.

Reporter

Thomas Beale

Raised By

Heath Frankel

Components

Affects versions

Configure