AFoletti
commented
7 months ago I agree that having an object with multiple IDs is oftentimes calling for trouble. In this instance (how I currently understand it) however the id is not a model-intern identificator but rather a reference to an ID used in an external system. And how we define which system is allowed to be in the "id" position and which ones go in the "alternateId"?
My alternate proposal is to keep only one "id" attribute but to rename it to "externalId" (or "referenceId" in order to avoid lower l and capital i confusion) in order to make clear that all the delivered IDs are actually references to IDs used by external systems and have no claim to unicity in the context of this model.
lars-steffen
In the current iteration, the id is of type 0261:Identifier which allows an id and a sourceId. It currently has a cardinality of 1-n. This handles a known use case where we need to support IDs from numerous systems, i.e., we need to relate IDs from one system to the next. So, in abstract theory, the definition is correct.
However, depicting an id as a multiplicity is an unfortunate choice when it comes to a solution or implementation architecture by users of the standard.
The proposal recommends:
a. changing the cardinality of id to 1
b. Add an element named alternateId of type Identifier with a cardinality of 0-n. These could also handle the case in which there may be a multiplicity of CAS-Numbers.