Enhancement: Python client cannot read a parameter's bound expression (`in power = powerPort.power;`); only constant values are exposed

Đang mở
  • Có gì không ổn?
#1,965 3 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.

  • #1981 của @devin-ai-integration — đã đóng, không merge

Đá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
42/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
go, python
Lĩnh vực
api, backend

Hướng nghiên cứu

Start with the attached repro.py and model to reproduce the missing binding in the Python client, then trace how Symbol facts and attribute_facts() expose parameter values. The requested API should report the binding expression, default status, and referenced features for feature chains while retaining folded constants. Also investigate why reflection returns an empty targetFeature.qualifiedName; done means the reproduced bindings and target feature are accessible through the relevant APIs.

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

Mô tả

bug enhancement spec compliance

This issue was written with AI help. The model, the reproduction script and its output are
attached and were run against the version below.

This is mainly a feature request. The issue form points feature requests to Discussions, but
Discussions are not enabled on this repository, so it is filed as an issue.

What happened, and what you expected instead

An action performed by a part binds its input parameter to a feature of the part's port:

part def Motor {
    port powerPort : PowerPort;
    perform action consume : Consume {
        in power = powerPort.power;          // bound to a feature chain
        in gain = 0.5;                       // literal
    }
    action boost : Consume {
        in power = powerPort.power * 2.0;    // operator expression
    }
}

A client walking the model (to generate an interface table, a simulation wiring, or code) needs
to know what each parameter is bound to. From Python:

Route consume::power = powerPort.power consume::gain = 0.5 boost::power = powerPort.power * 2.0
parameter Symbol (metadata, type_facts) direction in, type Real; no value same same
owner's attribute_facts() value None 0.5 ✔ None
model.query no property carries a value same same
reflection, ….metadata.ownedRelationship (the FeatureValue) UnsupportedValueError: metaobject of an element with no qualified name same same
api-json FeatureValue → FeatureChainExpression, targetFeature = PowerPort::power ✔ FeatureValue → LiteralRational 0.5 ✔ FeatureValue → OperatorExpression '*' ✔

So a value is exposed only when it folds to a model-level constant (AttributeFacts.value is
documented that way: "Default value, when it is a model-level constant"). An expression that
refers to another feature, which is the normal way to wire a parameter, is invisible: there is
no text, no referenced feature, and no indication that the parameter is bound at all. The only
route to it is exporting the whole model as api-json and following
ownedRelationship → FeatureValue.value → the expression tree.

Requested: the Symbol API reports a feature's value binding when there is one. At minimum
that means the expression's source text and whether it is a default (isDefault/isInitial).
For a feature-chain expression it should also give the referenced features
(powerPort → PowerPort::power), so a client can follow the binding without parsing text.
AttributeFacts.value could stay as the folded constant beside it.

One reflection defect found on the way: even when navigating straight through the anonymous
elements, last(…::consume::power.metadata).ownedRelationship.value.targetFeature.qualifiedName
returns []. KerML v1.1 §8.3.4.8.4 derives FeatureChainExpression::targetFeature, and
api-json writes it as PowerPort::power. The anonymous-element limitation of reflection
(UnsupportedValueError) is the same one described in #1957.

Reproduction
$ python repro.py          # loads model.sysml with opensysml.loads() over sysml-grpc
## consume::power = powerPort.power
[OK  ] consume::power: Symbol reports direction and type
       observed: {'metadata': {'visibility': 'default', 'direction': 'in'}, 'type_facts.primitive': 'Real'}
[INFO] consume::power: owner's attribute_facts() value
       observed: None
[BUG ] consume::power: the Symbol API exposes the value or expression
       observed: {'facts': {'metadata': {'visibility': 'default', 'direction': 'in'}, 'type_facts.primitive': 'Real'}, 'value': None}
       expected: 'the expression `powerPort.power` (text, and for a chain the referenced feature)'
[INFO] consume::power: reflection ownedRelationship (the FeatureValue)
       observed: UnsupportedValueError('unsupported: metaobject of an element with no qualified name')
[OK  ] consume::power: api-json has FeatureValue -> FeatureChainExpression
       observed: {'@type': 'FeatureChainExpression', 'targetFeature': {'@id': 'ParameterValues__PowerPort__power'}}

## consume::gain = 0.5
[INFO] consume::gain: owner's attribute_facts() value
       observed: 0.5

## Reflection: FeatureChainExpression::targetFeature of consume::power
[BUG ] consume::power: ownedRelationship.value.targetFeature is PowerPort::power
       observed: []
       expected: ['ParameterValues::PowerPort::power']

model.sysml:
package ParameterValues {
    port def PowerPort {
        out attribute power : ScalarValues::Real;
    }

    action def Consume {
        in power : ScalarValues::Real;
        in gain : ScalarValues::Real;
    }

    part def Motor {
        port powerPort : PowerPort;

        perform action consume : Consume {
            in power = powerPort.power;          // bound to a feature chain   -> not exposed
            in gain = 0.5;                       // literal (for comparison)   -> exposed as a value
        }

        action boost : Consume {
            in power = powerPort.power * 2.0;    // operator expression        -> not exposed
        }
    }
}
Reproduction files (attached)
File Contents
model.sysml.txt the model above (GitHub does not accept .sysml uploads): rename it to model.sysml next to repro.py
repro.py loads model.sysml with opensysml.loads() and, for each parameter, checks the Symbol facts, the owner's attribute_facts(), the query API, reflection and the api-json export. Each check prints OK, BUG or INFO, and the script exits 1 while any BUG reproduces.
_common.py shared helper the script imports: starts the sysml-grpc named by $OPENSYSML_BINARY, prints the server and client versions, and formats the checks
output.txt the full output of the run reported here

model.sysml.txt

repro.py

_common.py

output.txt

To run it, put _common.py in the parent directory of the folder holding repro.py and the model,
install the client (pip install -e client/python from an OpenSysML checkout), and point
OPENSYSML_BINARY at a sysml-grpc build:

$ OPENSYSML_BINARY=/path/to/OpenSysML/bin/sysml-grpc python repro.py

Without OPENSYSML_BINARY, _common.py assumes an OpenSysML checkout next to the directory
that holds _common.py, with bin/sysml-grpc built by make build-grpc.

Version

sysml-grpc v0.12.0-262-gc86932321 (develop at c86932321), opensysml Python client 0.12.0, Python 3.13.15

Surface

Python client (opensysml)

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.