14. Processing model

Contents of DISL 0.1

14.1 Loading a specification

Parse the JSON; reject duplicate keys.
Check versions: disl major version supported (or its deprecated alias, section 18).
Resolve imports recursively, verify integrity hashes, detect cycles, apply include filters, prefix names with aliases.
Validate structure against the JSON Schema $defs/Specification.
Resolve names: every type, style, shape, marker, icon, form, tool, snap profile, layout, operation, function and plugin reference must resolve.
Flatten inheritance: compute C3 linearisations; merge attributes, ports, containment; check narrowing rules (4.7).
Derive built-ins: generate built-in constraints (8.7), default notations, default forms and the default toolbox where absent.
Compile CEL: parse and type-check every expression in its context (12.3); estimate costs against language.limits.celCost; check user functions for recursion.
Check semantic rules not expressible in JSON Schema: reserved attribute names, placement attribute types compatible with axes, snapping rules compatible with axis kinds, x2 vs width exclusivity, handle parameters exist, label editable requires attribute binding, exactly one of path/parts/svg/plugin in shapes, and all other MUST statements of this document.
Build the runtime model.

Validators report every problem with the JSON Pointer of its location, a severity (error makes the specification unusable; warning does not) and a message.

14.2 Loading a DID definition

A runtime loads a stored diagram as DID specifies (DID-specification.md, section 8.1): it checks the language id and version against the specification's, runs this specification's migrations (11.9), validates, resolves view data, evaluates live constraints and renders.

14.3 Unknown content

Unknown types, attributes and view properties in a stored diagram are preserved as DID specifies (DID-specification.md, section 8.2), and unknown elements are reported by std.typeExists.

14.4 The editing transaction

Every user gesture, form commit, operation or quick fix is one transaction:

Diagram as text (Mermaid)

---
config:
  flowchart:
    rankSpacing: 20
---
flowchart TB
  accTitle: The editing transaction
  accDescr: A gesture passes through gesture constraints, which may prevent it, then snapping, then the change is applied. Then run the before hooks, which may abort, the after hooks, and the recomputation of derived values and bindings. Invariants with enforcement prevent then either reject the transaction, which rolls it back, or let it commit as one undo step. After the commit, live constraints are evaluated, debounced, and the diagram is rendered.
  gesture([gesture]) --> gestureConstraints["gesture constraints<br/>prevent?"]
  gestureConstraints --> snapping[snapping] --> apply[apply change]
  apply --> before["#quot;before#quot; hooks<br/>may abort"]
  before --> after["#quot;after#quot; hooks"] --> recompute["recompute derived<br/>values & bindings"]
  recompute --> invariants["invariants with<br/>enforcement #quot;prevent#quot;"]
  invariants -- reject --> rollback([roll back])
  invariants --> commit["commit<br/>(one undo step)"]
  commit --> live["live constraints<br/>(debounced)"] --> render([render])

Transactions are atomic: either all effects apply or none. Remote changes from collaborators apply as transactions without hooks but with constraint evaluation.

14.5 Saving

Evaluate constraints with save timing. If blockSaveOn: "error" and errors exist, ask the user (saving MUST remain possible under a different name or as a draft if the runtime supports drafts).
Write the DID definition canonically and atomically, as DID specifies (DID-specification.md, section 8.3).