# Values and expressions

Prefer the [XML schemas dialect](schema-manual://schema-xml-1/authoring) for embedded schemas. It supports native form annotations such as `input-type="password"`, `related-resource="device"`, `editor-language="lua"`, and `property-order`. Existing JSON text and CDATA remain supported; each resource keeps its existing validation and execution restrictions.

Use strings for identifiers, including numeric-looking values such as `0012`. `<value>` defaults to string. Other types are `integer`, `number`, `boolean`, `null`, `array` and `object`. Object entries have names; array entries do not.

```xml
<workflow>
  <nodes>
    <node id="values" type="transform">
      <config>
        <value name="mapping" type="object">
          <value name="identifier">0012</value>
          <value name="count" type="integer">3</value>
          <value name="enabled" type="boolean">true</value>
          <value name="missing" type="null"/>
          <value name="labels" type="array">
            <value>rush</value>
          </value>
        </value>
      </config>
    </node>
  </nodes>
  <edges/>
</workflow>
```

Use `expression` for a calculated value, without a `type` or literal body. `input` contains run inputs, `nodes.<id>.output` contains earlier results, and `variables` contains workflow variables. Connect the producing node to the consuming node: an expression alone does not create a dependency. Use bracket notation for IDs containing punctuation, such as `nodes['load-order'].output`. Escape quotes and ampersands as XML requires.

Suggestions show known input fields and earlier outputs. Fields supplied by external data may remain unknown until a run.

Execution step input shows the executor envelope for each attempt: `input` holds the run inputs, and each connected predecessor ID holds that node's output. An untaken or failed predecessor has no fabricated value. Retries have their own observations; a completed node skipped during resume keeps its original observation.

Step observations omit secret-bearing values declared by the pinned input schema (`writeOnly`, `format: password` or `x-input-type: password`) and known credential keys. They are bounded independently of execution data. If an observation exceeds the byte, nesting or value limit, `__workflowInputObservation.status` is `OMITTED_LIMIT` instead of a misleading partial payload. This does not alter the inputs used by the node or the outputs used to resume it. Use configured connections for credentials, rather than ordinary workflow data.