Skip to content

15. Conformance

Contents of DISL 0.8

15.1 Conformance classes

Class Requirements
Specification A specification is conforming if it validates against the JSON Schema, passes all checks of 14.1 without errors, and uses only declared plugins.
DID definition Conformance of a stored diagram to a specification is defined by DID (DID-specification.md, section 9).
Validator Implements 14.1 and DID's loading rules (without rendering), reports findings with JSON Pointers and locations (8.6), and evaluates constraints headlessly.
Runtime — Core Metamodel, persistence (including migrations, determinism), constraints, behavior, CEL environment, one cartesian numeric coordinate system with grid snapping, built-in shapes rect, roundedRect, ellipse, diamond, text, straight and polyline edges, markers none, arrow, arrowFilled, generated forms and toolbox.
Runtime — Standard Core, plus: all built-in shapes and markers, styles with states and conditions, labels at all positions, compartments, ports, containers, custom path shapes, orthogonal and curved routing, all snap rules for numeric axes, per-axis snapping, time axes with calendar snapping, ordinal axes with bands, bound and computed placement, explicit forms and all standard widgets, context tools, templates, documentation surfaces (2.4), themes with modes.
Runtime — Full Standard, plus: composite shapes with handles, nine-slice scaling, line effects, jump-overs, stacked and custom markers, embedded forms, nested coordinate systems, polar systems, level of detail, variants, collaboration, all export formats, plugins.

A runtime MUST state its conformance class and list unsupported optional features. When a specification requires a higher class or unsupported features, the runtime MUST inform the user and MAY open the diagram read-only.

15.2 Graceful degradation

Runtimes that do not support a visual feature SHOULD degrade visually rather than refuse: a sketch stroke renders as solid, a wave effect as a straight line, an unsupported marker as arrowFilled (target) or none (source), an unsupported shape as rect with its label, an embedded form as its fallback. Semantic features — metamodel, constraints, persistence — MUST NOT degrade.

  • Missing plugin functions. A call to a function of an absent plugin MUST degrade through its fallback (13.1.1). Without one, its semantic uses (constraints, derived elements, ids) report findings as evaluation errors (2.5), and its visual uses fall back to their defaults; the runtime MUST NOT crash, and reports one std.pluginMissing per plugin.
  • Missing 0.2 features. A runtime that lacks an optional feature of Appendix B.8 SHOULD degrade as that feature's absence implies: without canvas.filters, nothing is filtered out; without canvas.notices or canvas.chrome, notices, the title, the header and the empty message are not drawn; without view.viewer, viewer kinds are recomputed on load; without limits.budgets, a budget does not cut the view and the runtime warns beyond maxElements instead, which draws everything, so a specification whose budgets gate edits SHOULD list limits.budgets in language.requires.features; without anchor.part, anchor.sides, edge.stub or edge.bezierLoop, edges attach and route as in 0.1. When a specification requires a feature the runtime lacks, 15.1 applies.

Referenced from