Meaning of of SupervisorType/SupervisorInPin/@id

[m8pple]

While trying to implement supervisors, there is an attribute Graphs/GraphType/SupervisorType/SupervisorInPin/@id,
but it isn't clear what it is for.

On some examples it has a name, e.g.:
https://github.com/POETSII/Orchestrator_examples/blob/81b2223b5cab07d917bb6d985cc1c558d37befc1/simple_tests/test_RequestIdle_behaviour.xml#L77
However, the id is never used elsewhere in the graph.

On other examples it is empty, e.g.:
https://github.com/POETSII/Orchestrator_examples/blob/81b2223b5cab07d917bb6d985cc1c558d37befc1/mothership_diagnosis/test_ddos_supervisor.xml#L70

In Orch_Vol_II on page 19 it is not listed as as an attribute of SupervisorType/SupervisorInPin.
On page 32 it does appear in the id="" form, but it is not mentioned (as far as I can tell).

In the grammar on page 53 of Orch_Vol_III it is shown as required, and the same in the V4Grammar3.ocfg grammar file

Is this a legacy thing, or for functionality that doesn't exist yet. I notice on page 38 of Orch_Vol_III it says:

For historical reasons, edge definitions where one or both device fields are
blank are intended to represent supervisor connections

Apart from that it doesn't say anything I can see (though I'm scanning it quite quickly).

Looking at the orchestrator code, in composer it doesn't seem to care about the
id (

Orchestrator/Source/OrchBase/Composer.cpp

Line 1738 in ee9abed

if(supType->pPinTSI)

).
There is mentioned of a general handler, but it isn't implemented (

Orchestrator/Source/OrchBase/Composer.cpp

Line 1765 in ee9abed

if(supType->pOnPkt)

).

So questions arising are:

• What is the id attribute intended to be for. Is it for explicit device->supervisor connections?
• Why is it "id" rather than "name" (like with device pins, which have local scope)? Does it have global scope in some way?
• Are there any examples where the id attribute is used?
• If the attribute can be empty, would it not make sense to make it optional in the grammar?
  • Or: could it be required to have a name?

Going further, once there are multiple SupervisorInPin elements on a SupervisorType, how do we know which one
is the implicit/default input pin?