The Common Source Database (CSDB)
The Common Source Database (CSDB) is the central store for an S1000D project. It holds every reusable information object in one place. You author the content once. You then use it many times, in many publications and many output formats.
The CSDB is the database that S1000D is built around. The full name of the specification is "the international specification for technical publications using a common source database." So the CSDB is not an optional add-on. It is the core idea.
What the CSDB stores
The CSDB contains all of the information objects that a project needs to build its technical publications. These objects include the following.
| Object | Short name | What it holds |
|---|---|---|
| Data module | DM | A self-contained, reusable unit of information (XML metadata + content). |
| Illustration / graphic | ICN | A non-text object — a figure, diagram, or multimedia file — identified by an Information Control Number. |
| Multimedia | ICN | Video, animation, and audio files, also identified by an ICN. |
| Publication module | PM | A list that says which data modules to include, and in what order, to form a publication. |
| Management and common information | — | Comments, data dispatch notes, the BREX rules, and other project control data. |
An ICN (Information Control Number) is the unique identifier of an illustration sheet or multimedia object in the CSDB. A data module references an ICN; it does not embed the graphic. In earlier issues of the specification, "ICN" stood for Illustration Control Number. From Issue 4.0, an ICN can be built from a CAGE code or a model identifier.
Source once, use many
The CSDB does not duplicate content. The same data module, or the same graphic, is stored once. A publication module can then call that single object as many times as it is needed.
This gives a clear benefit. If you correct a procedure or a figure, you edit the one source object. Every publication that uses that object picks up the change. You do not hunt for copies. The same data module can also appear in more than one publication, and a goal of S1000D is to let a data module be reused across different projects.
"Source once, use many" is the main reason S1000D scales. The cost of an update does not grow with the number of publications that share the content.
From a folder to enterprise software
The specification defines what a CSDB must contain. It does not force you to buy a product. The CSDB can range from very simple to very capable.
- Simple: a folder on your computer that holds the data modules and the other content objects. This is enough to learn the specification and to build small projects. The open-source s1kd-tools work directly on files in a directory, so a plain folder is a working CSDB.
- Enterprise: dedicated software that stores the publication objects and manages them across the full lifecycle of the project — versioning, workflow, applicability, multi-user authoring, and release.
This site is generated by techwriter.ai watching the s1kd-tools repository — a free, open-source command-line toolchain for S1000D. With those tools, a directory of XML files acts as the CSDB, so the "folder" end of the range is real and usable today.
The pipeline: from objects to output
The diagram below shows how the CSDB sits at the centre of the workflow. Authors create data modules and graphics. The CSDB stores them. Each data module is validated against the project's BREX (Business Rules EXchange) data module. A publication module then assembles the approved data modules into a publication, which is rendered as an IETP or a PDF.
The BREX step is a real gate, not a label. Every data module must reference a BREX data module, and its content is checked against those rules. A data module that fails validation goes back to the author for correction before it can be published. See Business Rules & BREX for detail.
How the parts relate
| Stage | Object | Role |
|---|---|---|
| Author | Data module + ICN | Create the smallest reusable units of content and graphics. |
| Store | CSDB | Keep one copy of every object; manage and reuse it. |
| Validate | BREX | Check each data module against the project's machine-readable rules. |
| Assemble | Publication module | Select data modules and set their order to form a publication. |
| Deliver | IETP / PDF | Render the assembled publication for the reader. |
Because the CSDB stores each object once, the publication module step is cheap and repeatable. You can build many different publications — for different audiences or formats — from the same shared pool of data modules.