FlowDrop Workflow Specification 1.0

A node's ports are its effective schemas, with dynamic ports overlaid

A dynamic port definition is configuration that adds one property to the node's input or output schema. Once it is overlaid, the port is a port like any other, and no rule needs to say anything special about it.

The rule

Normative: this is the rule
  1. A node's ports MUST be read from its effective schemas: the node type's parameter schema overlaid with the node's dynamicParameters, and its output schema overlaid with its dynamicOutputs.
  2. Each definition MUST add one property named after it.
  3. Where the definition carries a schema (DYN-2), the property MUST be that schema.
  4. Otherwise the property MUST carry the definition's lane in x-data-type, and the JSON Schema type that lane stands for: string, number, boolean and array for the lanes of those names, object for json, and no type for mixed.
  5. Where the lane is a shape, the property MUST carry the shape's own top-level type where the shape declares one, and nothing more of the shape (SCH-42).
  6. A property the node type declares MUST win over a definition of the same name (DYN-5).
  7. An overlaid parameter MUST take the gate flags its definition carries (DYN-2), and the derived input and config schemas MUST split it as any parameter (SCH-3, SCH-6).
  8. An overlaid port's default exposure MUST be its definition's exposedByDefault where the definition states one (DYN-2), and exposed where it does not (CFG-2).
  9. The overlay MUST be computed from the node's stored definitions wherever a node's ports are read: at save, when the node is enriched, when a contract is built and when the node runs.
  10. It MUST NOT be computed from a value delivered at run time (DYN-7).
  11. Every rule that reads a node's ports reads them from its effective schemas.

Why

Recorded under OPEN-25, OPEN-31, OPEN-33.

Fixtures

Test cases whose outcome this rule decides. A case compares absent, null and empty members exactly; the fixtures README defines each operation. Where a case and the rule disagree, the rule is right.

  • An unwired dynamic input is absent; a null on its wire is present resolve-parameters
    {
  "given": {
    "parameters": {},
    "dynamicParameters": [
      {
        "name": "a",
        "connectable": true,
        "exposedByDefault": true
      },
      {
        "name": "b",
        "connectable": true,
        "exposedByDefault": true
      }
    ],
    "inputs": {
      "b": null
    }
  },
  "expect": {
    "resolved": {
      "b": null
    }
  }
}

    fixtures/presence/dyn-unwired-absent-null-present.json

Rule identifiers are permanent and are never renumbered. Each implementation publishes its own standing against these rules; this specification does not.spec 1.0 · DYN-8 · changed in spec 1.0