FlowDrop Workflow Specification 1.0-draft

A dynamic port declares a name, a label and a data type

The rule

Normative: this is the rule
  1. Every dynamic port definition carries a name, a label and a dataType.
  2. The dataType defaults to mixed, and the set an editor offers an author is exactly those data-type lanes that carry a value; the control lanes are not offered, because a dynamic port carries a value by definition.

What it means

A dynamic port definition needs exactly three keys to be usable: name, label and dataType. Leaving dataType out is not the same as refusing the definition — it defaults to mixed instead. The lanes an editor may offer for dataType exclude the ones that carry no value at all: a dynamic port is a value port by definition, so a lane that exists only to route control is not among the choices, whatever else the vocabulary contains.

That closure only shapes what an editor offers. A definition naming a dataType outside the offered set is not refused, and nothing downstream checks a dynamic port's declared type against the value it actually carries.

Example

A definition naming a dataType outside the offered set still resolves:

A definition whose dataType is outside the offered setaccepted
[{ "name": "alpha", "label": "Alpha", "dataType": "object" }]
What resolving it still returnsunaffected
{ "alpha": "a value" }
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-2 · changed in spec 1.0