Which UML 2.5.1 semantic variation points affect required stereotype property enforcement during XMI round-trips?

Direct answer

Three Annex C semantic variation points govern this behavior: stereotype application semantics, property constraint evaluation timing, and tagged value serialization semantics. Together they determine whether a tool rejects, warns about, or silently drops a missing required stereotype property during XMI export and import. Because XMI 2.5.1 does not mandate serialization of default or absent required values, the combination of these variation points — not the XMI schema — decides what survives a round-trip.

Confirmed facts vs. likely explanation

Confirmed by the specification: UML 2.5.1 clause 18.3.1 and Annex C explicitly leave stereotype application and property constraint semantics open to the implementation. A compliant tool may enforce required properties at model-edit time, at save/export time, only during explicit validation, or never. XMI 2.5.1 interchange rules do not require that unset required properties be emitted with their default values.

Likely explanation for the divergence you observe: tools that validate only on explicit request will happily export a profiled model with missing tagged values; the importing tool, applying its own policy, then either defaults them, flags them, or discards the stereotype application. Neither tool is non-conformant — the variation points permit all three outcomes. fUML compounds this because it defines no standardized runtime interpretation of Profiles, so executable-model tools add yet another policy layer.

Verifying a target tool's policy without trial-and-error migration

There is no way to read the policy off the tool's conformance claim, but a five-minute probe settles it:

1. Create a minimal profile with one stereotype containing one required property (lower bound 1) of type String, with no default.
2. Apply the stereotype to a Class and deliberately leave the property unset.
3. Export to XMI 2.5.1 and inspect the XML: is the tagged value element present with a synthesized default, present but empty, or absent entirely?
4. Re-import into the same tool and check whether the property is still unset, set to a default, or whether the stereotype application was rejected.
5. Repeat with the tool's explicit validation enabled, and note whether save/export triggers the check or only the validate command does.

The export-time XML inspection is the decisive step: it tells you what the next tool in the chain will actually receive, independent of either tool's UI behavior.

Conformance testing

No vendor-neutral OMG conformance suite exercises Profile interchange across implementations. The closest public effort is the Eclipse Papyrus XMI interoperability test harness, which is community-maintained and does not cover all commercial-tool edge cases. Treat any vendor's "UML 2.5.1 conformant" claim as silent on this specific question.

Practical recommendation

Since UML 2.6 has not resolved these variation points, do not rely on either endpoint enforcing required properties. Instead, run an explicit validation pass before export in the source tool, and add a post-import check (a small script over the XMI, or the target tool's validation API) that asserts every required tagged value is present. This makes the enforcement policy explicit in your pipeline rather than implicit in whichever tool happens to be stricter.