DITA (Darwin Information Typing Architecture) has been the OASIS standard for technical documentation since 2005. It defines a model for topic-based authoring, content reuse, and conditional publishing. No other format has matched its formal rigor. It is also why most documentation teams under 20 writers never adopt structured authoring at all.
The reason is not DITA's architecture. The reason is the XML.
This article explains what DITA actually is: an information architecture, not a file format. It then prices the XML tax. It maps the DITA concepts that now exist in non-XML tools. And it names what you genuinely lose when you walk away. It is written for technical writing leads evaluating their first move beyond Markdown or a wiki. It also serves teams already on DITA who wonder whether the toolchain still earns its keep.
What DITA actually is
DITA is two things bundled together: an information model and an XML schema. The information model is the valuable part. It defines documentation as a collection of typed topics: concept, task, reference. Maps assemble them. Conditional attributes filter them. Content references reuse them. These are the load-bearing ideas behind every modern component content management system. XML storage is optional. The ideas are not.
The XML schema is the original implementation of that model. It is also where the cost lives. Writing DITA means typing element names like <concept>, <conbody>, <shortdesc>, <prolog>, and <keyword>. Every file validates against the official DTD or RNG schema. The result goes through the DITA Open Toolkit to produce HTML or PDF.
You can run that whole stack with open-source tooling. Most teams do not. Doing it well requires an in-house DITA architect.
The XML tax: what it actually costs
Five concrete costs separate DITA from its modern alternatives. None of them is mysterious. All of them compound.
Tool licenses. A serious DITA setup needs an XML editor that understands the schema. Oxygen XML Editor lists the Professional edition in the high hundreds of dollars per author. Annual maintenance follows after the first year. Adobe FrameMaker runs at subscription pricing per user per month. These are per-seat, not per-team. For a 10-person doc team, that is five figures per year before the CMS.
CMS licenses on top. The editor edits files. It does not store them, version them, manage releases, or push them to a website. For that you need a component content management system. DITA-native options include Heretto and IXIASOFT. DITA-derived options include Paligo. Both categories add hundreds to thousands of dollars per user per month. Plan and seat count set the exact figure.
Publishing engine maintenance. DITA Open Toolkit is free, but configuring it for your house style is a project. Most teams either hire a DITA consultant for the initial setup or use a CCMS that wraps DITA-OT with its own UI. The DIY path means owning a build pipeline. It produces PDF, HTML, and EPUB from XML. It also means managing XSL-FO stylesheets for PDF output. Large enterprises keep doc engineering teams for exactly this work.
Training. A writer fluent in Word or Markdown does not become productive in DITA in a week. Element types. The difference between a topic and a topicref. When to use a conref versus a keyref. How filtering attributes propagate through maps. This is real learning. The OASIS DITA 1.3 specification runs over 2,000 pages across its three packages. Most teams budget 4 to 8 weeks before a new hire is shipping production topics.
Hiring. When you do need to hire, the candidate pool is small. Search "DITA" on LinkedIn and you will find experienced practitioners. Most are already employed at large enterprises where careers were built around the standard. A junior writer with three years of Markdown experience is not a DITA writer. Cheaper hiring buys you a longer ramp.
Take a documentation team of three to fifteen writers shipping product docs. The total cost of running a real DITA stack routinely exceeds the cost of the documentation tool itself. That is the XML tax.
DITA concepts that survive in modern tools
Walking away from DITA does not mean walking away from structured authoring. The architectural ideas are portable. The vocabulary maps almost one-to-one onto modern tools. Those tools store content as JSON, custom binary, or even Markdown with extensions.
Here is the translation table.
| DITA concept | What it does | Modern equivalent |
|---|---|---|
| Topic | Self-contained unit of content with a title | Topic (same name) or page in tools like Paligo, Topicary, Document360 |
| Map | Ordered hierarchy of topic references that form a publication | Map, table of contents, or content collection |
| Topic types (concept, task, reference) | Schema constraints on what each topic can contain | Topic types or templates (less formally enforced) |
| Conditional processing | Attributes that include or exclude content at publish time | Conditions or profiling — same attribute-based filtering |
| Content reference (conref) | Embedding one topic's element into another | Component reuse, block-level or topic-level transclusion |
| Key reference (keyref) | Indirect linking through named keys, resolved per map | Variables for text, link variables for URLs |
| Map-level metadata | Audience, product, platform attributes inherited by all topics | Map metadata or publication target configuration |
Specialization is the mechanism modern tools generally do not replicate. It defines your own constrained topic types by extending the base schema. Say your organization writes API reference using a custom specialization. It requires <methodName>, <endpoint>, and <authType> elements. Very few non-XML tools support that. For most teams, this is a feature they never used.
What you actually lose
Honest accounting matters. If a vendor tells you that you lose nothing by leaving DITA, they are selling you something. Here is what you give up.
Standards-based vendor neutrality. DITA files are plain XML against a published schema. You can move them between Oxygen, FrameMaker, IXIASOFT, and Heretto without conversion. A topic stored as proprietary JSON in tool X cannot be opened in tool Y without an export step. Most modern tools mitigate this with Markdown or DITA export. The round-trip is not always lossless.
Granular specialization. Defining your own topic types with required elements and validation is hard to replicate outside XML schemas. Say you work in a regulated industry. Every safety warning topic must contain specific structured fields. There DITA's specialization is a real feature, not overhead.
Enterprise interop. Aerospace, defense, medical devices, and heavy-equipment manufacturing specify DITA in contracts. If your downstream customer expects DITA deliverables, you need to produce DITA, full stop.
Decades of community work. DITA-OT plugins, XSL-FO stylesheets, learning resources, conferences, and case studies have accumulated for over twenty years. The ecosystem around modern alternatives is smaller and younger.
If none of those losses applies to your team, you are paying the XML tax for nothing.
When to stay with DITA, when to leave
A simple rule. Stay with DITA if any of the following is true.
- You work in a regulated industry where DITA is contractually required or strongly expected.
- You have an internal DITA architect and the maintenance is already absorbed.
- You use specialization for domain-specific topic types that you would have to give up.
- You have more than 30 writers and the scale economics of DITA-OT customization pay back.
Leave DITA if all of the following are true.
- You are a software, SaaS, or developer-tools company shipping product documentation.
- Your team is under 20 writers.
- You do not currently exploit specialization.
- Your tooling line item is a meaningful percentage of your overall doc-ops budget.
- You are losing candidates to the DITA learning curve.
For teams that fit the second profile, the question is which alternative to choose, not whether to switch. We cover the broader question in What Is a CCMS?. The system model is what matters, not the file format.
Modern alternatives, briefly compared
Five tools come up in most "DITA alternative" searches. Here is the practitioner view.
Paligo is the closest functional equivalent to DITA in a hosted CCMS. It stores content in DocBook XML, the other major OASIS standard. It replicates DITA's topic, map, conditional, and reuse model. Paligo is priced on the enterprise end. Check their pricing page for current numbers. If you want a DITA-style workflow with a hosted CMS, Paligo is the leading option. You will pay enterprise rates. See our Topicary versus Paligo comparison for detail.
MadCap Flare is a desktop authoring tool with conditional content, snippets, variables, and multi-channel publishing. It is not DITA-based but covers a similar feature space. Flare is per-seat and Windows-focused. For teams migrating from Flare to a cloud alternative, see Migrate from Flare. Our Topicary versus MadCap comparison covers the head-to-head.
Heretto is a DITA-native cloud CCMS aimed at enterprise teams. It is XML under the hood with a wrapper UI. If you want hosted DITA without running your own DITA-OT, Heretto is a serious option. It is priced accordingly. The trade is that you remain in the XML world. The user interface is friendlier than raw Oxygen. The content underneath is still DITA.
Document360 and similar knowledge-base tools provide basic structured authoring features: categories, variables, simple reuse. They stop short of full conditional processing and topic-level reuse. They are good for help centers, not for product documentation with audience and platform variants.
Topicary implements the DITA conceptual model — topics, maps, conditions, content reuse, variables — in a visual editor backed by JSON storage. There is no XML to learn. Writers see formatted content with inline component blocks and conditional regions. The structure is enforced but invisible. Multi-channel publishing produces HTML, PDF, and Markdown from the same source. We cover the design rationale in Structured Authoring Without the XML.
Docs-as-code in a Git repository is a different set of trade-offs. It is worth reading separately (see Docs-as-Code Limitations).
A note on migration
Migrating away from DITA is not free. You convert your XML topics into the target tool's format. You preserve your conditional attributes and conref links. You rebuild your publishing pipeline. Most modern CCMSes (Topicary included) accept DITA import. The conversion preserves structure and content, and flattens specialization-specific elements into the closest base type. Plan for a sprint or two of cleanup per 500 topics. Pilot the conversion on a small subset before committing.
The conceptual model survives the move. A writer who knows DITA topics, maps, and conditional processing is productive in a modern alternative within a day. The XML expertise is what becomes optional, not the underlying architecture.
That is the right way to read the choice. You are not abandoning structured authoring. You are removing the syntax tax that prevented adoption in the first place.
FAQ
Is DITA dead?
No. DITA is alive and widely used in aerospace, defense, medical devices, and large enterprise documentation. It is losing ground in software and SaaS to lighter alternatives, but the OASIS standard is healthy and the tooling ecosystem is mature. The question is not whether DITA is alive; the question is whether your team needs it.
Can I use Markdown instead of DITA?
For simple documentation, yes. For documentation with conditional content, component reuse, variables, and multi-channel publishing, plain Markdown does not have the features. Markdown extensions like MDX and tools like Docusaurus narrow the gap but do not close it for component-level reuse or audience filtering.
What is the difference between DITA and DocBook?
Both are XML-based OASIS standards for technical documentation. DITA is topic-oriented and assembled through maps; DocBook is book-oriented and structured as a single hierarchical document. DITA is more common in software and hardware documentation; DocBook is more common in open-source projects and book publishing. Paligo uses DocBook internally as its native format.
Do I need an XML editor to write DITA?
In theory no, in practice yes. You can edit DITA files in any text editor, but without schema-aware autocomplete and validation, you will produce invalid XML constantly. Oxygen XML Editor and Adobe FrameMaker are the two dominant commercial options. A handful of teams use VS Code with XML extensions, but the experience is rougher.
How long does DITA training take?
Most teams report 4 to 8 weeks before a new writer is productive in DITA, depending on prior structured authoring experience. A writer coming from Markdown will be slower; a writer coming from FrameMaker or another XML-based tool will be faster. Fluency with specialization and advanced map-level filtering takes longer.
Is there a free DITA CCMS?
The DITA Open Toolkit is free and open source, but it is a publishing engine, not a CCMS. There is no fully featured open-source DITA CCMS with hosted infrastructure. Self-hosting an open-source DITA stack is possible — DITA-OT plus Git plus CI publishing — but the engineering time it requires usually exceeds the cost of a commercial alternative for teams under 20 writers.