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

Đang mở
  • Có gì không ổn?
#2,007 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
go, python
Lĩnh vực
backend-api-design

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Go
Star
56
Fork
17
Merge trung bình
12 giờ 31 phút
Pull request đã merge (30 ngày)
909

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của Open-MBEE/OpenSysML

Tất cả issue của Open-MBEE/OpenSysML

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.