Skip to content

Report only transitions in a parallel state - #24

Open
mbrunnen wants to merge 1 commit into
Open-MBEE:mainfrom
mbrunnen:parallel-state-successions
Open

mbrunnen wants to merge 1 commit into
Open-MBEE:mainfrom
mbrunnen:parallel-state-successions

Conversation

@mbrunnen

@mbrunnen mbrunnen commented Nov 7, 2026

Copy link
Copy Markdown

Fixes #23.

validateStateDefinitionParallelSubactions and
validateStateUsageParallelSubactions now report a parallel state that owns
a transition, and no longer a state that owns a plain succession. SysML 2.0
forbids only transitions there
(8.3.18.5,
8.3.18.6).

How to test

$ cargo test -p sysmlv2-model --lib a_parallel_state_may_own_successions
$ cargo test -p sysmlv2-parser --test integration opensysml::

Look closely at

  • This departs from the Pilot Implementation, which also rejects a
    succession. The opensysml fixtures
    negative/semantic/s33-parallel-state-usage-with-succession.sysml and
    negative/xpect/p19-parallel-state-with-transition.sysml come from its
    reject tests and hold a succession, not a transition. The fixtures are
    unchanged; both baselines record them as unknown now. The probes with a
    transition keep their error.
  • The message changes to "A parallel state cannot own transitions".
  • The CHANGELOG.md entry is under a new Unreleased heading. Move or drop
    it as you prefer.

SysML 8.3.18.5 and 8.3.18.6 forbid incoming and outgoing transitions of
the substates of a parallel state; clauses 7.18.2 and 7.18.3 say the
same. No text forbids a succession, which the rule rejected after the
Pilot Implementation.

The opensysml fixtures s33 and p19 hold a succession and no transition,
so both baselines record them as unknown now.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

check rejects a succession in a parallel state, but SysML forbids only transitions (validateStateDefinitionParallelSubactions)

1 participant