Colleagues who refuse to work in XML
A 2020 piece on SME adoption in DITA programs. A survey of 80 companies: DITA XML complexity is the most-cited reason departments are dropped from a rollout.
Originally written by Søren Weimann, April 2020, when he was a co-founder of DitaExchange. Refreshed for republication in 2026 under DitaExchange editorial.
“Looks cool, but couldn’t we just stick to what we have?”
“Being able to grab a piece of content like that would be nice, but I don’t have the time to learn this new tool.”
“Yes, I’d like to be able to publish a white paper using parts of your updated documentation, but all these tags and attributes? I don’t know…”
We have all heard these complaints.
Fifteen years of the same brick wall
Since DITA XML became an open standard and DITA 1.0 was released in 2005, people have been trying to spread the use of modular and structured content beyond the traditional documentation department. Some have been successful. Many have hit a brick wall when they present XML templates and XML tools to marketing and development teams.
I have presented the opportunity of sharing content, reusing topics, conrefing legal notes and filtering output for different audiences many times. People see the benefits. But they often take a step back when they see the tools, the interfaces and the appearance of overwhelming complexity. Some rule it out entirely. Others have a hard time finding the bandwidth to prioritize the change process.
Is this the case across the DITA world generally?
Before assuming my experience generalizes, I ran a survey of 80 companies. Three implementation patterns showed up. There are those that aim for one department only. There are those that try to include several departments but eventually drop one or more from the rollout. And there are those that implement DITA XML company-wide. The survey included roughly a third of each group, with a slight overrepresentation of the middle category.
The 2020 survey’s central finding: the broader the DITA rollout, the more decisive XML-editor complexity becomes as the limiting factor. The pattern that justified the Word-based authoring path the platform has followed since.
I wanted to know what was challenging.
Single-department rollouts. Complexity of DITA XML is less of a challenge here, which is not surprising, ownership alone motivates most people to take on the learning curve. But I wanted to know why those teams limited the joys of DITA to their own part of the organization. 42% of them indicated that complexity was part of the reason. Specifically: other departments wanted to stay in familiar tools, the change process would be too much, or plainly that DITA XML was too complex for the audience.
Multi-department rollouts that dropped departments. 70% of these indicated DITA-XML complexity as part of the reason why some departments under consideration were not included in the final implementation.
Company-wide rollouts. 89% saw complexity of DITA XML as one of the most significant challenges in the implementation.
The pattern is striking and consistent: the broader the rollout, the more decisive complexity becomes as the limiting factor. This is not a coincidence, broader rollouts expose more non-specialist authors to the tooling, and those non-specialist authors are the population that struggles with the XML editor.
What to do about it
DITA XML is complex. That is why DITA XML can do so much. It allows the management of very complex documentation sets and minimizes risk and inconsistency in an ever-changing world of product development. But if the threshold for more people to benefit is so high that people do not bother trying, or give up before getting there, we may need to provide a stepping stone.
What if we aim for reducing complexity, and focus on a few of the most important benefits of DITA?
I am thinking:
- Modular content that allows reuse of topics across deliverables
- Topic types for task-based writing
- Ditaval filtering
- Semantic tagging and conrefs
- Publishing with DITA Open Toolkit
Familiar tools, with the DITA structure behind them
To reduce the change process and the learning curve, we allow content creators to work in familiar tools that have been adapted to achieve some of the key benefits of DITA.
On top of this, content created in those familiar tools should be publishable in deliverables alongside DITA XML topics. And conversion between formats should be easy. People who refuse to work in XML can contribute directly to modular and structured content. Some of them may use the chance to become familiar with conrefs, tagging and topics in a familiar tool, and possibly use it as a stepping stone before leaping into DITA XML to get the full benefit.
A note from 2026. The argument has aged exactly as well as the survey suggested it would. The SME refusal to adopt unfamiliar XML editors is now treated as a steady-state observation across the industry, not a transitional one. The companion view from 2026 is in Why technical writers stop using XML editors, which walks the eighteen-month disengagement pattern that follows when a team tries to push an XML editor on a non-specialist population. The product expression of the alternative, DITA authoring inside Microsoft Word, is now Authoring in Word in the Dx5 platform.
Frequently asked questions
Why is DITA XML complexity the limiting factor for broader rollouts?
Because the breadth of a CCMS rollout determines how many non-specialist authors are exposed to the structured-content tooling. A documentation-team-only rollout exposes a small population of specialists who can absorb the learning curve. A company-wide rollout exposes hundreds of subject-matter experts who have a primary job that is not authoring documentation and who will not adopt an unfamiliar tool to do a task that takes them a fraction of their time. The survey numbers (42% → 70% → 89% citing complexity as a challenge) track this directly.
What is the proposed alternative?
A two-track authoring model. The technical-writing team and structured-content specialists continue to use a dedicated XML editor for the work that genuinely needs it: schema-level changes, complex content references, deep DITA modeling. The subject-matter experts author in Microsoft Word with a CCMS add-in that maps Word structure to DITA at save time. Both populations contribute into the same content base. Neither is asked to adopt the other's tooling.
Has the picture changed since 2020?
Not meaningfully, if anything it has hardened. The SME refusal to adopt unfamiliar XML editors is a steady-state observation, not a transitional one. The CCMS field still divides into vendors that treat Word as a first-class authoring surface (DitaExchange and Quark Publishing Platform) and vendors that treat it as an import path. The 2026 view on this exact pattern is in the companion post 'Why technical writers stop using XML editors'.
