Data module types

Every data module holds one kind of information. S1000D gives each kind its own schema, so the structure matches the content. A removal procedure uses a different schema from a parts list, and a parts list uses a different schema from a fault chart. The schema you choose is recorded in the data module's metadata and drives validation.

note

The data module type is set by the schema the module conforms to, not by the information code in the Data Module Code. The two should agree — a procedural module should carry a procedural information code (for example a 500-family code for a removal) — but they are separate fields.

The common types

The five types below cover most of the content in a typical technical publication. Each is explained in one sentence.

• Descriptive — a general-purpose module for descriptive text; it tells the reader what something is and how it works.
• Procedural — a step-based module that tells the reader how to do a task, such as a removal, an installation, or a servicing job.
• Fault — a dedicated structure for fault isolation, including charts that guide the reader from a symptom to its cause.
• Illustrated parts data (IPD) — the building block for an illustrated parts catalogue; it links a figure to a parts list so each item can be identified and ordered.
• Process — a module that integrated systems use to deliver maintenance information dynamically, driven by the state of the equipment.

tip

If you are unsure which type to use, start with descriptive for "what it is" content and procedural for "how to do it" content. These two carry most of a manual.

The full set

S1000D defines many more types beyond the common five. The table below lists the main ones and what each is for. Schema names are shown as examples; the exact file names change between issues.

Type	Schema (example)	Purpose
Descriptive	descript	General descriptive text.
Procedural	proced	Step-based task procedures.
Fault	fault	Fault isolation, including fault charts.
Illustrated parts data	ipd	Parts catalogue linked to figures.
Process	process	Dynamic, system-driven maintenance delivery.
Wiring data	wrngdata	Wire, harness, equipment, and standard-part data.
Wiring data description	wrngflds	Project-specific field descriptions for the elements in a wiring-data module.
Maintenance planning (schedule)	schedul	Maintenance planning and scheduled-task information.
Checklist	checklist	Maintenance checklist content.
Crew / operator	crew	Operational checklists and related descriptive information.
Container	container	A wrapper that holds alternative modules for the same result.
Learning	learning	Technical training content (added in Issue 4.0, which also defined the S1000D–SCORM relationship).
Business Rules Exchange (BREX)	brex	A project's business rules in machine-checkable form.
Applicability cross-reference table	appliccrossreftable	The hub of applicability handling.
Condition cross-reference table	condcrossreftable	Common applicability conditions.
Product cross-reference table	prdcrossreftable	Product and condition attributes per instance.
Common information repository (CIR)	comrep	A shared repository data module that holds common, reusable objects — such as functional items, parts, tools, supplies, zones, access points, warnings, cautions, and externalized applicability — so other modules can reference them instead of repeating them. (Called the technical information repository, schema techrep, before Issue 4.1.)

info

BREX is a data module too. The Business Rules Exchange is not a separate file format. It is a data module with its own schema that encodes the rules every other module must follow. Each data module references a BREX, and validation checks the module against it. See Business rules & BREX.

How the type fits the content

A few notes that explain why the list is shaped this way:

• Fault modules can present fault isolation as a chart, so the reader follows branches instead of reading flat text. A plain procedure cannot do this, which is why fault has its own schema.
• IPD modules separate the catalogue structure (figure plus item list) from the descriptive and procedural content around them. This keeps parts data consistent and reusable.
• Cross-reference tables (applicability, condition, product) are not reader-facing pages. They hold the data that decides which content applies to which version of the product.
• Container modules do not hold content of their own. They wrap two or more modules that offer alternative ways to reach the same result.

The exact set of schemas, and some of their names, has changed across issues. For a given project, the available types are fixed by the issue you target and constrained further by your BREX.

Sources

• S1000D — Wikipedia — data modules as the structured, self-contained, reusable unit of S1000D.
• Adobe FrameMaker — S1000D data module types — descriptions of each data module type and schema.
• S1000D Schemas for Issues 1.9 through 6 (Medium) — how schema names and the set of types changed across issues, including the learning schema and the techrep → comrep rename.
• The Emperor's New Clothes (S1000D blog) — Issue 4.1 reworked the technical information repository (TIR) into the common information repository (CIR), and the comrep schema's object types (functional items, parts, tools, supplies, zones, warnings, cautions, externalized applicability, and more).