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

Abierto
  • ¿Algo no está bien?
#1,965 3 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

  • #1981 de @devin-ai-integration — cerrado sin fusionar

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
42/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go, python
Área
api, backend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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)

Lenguaje dominante
Go
Estrellas
56
Forks
17
Merge medio
12 h 31 min
PR fusionados (30 d)
909

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Open-MBEE/OpenSysML

Todos los issues de Open-MBEE/OpenSysML

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.