To split composite DITA into topics is the step that turns a valid migration into a working single-source library. Your ditabase validates and it is topic-based on paper, but held together as one enormous composite file it cannot be managed at the granularity single-sourcing depends on — per-topic check-in, per-topic reuse, parallel authoring, useful version history. This DITA transformation breaks the monolith into individual infotyped topics, generates the bookmap and the key map that belong with them, and hands your CCMS a library it can actually manage.
A composite DITA file is a comfortable place to land a migration and an expensive place to stay. The working unit of every single-sourcing workflow — reuse management, review, translation, version history — is the topic, and one giant file gives that machinery nothing to hold on to. Your component content management system expects to check topics in and out individually; a monolith checks in as a single blob, which kills parallel authoring and any useful version granularity. And the first time two publications need the same procedure, somebody copy-pastes it — and now you maintain it twice, permanently.
Choosing to split composite DITA into topics is what converts a valid migration into a working library. It is also the step teams most often attempt by hand in an XML editor, one drag at a time: slow, inconsistent, and precisely where IDs and links quietly break. Automating the split removes both the tedium and the risk.
The conversion reads the composite end to end and breaks it into individual topics, working out the right infotype for each — concept, task, reference or glossentry — instead of dumping everything into generic topics somebody has to classify later. Your headings decide where the file boundaries fall, and the depth at which that happens is your decision rather than ours: split at chapter level for a coarse library, or deeper where your writers reuse at a finer grain. A topic body that is really an ordered list of steps is promoted to a genuine task instead of being left as a concept with a procedure buried inside it. Assets travel with the topics that reference them.
Around the topics we build the bookmap or map that preserves the original reading order, and generate the key map your reusable references need in order to resolve. The shape of the output tree is yours to set: submaps and subfolders that mirror your information architecture, or a deliberately flat layout when that is what your repository prefers. And your existing identifiers can be preserved exactly as they are, so the inbound cross-references pointing at them keep working after the split.
The composite is read end to end and inventoried: the nested topic structure, the heading hierarchy that will become file boundaries, the identifiers already in use, and every referenced asset. Reading order is taken from the document itself and never reconstructed or guessed.
Topics are split at the level you chose and each is classified as concept, task, reference or glossentry. Bodies that are genuinely procedural become task topics — an ordered list of instructions is rebuilt as real steps rather than left buried in a concept — while a topic the composite already holds as an authored concept, task, reference or troubleshooting topic keeps its authored type instead of being re-guessed from its title.
Every reference the split moves is re-addressed rather than left to luck: cross-references and content references — conref and conref ranges included — are rewritten onto the files their targets land in, key-based references are checked against the keys the run defines, and a reference that genuinely cannot be resolved is left exactly as authored and reported, so a dangling reference can never hide inside a clean-looking run. A key map is generated across the new topic set, identifiers are preserved or regenerated to your convention, and filenames and folders follow your naming and foldering rules, so the output is addressable exactly the way your repository expects.
Our DITA completeness check runs across the split output: well-formedness, DTD conformance, links, conref, keyref, image references and — critically for a split — duplicate IDs or keys and any circular map chains introduced along the way.
You receive a topic-per-file tree with its bookmap or map, submaps and subfolders where you wanted them, the generated key map, and every reference intact, in the layout your CCMS or DITA-OT build expects.
A generic split gives you valid, well-formed topics with inferred infotypes, generated IDs and a serviceable map — a correct starting point. A customer-specific split goes further: it maps to your DITA specialization and element rules, applies your ID, filename and folder conventions, follows your key-naming scheme so the generated key map matches how your writers actually reference content, and validates against your own DTD. The difference is simply whether the package checks straight into your CCMS or waits for somebody to reshape it first.
| Your concern | How we answer it |
|---|---|
| Our CCMS rejects anything that is not a task under /tasks/ with a t_ prefix. | Customer-specific conventions produce exactly that layout and those identifiers on the first pass, so the package checks straight in. |
| We have thousands of inbound links to existing topic IDs. | Your original identifiers are preserved on request, so those cross-references survive the split and keep resolving. |
| Will the split lose any text? | Content conservation is a hard rule — structure is reshaped, never silently discarded: the rare construct that cannot survive the split (a cross-reference standing alone at body level, say) is called out in the run log for your review instead of vanishing. |
| We do not want a flat dump of hundreds of files. | Submaps and subfolders shape the tree to mirror your information architecture, at whatever depth you choose. |
Today this work is usually done by hand in an XML editor, or with a brittle one-off script that a single author wrote and nobody else can maintain. Both struggle at scale, and both are where reference integrity goes to die: an author splits a topic, forgets that three others linked into a heading that is now a separate file, and the links dangle silently until a customer finds them. DocentraX runs the split as a repeatable, configurable operation with source-native reading order, every moved reference rewritten onto the file its target landed in, and a repository-scale completeness check on the way out, so integrity is verified rather than assumed. It is one stage of a wider DITA transformation practice that also covers the reverse operation — merging split topics back into a composite per publication — and it pairs naturally with our Word to DITA conversion, which produces exactly the kind of composite this service then splits.
What you get back is not a tidier file; it is a content library. Once your content is addressable topics with a real key map, single-sourcing stops being an aspiration: one procedure, reused by reference in every publication that needs it, corrected once when it changes. Conditional publishing, parallel authoring and clean multi-channel output through DITA-OT all depend on that granularity. The monolith that validated but could not be reused becomes a set of assets your organisation can compose, profile and publish — which was the whole point of moving to DITA in the first place.
Run the composite through the conversion. It reads the file end to end, splits it at the heading depth you choose, and writes one infotyped topic per file — concept, task, reference or glossentry. It also builds the bookmap or map that preserves your reading order, plus a key map, so the topics are immediately usable in a CCMS or a DITA-OT build.
A ditabase is a single composite file holding many topics inside one document; split DITA is one topic per file, each a unit of its own. Most CCMS and single-sourcing workflows require the split form, because check-in and check-out, versioning, review, translation and reuse management all operate on topics as individual units — which one composite blob cannot offer.
Not if you keep your original identifiers, which the conversion can preserve exactly as they are. Internal references are actively re-addressed — xref, link and conref alike are rewritten onto the files their targets land in, and anything unresolvable is reported rather than guessed — and the completeness check then verifies links, conref and keyref after the split, flagging duplicate IDs or circular map chains before anything is delivered.
Yes. A bookmap or map is built that preserves the source reading order, and a key map is generated across the new topic set so reusable references have somewhere to resolve. You also decide how the tree is shaped — submaps and subfolders mirroring your information architecture, or a flat layout if that is what your repository prefers.
Yes. Each split topic is classified as a concept, task, reference or glossentry rather than emitted as a generic topic, a topic that already carries an authored type keeps it, and how assertively the typing of the rest is applied is tuned to your content. A body that is essentially an ordered list of steps is promoted to a real task, so procedures arrive as procedures.
We'll convert them to DITA free of charge — through the real pipeline, not a demo — and review the output with you. Then we'll discuss pricing one-to-one.
Request your free sample conversion