DXL (DOORS Extension Language)

DXL — the DOORS Extension Language — is a procedural scripting language embedded inside IBM DOORS (Dynamic Object Oriented Requirements System), the requirements management tool that dominates safety-critical engineering in aerospace, defense, automotive, and medical device industries. DXL gives engineers direct programmatic access to DOORS’ internal data structures: modules, objects, attributes, links, baselines, and views. Through DXL, teams automate workflows that would otherwise require hundreds of manual steps — generating traceability matrices, enforcing company-specific data standards, migrating content between projects, and producing compliance documentation for regulators. Although DXL is largely invisible outside industries where DOORS is standard infrastructure, it has been in continuous production use for over three decades across some of the most demanding engineering programs on Earth.

History & Origins

DOORS traces its origins to work done by Dr. Richard Stevens at the European Space Agency’s research institute (ESRIN) in the 1970s and 1980s. Stevens recognized that managing large volumes of requirements for complex systems — spacecraft, in ESA’s case — required a structured database approach, not documents. The resulting system captured requirements as objects in a hierarchical database, with each object uniquely identified and linkable to others.

Stevens and colleagues founded Quality Systems & Software Ltd (QSS) to commercialize the tool. The first version was delivered to the UK Ministry of Defence as an early customer around 1991. In April 1993, QSS released DOORS commercially at the Software Technology Conference in Salt Lake City, marking the beginning of DOORS’ three-decade run as the industry-standard requirements tool for regulated programs.

The Origins of DXL

DXL emerged from a practical need inside QSS itself. According to accounts from early DOORS practitioners, a QSS employee created DXL as a personal productivity tool to automate repetitive requirements management tasks. The language was effective enough that management took notice, customers requested access, and DXL became an official product feature shipped with DOORS. This bottom-up, automation-first origin explains much about DXL’s character: it is designed to get things done within DOORS, not to be a general-purpose programming language.

DXL shipped as part of the first commercial DOORS release in 1993. Its exact form and capabilities in those early years are not comprehensively documented in public sources, but by the time DOORS reached wide industry adoption in the late 1990s, DXL was already the established mechanism for customization and automation.

Corporate Ownership Changes

DOORS and DXL passed through three owners in the decade following commercial release:

• QSS (1993–2000): Created and maintained DOORS as an independent product.
• Telelogic AB (2000–2008): Swedish systems engineering firm that acquired QSS and integrated DOORS into its engineering tool portfolio.
• IBM (2008–present): IBM acquired Telelogic in 2008 for a reported sum of approximately $745 million. DOORS moved into IBM Rational, was later rebranded IBM Engineering Requirements Management DOORS, and continues there today.

Each ownership transition preserved DXL as-is. Unlike many acquisitions that result in language replacement, IBM maintained DXL’s core design because breaking the scripting layer would have disrupted the enormous installed base of DXL automation scripts in production at aerospace and defense customers.

Design Philosophy

DXL is unapologetically specialized. It does not aim to be a general-purpose scripting language; it aims to let DOORS users manipulate requirements data with minimal friction. Several design choices reflect this:

Relaxed syntax over strictness. DXL is syntactically influenced by C and C++, but deliberately relaxes many of C’s requirements. Semicolons and parentheses are optional in many contexts. There is no main() function — a DXL script is a sequence of statements that executes top-to-bottom. The goal was to make DXL accessible to engineers who were familiar with C-like code but not professional programmers.

Auto-typing for variables. Variables need not be explicitly declared with a type before use. DXL infers types from context. This reduces boilerplate and lowers the barrier for occasional scripters, at the cost of less rigorous compile-time checking.

No pointers. C’s pointer semantics are absent from DXL. This simplifies the language considerably and eliminates an entire category of bugs that would be particularly problematic in an environment where scripts manipulate live requirements databases.

Direct access to DOORS internals. DXL code can directly reference DOORS data structures — modules, objects, attributes, links — using built-in types and functions. The language has first-class knowledge of the DOORS object model. This tight coupling means DXL scripts are short, expressive, and directly meaningful to anyone who knows DOORS.

Language Features

Data Types

DXL provides a set of built-in types that map directly to DOORS concepts:

This set covers almost everything a DOORS user would want to script against, without requiring any wrapper or adapter layer.

Control Structures

DXL provides standard procedural control flow:

// Standard conditional
if (someCondition) {
    // ...
} else {
    // ...
}

// While loop
while (condition) {
    // ...
}

// C-style for loop
for (i = 0; i < 10; i++) {
    // ...
}

The most distinctive control structure is the for...in...do loop, which iterates over all elements of a DOORS collection:

Module m = read("/MyProject/Requirements", false)
Object o
for o in m do {
    string reqText = o."Object Text"
    if (length(reqText) > 500) {
        print "Long requirement: " reqText "\n"
    }
}

This construct reflects DXL’s DOORS-first philosophy: iterating over every object in a module, every attribute in an object, or every link in a link set is so common that DXL makes it a native language construct rather than a library call.

Functions and Modules

DXL supports user-defined functions with typed or auto-typed parameters:

string formatAttr(Object o, string attrName) {
    string val = o.attrName
    if (null val) return "(none)"
    return val
}

