S1000D Data Module Codes: Structured Identity and Faceted Navigation

When an aerospace or defense program states that its technical publications are in S1000D, it does not possess a collection of web pages waiting for CSS. It possesses a controlled, relational information model. The single most expensive mistake a conversion team can make is treating the Data Module Code (DMC) as an arbitrary filename or a primary key string.

A DMC is a hyphen-segmented, fixed-width coordinate. Every segment encodes a distinct operational dimension: the product line, physical system breakdown, disassembly sequence, information intent, and maintenance tier. Decomposed at intake, it provides a zero-cost navigation taxonomy and high-performance search facets. Preserved as an opaque string, all of that structural intelligence is lost.

Deconstructing the DMC Anatomy

Under S1000D Issue 4.1, 4.2, and 5.0 specifications, a standard DMC follows a strict grammatical structure. Consider this representative module taken from the specification's standard aerospace sample dataset:

DMC-S1000D-F-04-10-0301-00A-022A-D
|   |      | |  |  |    |   |    |
|   |      | |  |  |    |   |    +- Item Location Code (D = All / Flight-line)
|   |      | |  |  |    |   +------ Information Code & Variant (022A = Descr. of Operation)
|   |      | |  |  |    +---------- Disassembly Code & Variant (00A = Top Assembly)
|   |      | |  |  +--------------- Assembly Code (0301 = Recirculation Valve)
|   |      | |  +------------------ Subsystem / Sub-subsystem (10 = Air Distribution)
|   |      | +--------------------- System Code (04 = Air Conditioning / Pressurization)
|   |      +----------------------- System Difference Code (F = Variant / Engine Option)
|   +------------------------------ Model Identification Code (S1000D Project)
+---------------------------------- Literal DMC Prefix (Optional in markup, standard on disk)

Notice what those characters tell you before you inspect a single byte of XML markup. You know the exact physical system (Air Conditioning, Subsystem 10), the precise component (Assembly 0301), what kind of action the technician is performing (Information Code 022 represents an operational description, distinguishing it from 520 removal procedures or 720 testing routines), and where the maintenance takes place (Location D indicates field-level line maintenance).

The Three Query Channels

Parsing the DMC string into structured fields yields three parallel query dimensions that feed the delivery application:

• Channel 1 — Physical System Hierarchy (SNS): System (04), Subsystem (10), and Assembly (0301) form the Standard Numbering System (SNS). This creates a structured table-of-contents tree automatically, eliminating the need to maintain artificial navigation hierarchies.
• Channel 2 — Operational Intent (Information Code): Information Code 022 defines the content type. Technicians constantly want to toggle between description, procedural removal, installation, and fault isolation for the same part. The information code enables instant filtering across thousands of modules with zero text processing.
• Channel 3 — Operational Context (Item Location Code): Location D denotes flight-line maintenance. Code A denotes installed on-aircraft, B denotes component shop, and C denotes depot overhaul. A flight-line technician's tablet can immediately filter out depot-level teardown procedures that do not apply to their workspace.

Implementation: Typed Decomposition & Query Routing

The code below demonstrates a production-grade DMC parser with full AST tokenization, validation against S1000D Issue 4.2 regex patterns, and generation of multi-axis facet indexes for in-memory or SQLite FTS5 search engines.

/**
 * Canonical S1000D Data Module Code (DMC) AST.
 * Conforms to S1000D Issue 4.1/4.2 Chap 3.9.5.1 specification.
 */
export type ItemLocation = "A" | "B" | "C" | "D";

export type DataModuleCode = {
  raw: string;
  modelIdentCode: string;       // e.g. "S1000D" (2-14 chars)
  systemDiffCode: string;       // e.g. "F" (1-4 chars)
  systemCode: string;           // e.g. "04" (SNS System, 2 chars)
  subSystemCode: string;        // e.g. "1" (SNS Subsystem, 1 char)
  subSubSystemCode: string;     // e.g. "0" (SNS Sub-subsystem, 1 char)
  assyCode: string;             // e.g. "0301" (Assembly, 2-4 chars)
  disassyCode: string;          // e.g. "00" (Disassembly, 2 chars)
  disassyCodeVariant: string;   // e.g. "A" (Disassembly variant, 1 char)
  infoCode: string;             // e.g. "022" (Information type, 3 digits)
  infoCodeVariant: string;      // e.g. "A" (Information variant, 1 char)
  itemLocationCode: ItemLocation; // e.g. "D" (Maintenance tier, 1 char)
};

export type DmcFacetFilter = {
  systemCode?: string;
  infoCodes?: string[];
  itemLocation?: ItemLocation;
  systemDiff?: string;
};

The Filename Trap & Identity Boundaries

A pervasive anti-pattern in conversion projects is reading the DMC directly from the file name on disk. A typical file exported from an authoring Common Source Data Base (CSDB) looks like this:

DMC-S1000D-F-04-10-0301-00A-022A-D_003-01_EN-US.XML

The trailing tokens — `_003-01_EN-US` — are not part of the Data Module Code. They represent the `issueNumber` (Issue 003, in-work revision 01) and the language/country code (`EN-US`). In S1000D architecture, these attributes belong strictly to the `<identAndStatusSection>`, inside the `<issueInfo>` and `<language>` XML elements.

When a converter derives identity from the file path, it produces multiple distinct database records for what is a single data module at different revision states. Downstream cross-references (`<dmRef>`) point to the canonical DMC, not the issue-suffixed file name. The result is instant reference fragmentation: internal hyperlinks break, cycle-detection heuristics fail, and version comparisons become impossible.

What Else the Corpus Carries

While the DMC represents the densest metadata in the specification, it operates within an interconnected ecosystem of structured assets:

• Data Modules (`<dmodule>`): Independent XML documents split into `<identAndStatusSection>` (governing lifecycle, security, applicability, and quality assurance) and `<content>` (carrying descriptive, procedural, or fault isolation data).
• Publication Modules (`<pm>`): XML documents that assemble data modules into coherent publication structures. The publication hierarchy is separate from the physical SNS breakdown, allowing one corpus to assemble into both a flight manual and a line-maintenance handbook.
• Common Information Repositories (CIR): Centralized data modules holding shared definitions for tools, warnings, cautions, consumables, and parts. Modules reference CIR items by identifier rather than duplicating text inline.
• Interactive Vector Hotspots: Scalable Vector Graphics (SVG) or Computer Graphics Metafiles (WebCGM) equipped with `<hotspot>` tags that bind directly to Illustrated Parts Catalog (IPC) line items.
• Business Rules Exchange (BREX): Machine-readable rule sets dictating permissible elements, attribute conventions, and structural constraints across the project.

The Operational Payoff

Converting S1000D is not an exercise in HTML string formatting. It is the ingestion of a rigorous relational data model into a runtime application. When you treat the DMC as data rather than an opaque string, search relevance, faceted navigation, configuration filtering, and procedural drill-down stop being complex features you must construct from scratch — they become direct queries against structure you already own.