Add a node id to LOCATABLE so that child objects can be uniquely identified without relying on the name field. This would enable paths to be constructed to any object in data. The original idea was sibling_id an integer unique just across sibling child nodes. This would enable unique runtime path formation in a regular way, regardless of the type of RM class, as long as it inherits from LOCATABLE. In theory, the uid field could be used, but this creates a real overhead of GUIDs in storage and in paths which is arguably too heavy.
In a discussion with Borut, Bostjan, Bjorn, TB: we thought the most lightweight approach to adding unique ids to nodes is to add something we might call 'sequence_number' i.e. a short integer that only ever increases, and is assigned when a child node is added. If a child node is deleted in a subsequent version, the ids remain the same; if a new node is added in a new version, its sequence_nr is the current highest + 1.
This avoids the heavy penalty of universal use of Guids on all LOCATABLEs, and still provides a reliable basis for paths and thus URIs and LINKs.
The sequence_nr could be unique just across siblings, but Bostjan proposes that they are unique across the whole COMPOSITION. This means a COMPOSITION Guid + the sequence_nr uniquely identifies any node. To make this work, the current sequence number has to be recorded at runtime at the root of the COMPOSITION as meta-data.
I am not in favour of needing to label every node or using accession numbers. If we want a short id, then why wouldn't we use the XML id/idref approach, which is also only used when necessary?
@Heath can you elaborate how the id/id-ref approach would apply to an object reference model?
We do have some use-cases where the exact order of multiple locatables is important e.g sequential dose/amount timings. Right noew we are hard-wiring a sequence number into the archetypers.
Would the sequence number proposed here be safe enough to use for that requirement?
I'm pretty sure that just to have a correct specialization mechanism we need to have node id on the data types (if you can redefine them you should be able to precisely point to what is changed)
edit: wrong thread, but I left it as maybe is also a factor to be taken into account