Open Orangewithsugar opened 5 months ago
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.
Many thanks~
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.