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

Aperta
#1,965 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

  • #1981 di @devin-ai-integration — chiusa senza merge

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
42/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go, python
Ambito
api, backend

Direzione di ricerca

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.

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

Descrizione

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)

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.