FlowDrop Workflow Specification 1.0-draft

Dynamic ports are opt-in, and a node that does not opt in has none

Dynamic ports let an author add connection points to one node instance beyond what its processor declares. Nothing gets them by accident: a node type has to ask for them, and the definitions start empty.

The rule

Normative: this is the rule
  1. A node type opts a node in to dynamic ports.
  2. The opt-in declares two reserved parameters, one holding the node's dynamic input port definitions and one its dynamic output port definitions, each a list whose default is empty.
  3. A node that has not opted in has no dynamic ports.

What it means

Opting in adds exactly two keys to a node type's declared parameters, each holding a list of port definitions with an empty default. A node type that never opts in never carries those keys, so a node built from it cannot have a dynamic port at all — there is nothing to add one to.

What a stored definition looks like when it is not usable matters as much as what it looks like when correctly authored: a value that is not a list at all reads back as an empty list rather than surfacing the malformed content or refusing the node outright.

Example

A node's stored definitions are not lists — one is a string, one a number:

Stored definitions that are not listsunusable
{ "dynamicInputs": "not-an-array", "dynamicOutputs": 42 }
What reading them back returnsempty
[[], []]
Rule identifiers are permanent and are never renumbered. Each implementation publishes its own standing against these rules; this specification does not.spec 1.0-draft · DYN-1 · changed in spec 1.0