Different Id generated in one generated .sysmlx file.

[Orangewithsugar]

Hello SysML Team~

As we can see , the two IDs are different in one same sysmlx file. And the previous one correspons to the id in ISQMechanics.sysmlx, but the latter one can't find in ISQMechanics.sysmlx.
Best regards.

[seidewitz]

Despite both being resolved from the name TorqueValue in the textual notation, according to the specification, the resolution in the import resolves to a different element than the resolution in the context of the alias (or any other regular name resolution). In the case of the import, what is actually imported is the membership relationship (importedMembership), rather than the named element itself. So it is correct that the UUIDs should differ in the two cases.

In the ISQMechanics.sysmlx file, it is actually the second UUID (065547c5-30af-5eae-8779-c9647656fe8f) in your example that you will find as the elementId for TorqueValue. The first UUID should be the ID for the owningMembership of TorqueValue, which is d245a684-572b-492f-83ca-4b1e903a2206. Unfortunately, this is clearly different than the ID referenced in your example.

The problem here is that the library files are loaded by the Pilot Implementation from the textual notation representation, not from the XMI representation. The KerML and SysML specifications provide a deterministic algorithm for computing the UUID of any named element in a standard library file, which is why the UUID for TorqueValue matches the one in the ISQMechanics.sysmlx file. But the specifications do not determine the UUID for unnamed relationships, such as the owningMembership of TorqueValue, so a random UUID is assigned when the ISQMechanics.sysml file is parsed. The only case in which this is an issue is for a membership import such as import ISQ::TorqueValue;.

This is a known issue that we hope to resolve before the KerML and SysML specifications are finalized.

[Orangewithsugar]

Many thanks~