Glossary · Specialization and domains
DITA constraint
Also known as: constraint, constraint module, expansion module
In DITA, a constraint is a modification of a document type that restricts the content model or attributes of existing elements — for example making an optional element required or removing elements — without creating new semantics. Constrained documents remain valid against the unconstrained document type.
- DITA
- Architecture
In one sentence
A DITA constraint restricts an existing content model — making elements required, fixing their order or removing them — without new semantics.
Example
The strict task body constraint allows each task section only once and in a fixed order: prerequisites, context, steps, result, example, follow-up.
How it applies
- Technical documentation: Constraints tailor DITA to a style guide. A team can remove elements it never uses, require a short description, or fix the order of sections — and editors will enforce it.
- Compatibility: Because constraints only restrict, a constrained document is always valid against the unconstrained document type. Constraint modules are declared in
@domains, for example(topic task strictTaskbody-c)for the strict task body. - Expansion modules: DITA 1.3 added expansion modules, the counterpart to constraints: they extend a content model, for example to allow a domain element in a place where the base model does not.
- AI and retrieval: Constraints make content more predictable. When every task has a short description and a fixed section order, chunking and extraction rules become simpler and more reliable.
Constraint vs. specialization
A constraint makes an existing type stricter without new semantics; content can be exchanged without conversion. A specialization creates a new type that must be generalized for systems that do not know it.
In DITA markup
The domains attribute of a task document type that applies the strict task body constraint:
<task domains="(topic task) (topic task strictTaskbody-c)">…</task>