FlowDrop Workflow Specification 1.0-draft

An explicit null at a higher priority wins

Sending null is a decision, not a silence. A node that emits null on a wire has said something, and what it said beats whatever the author saved.

The rule

Normative: this is the rule
  1. At every priority, a value counts as supplied when a key of the parameter's name is present, whatever that key's value.
  2. An explicit null therefore wins over any lower priority: a null delivered on a wire beats the author's saved config, and a null in the saved config beats the schema default.
  3. This holds identically however a workflow is executed.

What it means

An assumption a careless reader might carry over from ordinary code is that null means "nothing here" and so falls through to whatever comes next. This rule refuses that: presence is what counts, not the value behind it. A wire, the saved config, and the schema default are each checked the same way — does a key of the parameter's name exist at all — and an explicit null at a higher priority satisfies that check exactly as any other value would. A null delivered on a wire therefore beats the author's saved config outright, and a null saved in config beats the schema default, in both cases exactly as if a non-null value had arrived.

Example

A node's output for the wired port is explicitly null:

A node's output, explicitly nullproduced
{"out": null}
What the wired input receivesdelivered
{"data": null}

The key survives as a present, null entry rather than disappearing — which is what lets priority 1 claim it instead of falling through to the saved config.

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 · CFG-7 · changed in spec 1.0