Glossary · 2 · Topics and information design

Topic (technical communication)

Also known as: Topic module, Information topic, Content topic

German: Topic

In technical communication, a topic is a self-contained unit of content that covers a single subject and serves a single purpose, written so that it makes sense without the content that precedes or follows it. Topics are the units that authors write, review, approve, translate, reuse, and assemble into deliverables such as manuals, help systems, and content delivery portals. The general concept is not fixed by a single standard: structured formats such as DITA and iiRDS each define their own topic constructs, and in-house information models define topic types of their own. What the implementations share is the pairing of one title with one subject and one communicative purpose.

topic
topic-based authoring
structured authoring
information design
content reuse

In one sentence

A topic is a self-contained content unit on one subject with one purpose — the building block of topic-based documentation.

Example

A machine builder writes "Replacing the filter cartridge" as a single topic with its own title, prerequisites, and steps, then assembles it into the operating manual, the maintenance manual, and the service portal without rewriting it.

A topic is the smallest piece of content that is still worth publishing on its own. The OASIS DITA architectural specification describes it as "a unit of information with a title and content, short enough to be specific to a single subject", yet long enough to be authored and understood as a unit. The iiRDS standard uses the same idea in its metadata model, where a topic is a "self-contained piece of information which deals with a single subject" that the reader understands without additional information.

The word is used at two levels, and mixing them causes most of the confusion in projects: as a general design concept (one subject, one purpose, standalone), and as a concrete construct in a format or tool (a <topic> element in DITA, an iirds:Topic resource in iiRDS, a content object in a CCMS). The general concept can be followed in Markdown, HTML, FrameMaker, or a wiki; the constructs add schemas, metadata, and processing rules.

How it applies

Scoping. Decide the subject and the purpose before writing: one procedure, one concept, one data set. If a draft needs two titles to describe it, it is usually two topics.
Standalone test. Read the topic cold, without its neighbors. Cross-references such as "as described above" or "in the previous chapter" break the test and the reuse that depends on it.
Information typing. Most models sort topics into types — task, concept, reference — so that each type gets a predictable structure. See DITA information typing for the best-known implementation.
Assembly. Order and hierarchy belong to a separate artifact, not to the topic: a DITA map, a CCMS publication structure, or a navigation model in a delivery portal.
Machinery documentation. Safety instructions, maintenance intervals, fault tables, and spare-part data are natural topics; the same maintenance topic can feed the printed manual, the HMI help, and an iiRDS package for a service portal. Note that topic structure organizes content — it does not by itself satisfy any legal requirement for information for use or instructions for use; the applicable legislation and standards decide what must be delivered.
Software documentation. Release-independent concept topics age differently from UI-bound task topics; topic granularity lets teams version and retire them separately. Standards for software user documentation, such as the ISO/IEC/IEEE 2651x series (ISO/IEC 26514, first published 2008, with a later ISO/IEC/IEEE 26514:2022 edition), set requirements for the structure and content of user documentation; whether and how they use the word topic has to be read in the standard edition that applies to you.
Metadata and findability. Because a topic is addressable, it can carry its own taxonomy or ontology values — product, component, task, audience — which is what makes filtered, query-based delivery possible.
Translation and review. Topics are convenient review and translation units, but only if they are stable: renaming or re-splitting topics invalidates review records and reduces translation-memory leverage.
Governance. Give each topic an owner, an ID that does not change, and a review status in your information model; "the chapter" is no longer a usable unit of accountability once content is modular.

Topic vs. DITA topic vs. iiRDS topic

Topic (general concept): a design rule for content units — one subject, one purpose, understandable alone. Format-independent, enforced by editorial guidelines rather than by software.
DITA topic: an XML document type defined by the OASIS DITA specification, with a title, body, and prolog, specialized into types such as task, concept, and reference, and validated against a DITA grammar. Here the rule is machine-checkable through schema validation, and it can be extended through specialization.
iiRDS topic: a metadata class (iirds:Topic, a subclass of iirds:InformationUnit) that describes and points to a self-contained content unit inside an iiRDS package. iiRDS classifies and delivers the unit; it does not prescribe the markup inside it, so the referenced content may be XHTML, a PDF page, or another format.

In SKOS terms, the DITA topic and the iiRDS topic are narrower, implementation-specific terms under the general concept — not synonyms for it. A document can satisfy the general concept without being either, and an XML file can be a valid DITA topic while still failing the standalone test editorially.

Topic vs. chapter

A chapter is defined by its position in a sequence; a topic is defined by its subject and purpose. Chapters assume linear reading and can rely on what came before; topics assume arbitrary entry points, which is why topic-based deliverables repeat prerequisites instead of referring back. Converting legacy chapters into topics is therefore a rewriting task, not only a splitting task.