Introduce 'alternativeIds'

[odungern]

When merging models from different tools, the same element has different ids with all likelyhood. We should keep track of original ids, which can be used for searching or updating. As there can be more than one original id, it should be a list.

[oalt]

I agree with this proposal.

[odungern]

In Telco on 2020-01-29 approved. Discussion came up on whether it is useful to include other information such as projectId or tool-name. In this case, the property name could/should be 'sources'. In the end: Yes, there are possible use-cases, but no concrete requirement.

[odungern]

We will implement the option to specify a string specifying an identifier or an object with a mandatory attribute 'id' and other optional information such as 'project'. Implemented with schema v1.0.0, but the constraint check is still to be enhanced.

[odungern]

Just thinking: The consolidation of a resource in the course of integrating two models is conceptually the same as merging two branches. Therefore it is an idea to add the id/key of a consolidated resource to the 'replaces' list instead of an 'alternativeIds' list. However, a consolidated resource is only added to the 'replaces' list once. In contrast, the 'alternativeIds' list keeps the keys of all consolidated resources 'forever', so they can be used to easily find the correct resource in case of an update.

[odungern]

The merge of two branches of the same model and the integration of two different models is similar, but not the same, however:

• merge of two branches: Items with the same ID but different revision numbers are replaced by a common item. The revision of the merged item is noted in 'replaces' once.
• merge of two models: Items with different IDs are replaced by a common item. One ID prevails while the other is noted in 'alternativeIds' from now on. If an update of any of the models is applied at some point in time, either the 'id' or a member of 'alternativeIds' is searched to unambiguously find the right item to update. In fact, alternativeIds can contain not just ids as strings, but also keys (objects consisting of id and revision plus potentially other information like project-id).

[oeichmann]

Concerning the merge of two branches I agree. The item with the older revision should be replaced by the newer one. For bidirectional traceability it is important to keep the ID that was used in the initial model as alternativeid. I would suggest to store the corresponding model or project ID. In case there are multiple initial models, alternativeids can be allocated to the respective models.

[odungern]

Yes, I agree. The current idea ist to allow both simple IDs (strings) or JSON-Objects with several properties, which must include the id of the merged model element and may include revision, project-id and perhaps other properties;

Schema:

    "alternativeIds": {
      "description": "The list of consolidated items which can be used in case a consolidated item shall be updated.",
      "type": "array",
      "items": {
        "description": "A list of pointers to resources resp statements which have been merged to this one.",
        "oneOf": [{
          "description": "A string with a valid identifier of a model-element; where the last revision (i.e. revision=0) is implied.",
          "$ref": "#/definitions/id"
        }, {
          "type": "object",
          "properties": {
            "id": {
              "description": "A string with a valid identifier of a model-element",
              "$ref": "#/definitions/id"
            },
            "revision": {
              "$ref": "#/definitions/revision"
            },
            "project": {
              "description": "A string with a valid project identifier",
              "$ref": "#/definitions/id"
            }
          },
          "required": [ "id" ]
        }]
      }
    },

[odungern]

Implemented in schema v1.0.0, no need for any consistency check.