ADL vs EXPRESS/STEP
The Ancestor That Never Got a Server
TL;DR: Long before “schema-driven” was a pitch, ISO 10303 (STEP) shipped EXPRESS: a declarative modeling language rich enough to describe the geometry of a jet engine, complete with typed entities, inheritance, derived attributes, and formal constraint rules. It is arguably ADL’s closest ancestor on the data side, and it proved, three decades ago and at industrial scale, that rich declarative domain modeling works. What EXPRESS never had was a runtime. It defined data for interchange (so that CAD, CAM, and PLM systems could exchange product models), and every one of those systems still implemented its behavior by hand. EXPRESS answered “what does a valid product model look like?” and stopped. ADL picks up at the exact line where EXPRESS stopped: it specifies what a running application does with valid data, not the shape of the data alone.
The most sophisticated spec language you’ve never used
If your background is web development, EXPRESS needs an introduction. If your background is manufacturing, aerospace, or CAD (the audience this article most wants), it needs no introduction at all, and the comparison will land differently than any other in this series.
STEP (ISO 10303, “Standard for the Exchange of Product model data”) emerged from a brutally hard problem: engineering data (parts, assemblies, tolerances, materials, full boundary-representation geometry) had to survive passage between rival vendors’ systems, across decades, under regulatory scrutiny. The committee’s answer began with a language: EXPRESS (ISO 10303-11), for defining the information models everything else would obey.
And EXPRESS was serious. Typed entities with multiple inheritance. Enumerations, selects, aggregates with cardinality bounds. Derived attributes: values computed from other attributes, declared in the schema. WHERE rules: formal boolean constraints on entities, so a schema could state, rather than hope, that an edge’s start and end vertices lie on its curve. Global rules spanning entity populations. A graphical notation (EXPRESS-G) for humans. Anyone who has read this series will feel the recognition: typed fields, computed fields, validation rules, cross-record constraints: the ADL vocabulary, drafted in the early 1990s by people modeling turbine blades.
So let it be said without hedging: rich declarative domain modeling is not a new idea, and it is not an unproven one. EXPRESS carried the aerospace and automotive supply chains for thirty years. When ADL claims that a domain’s structure, derivations, and invariants can be specified rather than programmed, it stands on ground EXPRESS cleared.
What EXPRESS deliberately didn’t attempt
Now the boundary — and it was a design choice, not an oversight.
EXPRESS defines what valid data is. It says nothing about what a system does: no operations, no API, no users, no permissions, no lifecycle, no side effects. A STEP file (the famous Part 21 physical file) is a snapshot of a product model in transit: validated against the schema on the way out and the way in, then absorbed into whatever the receiving system privately does with it. The standard governs the interchange; behavior was always each vendor’s proprietary business.
Which means the two-artifact gap this series keeps finding didn’t disappear in the STEP world — it relocated. The schemas were rigorous and shared; the implementations were hand-written, enormous, and private. Every CAD kernel, every PDM system, every translator implemented its slice of the semantics by hand, and STEP interoperability in practice became its own engineering discipline precisely because a schema, however formal, underdetermines a system. Anyone who has debugged a lossy STEP round-trip between two vendors’ systems has lived the gap between “the data validates” and “the systems agree.”
There’s also the matter of the constraints themselves. A WHERE rule declares an invariant; enforcing it is the implementation’s job, at whatever moments the implementation chooses, typically at file import/export. Between those checkpoints, inside each system, the invariant is whatever the vendor’s code says it is. The declaration and the enforcement are separate artifacts, separately owned. Familiar.
The same language, plus a pulse
ADL’s move, seen from the EXPRESS side, is compact: take the schema-language ambition (typed entities, derivations, formal invariants) and attach it to a runtime, so that the schema stops being a document about systems and becomes the system.
Line the mechanics up. An EXPRESS derived attribute declares a computation; an ADL computed field declares one and the runtime maintains it: virtual fields evaluated on read, stored fields recalculated in the same transaction as the writes that affect them, aggregations recalculated when related records change. An EXPRESS WHERE rule declares an invariant checked when an implementation gets around to it; an ADL validation or business rule is evaluated on every write, before commit, rejecting atomically with a structured error. There is no moment when the data can be out of compliance with its schema, because the schema is the gatekeeper, not a reference document. And around the data layer sits everything EXPRESS scoped out on purpose: the API generated from the model, the roles and field-level permissions, the state machines, the history, the processes.
The interchange concern doesn’t vanish. It gets a modern answer at a different layer. A Kalos domain emits an OpenAPI 3.1 document; typed clients in any language generate from it. Where STEP moved snapshot files between systems, an interpreted domain exposes a governed live surface and lets the standard contract handle the polyglot problem.
Where EXPRESS/STEP is simply better
Two concessions, one of them structural.
The structural one: interchange between rivals is STEP’s home game, and a vendor language cannot play it. STEP’s entire value is neutrality: ISO governance, decades of stability, no vendor able to bend it. If your problem is moving product data between Siemens NX and CATIA and a supplier’s PDM across a twenty-year program, you need the international standard, full stop. ADL is one vendor’s language with one runtime; by definition it can’t be the neutral ground between competitors. (Its data, at least, keeps exits open with plain SQL tables and a standard API, but an exit is not a treaty.)
The second: depth of domain investment. STEP’s application protocols (AP242 and its kin) encode person-centuries of formalized engineering knowledge: geometry, tolerances, kinematics, composites. ADL gives you a language for your domain; STEP hands whole industries theirs, pre-agreed. Nothing in a general-purpose application language substitutes for that accumulated modeling.
Why this comparison earns its place
Of the seven technologies in this series, EXPRESS is the one that makes ADL look least novel — and that’s exactly why it belongs here. The skeptic’s strongest objection to this whole series is “rich declarative specification of complex domains is a fantasy; real systems are too messy.” EXPRESS is the thirty-year, safety-critical-industry counterexample. The idea works. It has always worked. What the modeling tradition never shipped, from EXPRESS through UML, was the runtime that makes the model the artifact instead of an artifact. That’s the missing piece ADL exists to supply.
The one-line version
EXPRESS modeled product data richly enough to exchange it between rivals. ADL models application data richly enough to run it — the same declarative ambition, finally attached to a server.