allocate accepts two definitions as its ends (ReferenceSubsetting::referencedFeature must be a Feature)
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 68/100
Research direction
Start by reproducing the two allocate examples from the issue, then trace allocate relationship endpoint resolution and the ReferenceSubsetting validation that types referencedFeature as Feature. Done means definition endpoints produce a diagnostic like sysml-toolkit, while the usage form remains accepted; check the neighboring perform validation for comparison.
Written by the indexing model from the issue text.
Description
Summary
allocate accepts two definitions as its ends (rather than two features/usages) with no diagnostic, even though the ends resolve through ReferenceSubsetting, whose referencedFeature is typed Feature — a Definition is not a Feature. sysml-toolkit rejects the same source.
Version: OpenSysML v0.9.0. sysml-toolkit v0.9.1 with the standard library rejects the same source (see below).
Observed
package P { action def A; part def H; allocate A to H; }
Loads with ok=True and no diagnostic in OpenSysML v0.9.0.
With usages instead of definitions:
package P { part def S { action a : A; part h : H; allocate a to h; } }
loads cleanly in both tools, as expected.
sysml-toolkit v0.9.1 (check --lib <sysml.library>) rejects the definition form:
error: ReferenceSubsetting::referencedFeature must refer to a Feature [relationship-endpoint-metaclass]
OpenSysML already distinguishes definitions from usages in the neighboring perform case — perform A; naming an action definition is (correctly) rejected, since perform must reference a usage — so this looks like an inconsistency in how the same distinction is applied to allocate.
Reference
KerML 1.1 Beta 2, 8.3.3.3.9 ReferenceSubsetting: referencedFeature : Feature {redefines subsettedFeature} — the attribute's declared type is Feature. This section's own Constraints subsection is empty ("None"): there's no separate OCL rule needed, because the requirement is the attribute's own metamodel typing. A part def/action def is a Definition-kind element, not a Feature, so it cannot satisfy referencedFeature's type at all.
SysML v2.0 (formal/2026-03-02), 7.15.2 Allocation Definitions and Usages: the section's own worked example only ever allocates usages (allocate logical.component to physical.assembly inside an allocation definition, and allocate logical ::> system to physical ::> device at usage level) — never two bare definitions.
Note on #95
This is a different claim from #95 ("Subsetting type conformance is not checked"), which your team investigated and correctly closed as not-a-bug for general Subsetting (no type-conformance constraint exists there per KerML 8.3.3.3.10). ReferenceSubsetting's referencedFeature attribute is a different, more basic thing: it isn't asking whether two feature types conform to each other, it's that the referenced element must be a Feature at all, which a Definition structurally is not. We think this survives #95's reasoning, but wanted to flag the connection explicitly rather than have it look like the same question re-asked.
Request
Diagnose an allocate (or any ReferenceSubsetting-based relationship) whose ends are not features, the way sysml-toolkit already does.
- Dominant language
- Go
- Stars
- 24
- Forks
- 5
- Avg merge
- 10h 1m
- Merged PRs (30d)
- 512
Getting set up
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Open-MBEE/OpenSysML
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Maintainers usually reply within 1 day
All issues in Open-MBEE/OpenSysML
Similar issues
-
priority: low 🌱 type: enhancement 💅🏼
Difficulty 2/5 Half a day Newbie friendliness 84/100
nebari-dev/llm-serving-pack#199 ·
Maintainers usually reply within 3 days
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
area/helm kind/bug priority/backlog triage/accepted
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
lexfrei/cloudflare-tunnel-gateway-controller#889 ·
Maintainers usually reply within 1 day
-
bug difficulty: beginner documentation good first issue help wanted localization
Difficulty 1/5 Under an hour Newbie friendliness 90/100
wavefnd/wave-platform#140 ·
-
compiler/runtime
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day