Schema-driven forms

Prefer the XML schemas dialect 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 schema-form for typed nested configuration or forms provided by an API. Inline schemas can use the native XML schema dialect; JSON Schema text and CDATA remain compatible. The XML compiler verifies the enclosing contract; the CoCoCo app validates entered values against the schema.

<journey id="configuration" title="Configuration">
  <schema-form id="config" title="Print settings" outputKey="config">
    <schema>
      <schema type="object" xmlns="urn:cococo:json-schema:1">
        <property name="address" type="object">
          <property name="city" type="string"/>
        </property>
        <property name="binding" type="string">
          <default type="string">none</default>
          <enum>
            <value type="string">none</value>
            <value type="string">saddle</value>
          </enum>
        </property>
        <property minimum="1" name="copies" type="integer">
          <default type="number">1</default>
        </property>
        <property name="duplex" type="boolean">
          <default type="boolean">true</default>
        </property>
        <required name="copies"/>
        <required name="binding"/>
        <property-order>
          <name name="copies"/>
          <name name="duplex"/>
          <name name="binding"/>
          <name name="address"/>
        </property-order>
      </schema>
    </schema>
  </schema-form>
  <done id="done" title="Configured"><body>Copies: {{ $.state.config.copies }}</body></done>
</journey>

With outputKey="config", the full object is available as $.state.config. Without outputKey, top-level properties share Journey state and can collide with other field or capture keys. Prefer outputKey for reusable or dynamic schemas.

The CoCoCo app supports typed controls, defaults, choices, nested objects and x-propertyOrder. Some shapes use a generic JSON editor. JSON Schema keywords are not all custom widgets. Related-resource controls use the app's resource lookup and preserve the schema's requested value shape.

A prior fetch may capture a schema, followed by a reference instead of an inline schema:

<journey id="dynamic" title="Dynamic configuration">
  <fetch id="load" title="Load schema" description="Loading configuration">
    <document>query { result: configSchema }</document>
    <capture key="schema" path="result"/>
  </fetch>
  <schema-form id="config" title="Configuration" schema="$.state.schema" outputKey="config"/>
  <done id="done" title="Ready"/>
</journey>

The example's configSchema query is illustrative. Replace it with a real schema-producing field from your instance and analyze against that schema. Dynamic content must resolve to a usable object before the form can advance.

Do not combine a schema attribute and a schema child. The CoCoCo app does not yet support the load-bearing extensions x-dynamicSchema, x-queryParameterBindings or x-supportsExpression. Such schemas block continuation rather than silently converting them to free text. A JSON Schema being syntactically valid is not proof that every requested runtime capability exists.