FlowDrop Workflow Specification 1.0-draft

Only a flat default is published

A default is published so a caller knows what happens if they omit the input. Anything with nested structure is dropped rather than half-published, and the rest of the fragment survives the drop.

The rule

Normative: this is the rule
  1. A default survives into the published contract when it is null, a scalar, or a collection one level deep whose every member is null or a scalar, an empty collection included.
  2. A default of any other shape, including one with a nested value, is dropped and the drop is logged.
  3. Dropping a default never affects the rest of the fragment: every other contract key of that entry is retained.

What it means

A default is published so a caller can know what happens without supplying the input, and that only works if the published value is exactly what the runtime would use. A scalar is always safe. A collection one level deep is safe too, as long as every member of it is itself null or a scalar — a flat list, or a flat map, both count. Anything deeper is dropped rather than half-published, because a caller reading a truncated nested default would be told the wrong thing with no way to notice.

Dropping a default touches nothing else: every other key of that entry's contract fragment — its type, its maxLength, whatever else survived MAN-5's strip — is retained exactly as it was.

Example

A scalar defaultretained
{ "type": "string", "default": "abc" }
A one-level map whose members are scalar or nullretained
{ "default": { "a": 1, "b": null } }
A default nested one level too deepdropped
{ "type": "array", "default": { "nested": { "too": "deep" } } }

The third default is gone from the published fragment, but its type key is not:

What the third fragment publishes
{ "type": "array", "x-data-type": "array" }
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 · MAN-7 · changed in spec 1.0