DXL scripts can also include other DXL files, enabling code reuse across scripts. Many organizations maintain internal libraries of DXL utility functions — for generating reports, enforcing naming conventions, or managing link sets — that are included by individual scripts.

A Practical DXL Example

The following script opens a DOORS module, iterates over all objects, finds requirements that lack a linked test case, and prints a report:

Module reqModule = read("/MyProject/SystemRequirements", false)
Module testModule = read("/MyProject/TestCases", false)

if (null reqModule) {
    print "ERROR: Could not open requirements module\n"
    halt
}

Object req
int untracedCount = 0

for req in reqModule do {
    string reqId = req."Req ID"
    if (null reqId || reqId == "") continue

    // Check if this requirement has an outgoing link to the test module
    Link lnk
    bool hasTest = false
    for lnk in req -> do {
        if (target(lnk) in testModule) {
            hasTest = true
            break
        }
    }

    if (!hasTest) {
        print "Untraced: " reqId " - " req."Object Text" "\n"
        untracedCount++
    }
}

print "\nTotal untraced requirements: " untracedCount "\n"
close(reqModule)
close(testModule)

This is representative of real-world DXL use: navigating DOORS data structures, following link relationships, and producing compliance-relevant output.

Execution Model

DXL is an interpreted language. There is no separate compilation step — scripts are parsed and executed by the DOORS runtime. This means:

• Scripts can be written and run immediately without a build toolchain.
• Errors are discovered at runtime rather than compile time.
• Execution speed is bounded by the DOORS interpreter, not a compiled artifact.

DXL scripts can run in three modes:

1. Interactive mode: Executed directly from the DOORS Tools menu or script editor.
2. Batch mode: Invoked from the command line using the DOORS batch client, enabling integration with CI pipelines, scheduled automation, or external build systems.
3. Triggered mode: Attached to DOORS events (module opens, object saves, attribute changes) so the script fires automatically when specific actions occur.

Batch mode is particularly important for regulated programs, where generating compliance reports must be reproducible, auditable, and integrated into formal release processes without manual steps.

Evolution and the DOORS Next Generation Split

For its first two decades, DXL evolved incrementally alongside DOORS Classic. New built-in functions were added as DOORS gained features, but the language’s core design remained stable. This stability was a feature, not a bug: DXL scripts written in 2000 largely still run in 2025, which matters enormously to programs that may span decades.

The significant architectural rupture came in 2012 with DOORS Next Generation (DNG). IBM had acquired Telelogic with the intent to rationalize its multiple requirements tools, and DNG was the result: a modern, web-based, OSLC-standard requirements platform designed for cloud deployment and enterprise scale. DNG’s customization and automation model is built on JavaScript, not DXL, and IBM has explicitly stated it has no plans to implement a DXL interpreter for DNG.

This created a permanent split in the DOORS ecosystem:

Organizations running long-lived programs — where the requirements baseline has been in DOORS Classic for 10, 20, or 30 years — continue to use DXL because migration to DNG is costly, risky, and not obviously beneficial for programs that are already near completion. Organizations starting new programs, particularly outside of traditional aerospace/defense, increasingly choose DNG or competing tools.

As a result, DXL occupies an unusual position: it remains in active production use at organizations that represent some of the highest-stakes engineering on Earth, while simultaneously being a language that IBM no longer actively extends and that new engineers are increasingly unlikely to encounter.

Current Status

IBM Engineering Requirements Management DOORS 9.7.x is the current maintained release of DOORS Classic, and the DXL scripting interface it provides remains fully functional. IBM publishes the DXL Reference Manual as formal product documentation. There is no announced end-of-life date for DOORS Classic, and given the depth of investment that aerospace and defense programs have in their DOORS databases, it is likely to remain in service for years to come.

There is no official Docker image for DOORS or DXL. DOORS Classic is a client-server application with license management requirements that make containerization non-trivial. Some organizations have constructed custom container-based solutions for running DOORS in batch mode for CI/CD integration, but these are organizational implementations rather than publicly available images.

The DXL community is small but specialized. Resources include the IBM documentation, a small number of practitioner blogs, and institutional knowledge held within aerospace and defense organizations. There is no public package registry or open-source ecosystem in the way that exists for general-purpose languages.

Why DXL Matters

DXL matters because DOORS matters, and DOORS is embedded in programs where failure is measured in lost lives rather than lost revenue. When an airliner lands, when a satellite achieves orbit, when a pacemaker functions correctly, requirements management was part of the engineering process that made it possible — and in many of those programs, DOORS was the tool and DXL was the automation language.

The language also illustrates an important pattern in software history: domain-specific languages that are deeply embedded in specialized tools can achieve remarkable longevity precisely because switching costs are prohibitive. DXL is not the best-designed scripting language, but it is the language that works inside DOORS, and for programs where the DOORS database represents decades of engineering work and formal approval from safety regulators, “works inside DOORS” is all the justification needed.

For software archaeologists, DXL is a fascinating case: a language that has barely changed in thirty years, that most software engineers have never encountered, but that quietly runs at the heart of some of the most consequential engineering programs in existence.