Serialization
A Workfile is a YAML 1.2 document, restricted to the subset defined here. Connector manifests, filter package manifests, and schema overlays are YAML 1.2 documents under the same subset.
An implementation MAY accept or emit another encoding of the same data model. An implementation MUST NOT require an encoding other than YAML in order to consume a Workfile.
Within the subset:
- Anchors, aliases, tags, and multi-document streams are disallowed. Implementations MUST reject a document that uses them, rather than interpret it.
- Implicit typing is disallowed. A scalar that could be read as more than one type MUST be quoted. An implementation MUST NOT infer a type from an unquoted scalar’s shape.
- A type expression MUST be quoted wherever it appears: a Workfile’s
inputs, a state’saccepts, a manifest’s schemas, and an overlay’s fields. The type syntax is a grammar that this standard parses, and its brackets are YAML flow indicators. - Each construct has exactly one representation. There are no aliases, shorthands, or sugar forms, and no key accepts both a scalar and a single-element list.
- A duration or a timestamp appears as a quoted or unquoted scalar in a position that declares that type, and is parsed by the literal grammar.
Note: YAML 1.1 parsers read the unquoted key on as the boolean true. A Workfile’s on key is a string. An implementation MUST parse a Workfile with a YAML 1.2 parser, or MUST disable the YAML 1.1 boolean resolution for keys.
A JSON Schema describing the restricted data model is published with each spec version. It is the machine-readable form of this specification’s structural rules: the top-level keys, the one-key-per-step rule, the shape of every construct, the permitted modifiers per body kind, and the name and literal patterns.
The schema cannot check anything that needs a catalog or a scope. Path resolution, argument schemas, enum exhaustiveness, and template variables are outside it, so a document that the schema accepts is not therefore valid.