Input to #47 rather than a defect report — the emitter is correct on all of this today. Filing as an issue rather than a comment there so it has somewhere to be closed from.
Both are graph facts, which is why they belong to that work: graph_builder is what would carry them.
The framing is #47's own:
A selection that carries no datatype cannot drift from the specification by hand-copying one.
Agreed — and these are the two things the catalogs still cannot carry, so they are hand-copied and they do drift.
1. A string that is a device reference cannot be declared as one
| property |
datatype |
format |
connection/feeds-device-id |
string |
— |
connection/fed-by-device-id |
string |
— |
grid/grid-forming-entity |
string |
— |
That these point at a device lives only in the descriptions. conventions/schemas/property-catalog.schema.json allows exactly datatype, description, format, name, req, settable, unit, with additionalProperties: false — no field to say it in, and no way to add one locally.
What that permits. grid-forming-entity published the class name "BESS" for the life of the emitter (fixed in electrification-bus/distribution-enclosure-simulator#22, released 0.4.1). Datatype string made it legal, so no conformance run could object. Nothing about that was specific to the property; the same hole is open on the other two.
What it costs a consumer. A check that "this value resolves to a device on the wire" catches the whole class without naming a property — reverting the fix gives 1 dangling reference on both variants, 0 on a fixed tree. But it must be handed the list of three, because nothing in the data identifies them. That list is the hand-copied selection the declarative layer exists to eliminate, and it goes stale silently when a fourth appears.
The consumer for a marker is graph_builder: a property naming another device is an edge, and the builder already resolves edges.
2. Whether a MID exists, and what its id is, lives in an example script
examples/run_forty_tab_minimal.py::_mid_instance — sixteen lines, every one a rule about the shape of the tree rather than a detail of that example. mapping/mid.yaml already carries the placement declaratively; the existence condition and the id derivation are what a second producer must reproduce. Ours does, in about twenty hand-written lines mirroring it, outside our dependency pin — so uv sync will never correct it if the rule moves.
The smaller version of the 4,257-line vendored copy we deleted by depending on the emitter: much smaller, same shape, still hand-copied.
Timing
Both are cheap to express while the layer is being shaped and awkward to retrofit once profiles and mappings are a published surface. If a device-reference marker belongs in the specification repo instead, that is a fair call and I will move it.
Input to #47 rather than a defect report — the emitter is correct on all of this today. Filing as an issue rather than a comment there so it has somewhere to be closed from.
Both are graph facts, which is why they belong to that work:
graph_builderis what would carry them.The framing is #47's own:
Agreed — and these are the two things the catalogs still cannot carry, so they are hand-copied and they do drift.
1. A string that is a device reference cannot be declared as one
connection/feeds-device-idstringconnection/fed-by-device-idstringgrid/grid-forming-entitystringThat these point at a device lives only in the descriptions.
conventions/schemas/property-catalog.schema.jsonallows exactlydatatype,description,format,name,req,settable,unit, withadditionalProperties: false— no field to say it in, and no way to add one locally.What that permits.
grid-forming-entitypublished the class name"BESS"for the life of the emitter (fixed in electrification-bus/distribution-enclosure-simulator#22, released 0.4.1). Datatypestringmade it legal, so no conformance run could object. Nothing about that was specific to the property; the same hole is open on the other two.What it costs a consumer. A check that "this value resolves to a device on the wire" catches the whole class without naming a property — reverting the fix gives 1 dangling reference on both variants, 0 on a fixed tree. But it must be handed the list of three, because nothing in the data identifies them. That list is the hand-copied selection the declarative layer exists to eliminate, and it goes stale silently when a fourth appears.
The consumer for a marker is
graph_builder: a property naming another device is an edge, and the builder already resolves edges.2. Whether a MID exists, and what its id is, lives in an example script
examples/run_forty_tab_minimal.py::_mid_instance— sixteen lines, every one a rule about the shape of the tree rather than a detail of that example.mapping/mid.yamlalready carries the placement declaratively; the existence condition and the id derivation are what a second producer must reproduce. Ours does, in about twenty hand-written lines mirroring it, outside our dependency pin — souv syncwill never correct it if the rule moves.The smaller version of the 4,257-line vendored copy we deleted by depending on the emitter: much smaller, same shape, still hand-copied.
Timing
Both are cheap to express while the layer is being shaped and awkward to retrofit once profiles and mappings are a published surface. If a device-reference marker belongs in the specification repo instead, that is a fair call and I will move it.