Accept, assignment, perform, if, while and for actions are reported as plain `ActionUsage`, and a succession flow as plain `FlowUsage`

Aperta
  • Qualcosa non va?
#2,008 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
go, python
Ambito
backend-api-design

Direzione di ricerca

Start with internal/semantic/symbols/symbol.go for the Symbol kind vocabulary, then trace how parsed action and flow declarations receive their query metaclasses and symbol kinds. Use the reproductions in the issue and the C20/B20 cases in test-suite/data/models/C20.sysml and B20.sysml to check each action and succession flow. Done means the query API reports the expected metaclasses and the Symbol API reports matching kinds.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug spec compliance

This issue was written with AI help. The model and the reproduction were run against the version below.

What happened

#1985 reported that a send action is reported as a plain ActionUsage, and #1992 fixes that for SendActionUsage. The same happens to every other kind of action node, and to succession flows. Both the Symbol API and the query API report the generic kind:

package P {
    private import ScalarValues::*;
    attribute def Sig;
    item def Fuel;
    port def SigPort;
    part def Tank { out item fuelOut : Fuel; }
    part def Engine { in item fuelIn : Fuel; }
    action def Notify;
    action def A {
        in sig : Sig;
        in p : SigPort;
        attribute count : Integer;
        action sendIt send sig via p;
        action acceptIt accept s : Sig via p;
        action assignIt assign count := 1;
        perform action performIt : Notify;
        action ifIt if count > 0 { action body1; }
        action whileIt while count < 3 { action body2; }
        action forIt for i : Integer in (1, 2, 3) { action body3; }
    }
    part def Vehicle {
        part tank : Tank;
        part engine : Engine;
        flow f of Fuel from tank.fuelOut to engine.fuelIn;
        succession flow sf of Fuel from tank.fuelOut to engine.fuelIn;
    }
}

import opensysml
m = opensysml.loads(SRC)            # m.ok is True, no diagnostics
types = {e.id: e.type for e in m.query({"@type": "Query"})}
for n in ["A::sendIt", "A::acceptIt", "A::assignIt", "A::performIt",
          "A::ifIt", "A::whileIt", "A::forIt", "Vehicle::f", "Vehicle::sf"]:
    qn = "P::" + n
    print(qn, m.get(qn).kind, types[qn])

P::A::sendIt     actionUsage  ActionUsage     (#1985)
P::A::acceptIt   actionUsage  ActionUsage
P::A::assignIt   actionUsage  ActionUsage
P::A::performIt  actionUsage  ActionUsage
P::A::ifIt       actionUsage  ActionUsage
P::A::whileIt    actionUsage  ActionUsage
P::A::forIt      actionUsage  ActionUsage
P::Vehicle::f    flowUsage    FlowUsage
P::Vehicle::sf   flowUsage    FlowUsage

A client therefore cannot tell an accept from an assignment or a loop, or a succession flow from an ordinary flow. The Symbol kind vocabulary in internal/semantic/symbols/symbol.go has no entry for any of these kinds. The results are the same in an action def body and in an action usage nested in a part def.

Expected
declaration metaclass
action acceptIt accept s : Sig via p; AcceptActionUsage
action assignIt assign count := 1; AssignmentActionUsage
perform action performIt : Notify; PerformActionUsage
action ifIt if count > 0 { ... } IfActionUsage
action whileIt while count < 3 { ... } WhileLoopActionUsage
action forIt for i : Integer in (...) { ... } ForLoopActionUsage
succession flow sf of Fuel from ... to ...; SuccessionFlowUsage

The query @type should be the metaclass. The Symbol kind should be the matching name in its own vocabulary (acceptActionUsage, ..., successionFlowUsage), as #1992 adds sendActionUsage.

This issue is about the kind only. #1985 also asked for the send's payload, sender and receiver. The matching reads here (accept payload and receiver, assignment referent, loop and if conditions, the performed action) are a follow-up and can be raised separately once the kinds exist.

For comparison, the SysML v2 Pilot Implementation (0.64.0-SNAPSHOT, commit 378a8700c) and sysml-toolkit (v0.11.3) report each metaclass above.

Version

OpenSysML develop at 1a8e4927dc (2026-11-05), built locally: sysml-grpc nightly-153-g1a8e4927dc, Python client from client/python. The Go API (client/opensysml) reports the same kinds.

Related
  • #1985, and its fix #1992: the same bug for SendActionUsage.
  • #2001: accept as a state's entry/do/exit action is a syntax error. This issue is about accept actions that do parse.
Found by

The test suite at https://github.com/hideo67/sysmlv2-tests, matrices C20 (kinds of action) and B20 (flows). Models: test-suite/data/models/C20.sysml and B20.sysml. Failing cases:

  • C20-007/008, 010/011, 013/014, 016/017, 019/020, 022/023: accept, assign, perform, if, while and for, read in an action def and in an action usage owned by a part def. (C20-001..005 are the send cases of #1985. Every third case is read through a typing usage and fails because of #1961 instead.)
  • B20-007, B20-010: succession flow with end depths 1 and 2, read in the part def. (B20-008/009/011/012 read them through usages and fail because of #1961 instead.)
Lingua principale
Go
Stelle
56
Fork
17
Merge medio
12h 31m
PR unite (30g)
909

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Open-MBEE/OpenSysML

Tutte le issue di Open-MBEE/OpenSysML

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.