KERML_ — KerML Libraries' elements shall have an elementId defined

The way KerML libraries are provided relies on textual notation files on which element declarations do not include the specification of their elementId property.

As consequence, if the elementId is actually generated by the tool, as written in the KerML specification (p226), it is very likely to have a different value from one computer to another and even from one loading to another on the same computer.

Hence, it is impossible to make sure it will "not change during the lifetime of the Element", as required by in the same paragraph of that specification.

Note: a similar issue will be raised on SysMLv2

Create UUID based on unique path

This resolution introduces the concept of a "path" for an element that is unique within the composition structure under a specific root namespace. This path can then be used instead of the qualified name to generate a distinct UUID for every element in a standard library model, not just the ones with non-null qualified name. The element path is constructed as follows:

1. If the element has a non-null qualified name, that is used as the path. This means that the UUIDs generated for elements with non-null qualified names will remain unchanged from previous versions of the normative library models.
2. If the element has a null qualified name and a non-null owning relationship, then its path is constructed from the path of its owning relationship by appending the character "/", followed by its position in the list of owned related elements of it owning relationship.
3. If the element is a relationship with a non-null owning related element (except for an owning membership as below), then its path is instead constructed from the path of its owning related element by appending the character "/", followed by its position in the list of owned relationships of it owning related element.
4. If the element is an owning membership whose owned member element has a non-null qualified name, then its path is constructed from the qualified name of its owned member element by appending the string "/owningMembership". Since owning memberships are one-to-one with their owned member elements, this allows owning memberships of named elements in library models to remain stable even if there is a reordering of member elements within the owning namespace.

The following shows some examples of element paths:

// Path of package: TopLevel
// Path of owning membership: TopLevel/owningMembership
package TopLevel {

    // Path of classifier: TopLevel::A
    // Path of owning membership: TopLevel::A/owningMembership
    classifier A;

    // Path of classifier: TopLevel::B
    // Path of owning membership: TopLevel::B/owningMembership
    // Path of owned subclassification: TopLevel::B/1
    classifier B specializes A;
        // Path of owning membership: TopLevel::B/2
        // Path of feature:  TopLevel::B/2/1
        feature;
    }

    // Path of owning membership: TopLevel/3
    // Path of classifier: TopLevel/3/1
    classifier {
        // Path of owning membership: TopLevel/3/1/1
        // Path of feature: TopLevel/3/1/1/1
        feature f;
    }
}

The resolution also revises the derivation for qualifiedName so that, if there are multiple owned members in a namespace with the same name, all but the first of these have a null qualifiedName. While the validateNamespaceDistinguishability constraint makes it invalid for a namespace to have duplicate names, the revised derivation for qualifiedName ensures that no two elements have the same qualified name, even for models that violate the constraint. This eliminates the possibility of different elements with the same qualified name getting the same generated UUID.