FlowDrop Workflow Specification 1.0-draft

An exposure name may not collide with a reserved runtime name

R4.a's alphabet admits names beginning with underscores, which is where the runtime's own injected parameters live. Without this rule an author could claim one of them and shadow it.

The rule

Normative: this is the rule
  1. A workflow exposure entry's name must not be a name the runtime reserves for parameters it injects into a workflow's manifest; __interrupt_id__ is such a name.
  2. A reserved name is refused with R4_NAME_RESERVED at schema.{side}.{index}, on the input side and the output side alike.

What it means

R4.a's alphabet admits names that start with an underscore, and that is exactly where the runtime's own injected parameters live. This rule closes that gap by name, not by pattern: it refuses the specific reserved names, not every name that happens to start with an underscore, and it does so on the output side exactly as it does on the input side, even though the reserved name in question exists to carry an interrupt reply in.

Example

The same reserved name, claimed once as an input and once as an output:

An exposure entry claiming the reserved interrupt namechecked
{ "name": "__interrupt_id__", "node_id": "n1", "port": "result" }
The error when that entry sits among the inputsrefused
{ "code": "R4_NAME_RESERVED", "locator": "schema.input.0" }
The error when the same entry sits among the outputsrefused
{ "code": "R4_NAME_RESERVED", "locator": "schema.output.0" }

Nothing about the output side makes the collision less real: an author could shadow the injected name there just as easily.

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 · R4.e · changed in spec 1.0