Skip to main content

Data-module-type index

S1000D does not store all content in one shape. Each kind of information uses a dedicated XML schema. The schema you choose fixes the structure of the data module and tells authoring and publishing tools how to read it.

This page maps the common data module types — plus a few related Common Source Database (CSDB) object types — to their purpose and typical content. Use it as a lookup when you decide which schema a new module needs.

note

A data module (DM) is the self-contained, reusable unit of S1000D content. It holds identification and status metadata plus the content itself, and it carries a unique Data Module Code (DMC). The type of a data module is set by its schema, not by its DMC. Two modules can share a Standard Numbering System value yet use different schemas (for example, a descriptive module and a procedural module about the same component).

Core data module types​

These are the schemas you will use most often.

TypeSchema rootPurposeTypical content
DescriptivedescriptDescribe a system, component or concept.Text, tables and illustrations. General purpose; good for legacy data.
ProceduralprocedGive a maintenance procedure as ordered steps.Preliminary requirements (tools, supplies, conditions), numbered steps, warnings and cautions, closing steps.
FaultfaultSupport fault isolation.Fault descriptions, isolation logic and tests; can be shown as a fault tree or chart.
Illustrated Parts Data (IPD)ipdIdentify parts for ordering and assembly.Labeled illustrations linked to a parts list with item numbers, part numbers and quantities.
ProcessprocessDrive interactive (IETP) sessions.Scripted logic that an integrated system runs to deliver maintenance information dynamically.
Wiring datawrngdataHold electrical interconnection data.Wire, harness, equipment and standard-parts data used to generate wiring diagrams.
Wiring data descriptionwrngfldsDescribe the wiring set.Layout, routing, access and maintenance information about the wiring.
Crew / operatorcrewSupport operating crews.Operational checklists and references, such as flight reference cards and flight manuals.
Maintenance scheduleschedulPlan preventive maintenance.Scheduled tasks, intervals and thresholds.
ChecklistchecklistRun inspections and maintenance checks.Maintenance checklists and inspection items (the checklist schema was introduced in Issue 4.0.1).
ContainercontainerGroup alternative modules.A wrapper that points to two or more data modules giving alternative ways to reach the same result.
LearninglearningSupport technical training.Reusable learning content and structures for training material.

Business rules, applicability and repository types​

These types do not describe the product directly. They manage how a project's data set behaves: its rules, its applicability and its shared values.

TypeSchema rootPurposeTypical content
Business Rules EXchange (BREX)brexEncode a project's business rules so they can be checked by machine.Structural and value rules that every other data module is validated against.
Applicability Cross-reference Table (ACT)appliccrossreftableAct as the hub for applicability.The product attributes and conditions used to decide what content applies to which product.
Condition Cross-reference Table (CCT)condcrossreftableDefine reusable conditions.Common applicability conditions referenced across the project.
Product Cross-reference Table (PCT)prdcrossreftableDescribe product instances.Attribute and condition values for individual product instances.
Common Information Repository (CIR)comrepStore shared data once.Centrally managed values (for example supply or warning data) reused by many modules for consistency.
info

Every data module must reference a BREX. The BREX module is a real data module — it just carries rules instead of product content. Validating a module against its BREX is how a project enforces its own conventions on top of the base S1000D schemas. See the Business Rules & BREX page for detail.

The CSDB stores more than data modules. The objects below are not data modules, but you handle them alongside data modules, and S1000D defines schemas for them.

ObjectSchema rootPurpose
Publication modulepmDefine a publication: which data modules to include and the order and structure (chapters and sections) in which they are delivered.
Data Management List (DML)dmlList data modules for exchange and configuration management between organizations.
CommentcommentCapture review comments against CSDB content.
Data Dispatch Note (DDN)ddnAccompany a delivery of CSDB objects between parties.
tip

Think of the publication module as the table of contents and assembly plan. It does not contain procedure text or part numbers itself. It references the data modules and sets their sequence, so the same source modules can be assembled into different publications.

Choosing a type​

A quick way to pick a schema:

  • Plain "what it is" text, or no better fit -> descriptive (descript).
  • "How to do it" in ordered steps -> procedural (proced).
  • "What is wrong and how to find it" -> fault (fault).
  • Parts to order or assemble -> IPD (ipd).
  • Electrical interconnections -> wiring (wrngdata / wrngflds).
  • Rules the project must follow -> BREX (brex).
  • The shape of the final book -> publication module (pm).
note

The set of schemas grew over time. Legacy types such as descript, proced, ipd, fault, schedul and dml date from the early issues. Later issues added types like brex, the cross-reference tables, container, learning and checklist. The exact list — and the precise element rules inside each schema — is defined by the issue of S1000D your project uses. Always check against your target issue.

info

Example only. A descriptive module about a hydraulic tank might use a DMC such as DMC-EX-A-29-10-05-00A-040A-D (where 040 is a description information code). This DMC is illustrative and is not taken from any real product.

Sources​