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.
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.
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.
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/events/items 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...
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.
TB: fix para at file:///C:/dev/openEHR/specifications-publish/specifications-BASE/docs/architecture_overview/architecture_overview.html#_name_based_predicate
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.