Add a unique node id to LOCATABLE so that child objects can be uniquely identified without the name field

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

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?

@Heath can you elaborate how the id/id-ref approach would apply to an object reference model?

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?

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.