FlowDrop Workflow Specification 1.0-draft

Config field order applies inside a ui schema only

The rule

Normative: this is the rule
  1. x-config-order orders config fields ascending; a property whose value is absent or not numeric counts as 0, and ties keep declaration order.
  2. It takes effect inside a generated ui schema only: where no property carries a registered group there is no ui schema, no layout, and x-config-order has no effect on the flat form.
  3. The earlier spelling x-display-order carries no meaning; a schema that still writes only it orders at 0, like any untagged property.

What it means

The retired spelling is not a synonym that still works as a fallback: a schema that writes only the earlier name orders exactly as if it had written nothing at all, keeping declaration order rather than the order the retired key would have produced.

Example

Two grouped properties, first weighted ahead of second:

Two grouped properties, first weighted 20 and second weighted 10declared
{
  "first": { "type": "string", "x-group": "general", "x-config-order": 20 },
  "second": { "type": "string", "x-group": "general", "x-config-order": 10 }
}
What the generated layout orders them intoreordered
["#/properties/second", "#/properties/first"]

The same two weights, spelled with the retired key instead, do not reorder:

The same weights spelled with the retired x-display-orderdeclared
{
  "first": { "type": "string", "x-group": "general", "x-display-order": 20 },
  "second": { "type": "string", "x-group": "general", "x-display-order": 10 }
}
What the generated layout orders them into with the retired keyunchanged
["#/properties/first", "#/properties/second"]
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 · SCH-31 · changed in spec 1.0