FlowDrop Workflow Specification 1.0-draft

Dynamic port names are constrained and unique across the node

The rule

Normative: this is the rule
  1. A dynamic port name begins with an ASCII letter and continues with ASCII letters, digits or underscores.
  2. It must not be a reserved name, and it must be unique across the union of the node's dynamic input and dynamic output names: an input and an output on the same node may not share a name.
  3. A definition that breaks any of these is refused.

What it means

The pattern is ASCII-only: a name begins with a letter from a-z or A-Z and continues with ASCII letters, digits or underscores. A name written with a non-ASCII letter fails even though it reads as an ordinary word to a person, and a single ASCII letter on its own is enough to pass.

Uniqueness is checked across the union of a node's dynamic inputs and dynamic outputs, not within each side separately. An input and an output on the same node cannot share a name, even though one is never confused for the other at the point where a value is delivered.

Example

A name that reads as a word but carries a non-ASCII letterrefused
"pörtchen"
Input definitions that validate, one of them a single letteraccepted
[{ "name": "in_1" }, { "name": "Alpha2" }, { "name": "a" }]

The same definition declared on both sides of one node, not just repeated within one side, is refused too:

A definition declared as both an input and an outputrefused
[{ "name": "shared" }]
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-3 · changed in spec 1.0