#a11y

Sounds great, you explained it in a much better way, but that's what I had in mind ;-)

However, the "#parents" key is a common Form API concept. It's not something special. An implementation based on a certain API is supposed to incorporate its common concepts.

It was indeed meant as a response to #21. In my view, individual config forms from plugins (components) don't require any enhancements that the modeler requires, e.g. parent. As of the described separation between model owner (ECA) and modeler (bpmn_io or cm), the modeler can add stuff that they require without having a plugin to be bothered with enhancements that are not relevant on the component level.

Is #21 a reply to #20 or a general information about modeler API? Maybe posted into the wrong issue (looks like an answer regards modeler API)?

The architecture of the framework has meanwhile changed a lot. ECA and bpmn_io don't know each other anymore. They "communicate" through the modeler API such that ECA (or any other complex model owner) tells the modeler API which components and component types they have. Modelers, on the other end, also tell the modeler API what component types they provide, and the modeler API then maps the model owner component types to those of the used modeler.

The modeler receives the used components and a config form for each of them as individual pieces. That way the modeler can do with them whatever is needed by the modeler. At that point, the modeler can e.g. inject a parent ID, if that's what the modeler requires.

On the way back, i.e. when a model gets saved, the modeler breaks the model apart and delivers a list of used components and their config to the modeler API, who then maps that back to the model owner, who receives that data and stores it in its config format.

In that architecture, the modeler doesn't store a model as a complete entity. It just passes components, config and context to the modeler API. The modeler has no knowledge about the meaning or the components or the structure and format of the model as a config entity. That's only known and under control by the model owner, i.e. ECA or AI Agents, etc.

This decoupled architecture allows every model owner to work with every modeler, as long as both sides support the modeler API.

Of course, if a modeler only wants to work for e.g. ECA, they can still avoid using the Modeler API, but then they are on their own and need to implement everything themselves.

As long as the #parents key isn't incorporated into the states definitions, this may only work for now with the bpmn_io modeler. But it wouldn't work for any other tool that embeds plugin forms "inline" such as eca_cm does. The #parents key is a common form API concept and thus may be worth to be incorporated. For details, see #12.