A feature's type leaves out the types it gets through subsetting and redefinition, and reference subsetting (`::>`) is not reported at all

Aperta
  • Qualcosa non va?
#2,007 2 commenti 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
48/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
go, python
Ambito
backend-api-design

Direzione di ricerca

Start by reading type_info and specialization construction in the Go service, then compare those results with _with_inherited_facts in client/python/opensysml/generate.py. Reproduce with the supplied SysML example and check A20-037..039 and A40-007, A40-022, A40-034, A40-037, A40-040, and A40-043. Done means the API reports derived types and the reference-subsetting relationship for these cases.

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

Descrizione

bug

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

What happened

A Symbol's type_info gives only the feature's own : T typing. A feature that gets its type by subsetting, reference subsetting or redefinition reports no type. A feature that has its own typing and also subsets another feature reports only its own type. Reference subsetting (::>) is not in specializations either, so nothing in the Symbol says where pRef gets its type.

package P {
    part def T;
    part def V;
    part def Owner {
        part q : T;
        part pSub :> q;             // subsetting
        ref part pRef ::> q;        // reference subsetting
        part pBoth : V :> q;        // typing and subsetting
        attribute a : ScalarValues::Real;
    }
    part def SubOwner :> Owner {
        part :>> q;                 // redefinition
    }
    part tuned : Owner {
        attribute :>> a = 3.5;      // redefinition with a value
    }
}

import opensysml
m = opensysml.loads(SRC)            # m.ok is True, no diagnostics
for qn in ["P::Owner::q", "P::Owner::pSub", "P::Owner::pRef",
           "P::Owner::pBoth", "P::SubOwner::q", "P::tuned::a"]:
    s = m.get(qn)
    print(qn, repr(s.type_facts.resolved_id), repr(s.type_facts.primitive),
          [(sp.kind, sp.target_id) for sp in s.specializations])

P::Owner::q     'P::T' ''     [('typing', 'P::T')]
P::Owner::pSub  ''     ''     [('subsets', 'P::Owner::q')]
P::Owner::pRef  ''     ''     []
P::Owner::pBoth 'P::V' ''     [('typing', 'P::V'), ('subsets', 'P::Owner::q')]
P::SubOwner::q  ''     ''     [('redefines', 'P::Owner::q')]
P::tuned::a     ''     'Real' [('redefines', 'P::Owner::a')]

The last line is the most common case in practice: attribute :>> mass = 1500; in a usage. The service does follow the redefinition for primitive ('Real') but leaves resolved_id empty, so the type is known but not reported.

The Python client's own code generator already works around this. _with_inherited_facts in client/python/opensysml/generate.py walks subsets/redefines to fill in a feature's type. A user reading Symbols has no such fallback, and the workaround cannot help pRef, whose reference subsetting is not reported at all.

Expected

  • type_info (or a new field) reports the feature's types as KerML derives them. Feature::type covers the feature's own typings and the types of every feature it subsets. Redefinition and reference subsetting are kinds of subsetting, so their targets count too:

    feature expected types
    pSub :> q T
    pRef ::> q T
    pBoth : V :> q V, T
    SubOwner::q :>> q T
    tuned::a :>> a = 3.5 ScalarValues::Real

    pBoth has two types, and TypeInfo.resolved_id holds one. A list is probably needed. Alternatively, a separate field could hold the derived types and leave type_info as the declared typing.

  • pRef ::> q lists a specialization for q, with its own kind (the spec metaclass is ReferenceSubsetting). The comment on Specialization.kind in api/proto/sysml.proto lists only specializes, subsets, redefines and typing. Reporting ::> as subsets would also do, since a reference subsetting is a subsetting. Losing the relationship entirely is the bug.

For comparison, the SysML v2 Pilot Implementation (0.64.0-SNAPSHOT, commit 378a8700c) and sysml-toolkit (v0.11.3) give the types and specializations above for every case.

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) gives the same results.

Related

#1961 is about features not being listed through a typing usage or a specialization. This issue is about features read directly in their owner, which are found but report the wrong type.

Found by

The test suite at https://github.com/hideo67/sysmlv2-tests, matrices A20 (attribute usages) and A40 (feature typing, subsetting and redefinition). Models: test-suite/data/models/A20.sysml and A40.sysml. Failing cases:

  • A20-037..039: the type of :>> plain = 3.5, :>> bound and :>> dflt = 5.5 in a usage.
  • A40-007, A40-022: the specializations and subsetted features of pRef ::> q.
  • A40-034, A40-037, A40-040, A40-043: the types of pSub, pRef, pBoth and SubOwner::q.

The other A40 failures (read through owner, subOwner, subSub) are #1961.

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.