Structured authoring without XML - 59 writers

The short version

Nobody wants XML. They want content reuse, conditions, variables, and multi-channel output. XML is one way to get those capabilities. It is not the only way. For most documentation teams, it is increasingly not the preferred way.

I analyzed 59 practitioner voices across Reddit, LinkedIn, industry blogs, and community forums. The community has split into 3 camps. Only one camp (22 percent) considers XML essential. That camp is almost entirely aerospace, defense, and large-enterprise teams with compliance requirements. The other 78 percent resent XML or do not care about the format. They want the capabilities. The syntax underneath is somebody else's problem.

This article presents the evidence.

The 3 camps

Every discussion about XML and structured authoring eventually sorts participants into one of 3 positions. After cataloging 59 distinct practitioner voices, here is how the numbers break down. 22 percent say XML is essential. 31 percent say they hate XML but feel stuck with it. 47 percent say XML is unnecessary for their work. Your camp decides whether you need XML at all.

"XML is essential": 22 percent

The pro-XML camp exists, and their reasons are legitimate. But their profile is one most documentation teams do not share.

These practitioners work in aerospace and defense (S1000D, ATA iSpec 2200). Or they lead teams of 75+ writers with existing DITA infrastructure. They operate in regulated industries where XML schema validation is a compliance requirement. Or they have built careers as XSLT and XSL-FO specialists.

They are articulate about the value they get:

"Content reuse. Variables. Conditions. Metadata. All things that make the effort worth it." r/technicalwriting, 15 upvotes

"DITA is a true skill. It is something you get out of what you put in, and you can spend your life, not just your career, getting more out of it all the time." r/technicalwriting, DITA specialist with 10+ years of experience

Notice what even the strongest advocates emphasize: content reuse, variables, conditions, metadata. These are structured authoring capabilities. They are not unique to XML.

The pro-XML camp is buying tools at a different price tier entirely. They spend $50,000 or more for each seat a year on enterprise systems like PTC Windchill or IXIA CCMS. They employ dedicated XML Developer roles separate from their writers. If your team has 4 writers evaluating cloud-based documentation tools, none of that describes you.

"I hate XML but I am stuck with it": 31 percent

This is the largest single camp by sentiment intensity. These writers have firsthand experience with DITA or other XML-based authoring systems. They understand the capabilities. They resent the implementation.

"I fucking hate DITA myself, but it is in use all over the place." r/technicalwriting

"The CCMS is cumbersome and extremely difficult to hire for: we've had multiple contractors quit because they cannot make sense of it." hardware company team lead, actively evaluating alternatives

"I despise DITA with a flaming red passion, and I have been open with my management team about this. I have been a technical writer for more than 30 years." senior technical writer, r/technicalwriting

"Writing is no longer about crafting a coherent narrative; it is meticulously assembling context-free LEGO bricks." Fabrizio Ferri Benedetti, passo.uno

"A major learning barrier with DITA is that content structure depends on nested XML markup, where even simple sentences can be embedded with coding, and few writers want to deal with such intricacies. For DITA to work, authors sometimes need to become XML developers." Kontent.ai

The hiring problem surfaces repeatedly. One team lead described losing multiple contractors who could not get productive in their DITA environment. Another practitioner put it bluntly: "DITA is the only software where the learning curve gets steeper the more you use it."

A consultant who has worked on large-scale DITA and S1000D implementations was blunter:

"I have seen literal man-centuries flushed down the CCS hole, sometimes without a single deliverable to show for it." S1000D/DITA consultant

What this camp wants is specific. Content reuse without learning XML syntax. Conditions and variables without element nesting. Multi-channel output without XSLT pipelines. They want topic-based authoring without the DITA information model. And they want to hire writers who produce on day one, not after months of DITA training.

"XML is unnecessary": 47 percent

The largest combined group includes practitioners who have tried XML and moved on (17 percent with conditional views). It also includes the format-indifferent (30 percent). Together they are nearly half of all voices in the research.

"DITA's neat, but you do not need it for re-use. You do not even need XML. You can re-use full components, or parts of components, with Asciidoc." r/technicalwriting

"There is nothing that DITA does that cannot be done with lightweight markup, and lightweight markups even do the job better in certain areas." r/technicalwriting

"You are better learning the concepts of structured authoring. That will help you more and make you more valuable. I have looked at DITA at multiple companies over the years and have never found a compelling reason to use it." 30-year technical writing veteran

"When you treat docs as data, you would be amazed what you can do, and without expensive tech, no less." practitioner who built reuse with a database and templating system

"You do not need DITA for reuse: you need transclusion, partial transclusion, and conditionals." r/technicalwriting

This camp draws an important distinction. Structured authoring is a methodology. DITA is one implementation of it. You can have the methodology without the implementation. Ask whether your tooling supports the methodology. The markup under the hood is not the question.

The data: XML is declining in technical writing

The practitioner sentiment is not an outlier. Every measurable indicator points the same way. The profession is moving away from XML as a default requirement. Structured authoring keeps growing in importance. XML does not.

Job market shift

DITA job postings have dropped to 2.5 percent of all technical writing roles, down from a historical range of 3.5 to 4 percent. Keith Schengili-Roberts tracks these numbers on the DITA Writer blog. He described the trend as "a precipitous drop" to "low levels never seen before."

Meanwhile, Markdown has surpassed DITA in job posting frequency. Computer science programs increasingly teach Markdown over XML. The pipeline of new writers entering the profession with XML skills is narrowing. That is happening even as AI reshapes what the technical writer's job actually involves.

Satisfaction data

The 2017 DITA Satisfaction Survey conducted by Firehead remains the largest published study of DITA user satisfaction. The results were striking:

• 62 percent of DITA users reported dissatisfaction with their implementation
• 67 percent said convincing other departments of DITA's value was a "harder sell"
• Among the 38 percent who were satisfied, the top benefits cited were content reuse consistency (91 percent) and usability/predictability (87 percent)

That last point is critical. Even satisfied DITA users attribute their satisfaction to structured authoring capabilities, not to XML itself. They like reuse and consistency. The markup language is incidental.

The OASIS signal

The most telling indicator comes from the organization that governs the DITA standard itself. OASIS created Lightweight DITA (LwDITA) specifically to "free the specification from a dependency on XML." The standards body behind DITA treats the XML dependency as a problem worth solving. The trend is hard to dispute after that.

Industry voices

Tom Johnson runs idratherbewriting.com, the most widely read technical writing blog. He moved away from DITA years ago. His reason: "I felt that I should be able to use h3 tags on a page without resorting to complex element nesting."

Mike Howes described a migration from DITA to Docusaurus. He named the practical driver: "The doc team is tiny with a huge product portfolio to support. Their main priority was support for Markdown to enable collaborative authoring with people outside the doc team, as DITA is far too cumbersome for occasional contributors." These teams typically land on docs-as-code workflows. That solves the contributor access problem. It also introduces structural gaps of its own. See the analysis of docs-as-code limitations.

The Write the Docs community positions traditional CCMS tools for "non-technical teams" only. It rarely discusses XML as a requirement for modern documentation.

What you actually need for structured authoring

The research reveals a consistent pattern: when practitioners describe what they want from a documentation system, they name capabilities, not formats. Here is what those capabilities are and whether they require XML.

Only 4 capabilities genuinely require XML. These are schema validation (enforcing structural rules at the markup level) and vendor-neutral interchange in XML-native ecosystems. They also include semantic markup for machine processing pipelines and regulatory compliance where industries mandate specific XML standards.

Of these, only regulatory compliance resists an alternative approach. Schema validation can be implemented as editor-level rules. Interchange can happen through import and export. Semantic markup can be applied at the content model layer regardless of storage format.

Topicary implements all 5 core capabilities using a TipTap/ProseMirror JSON content model. Content reuse works through component references with where-used tracking. Conditional content uses dimension-based filtering with in-editor preview. Variables are key-value sets resolved at publish time. The result is structured authoring without the XML overhead.

When you genuinely need XML

Intellectual honesty requires acknowledging the cases where XML is the right choice. They exist. Dismissing them would undermine everything above.

You need XML when your industry mandates it. Aerospace and defense documentation follows S1000D or ATA iSpec 2200. Those standards require XML schema validation as a compliance deliverable. Medical device documentation under certain regulatory frameworks has similar requirements. In these industries, the XML is not overhead. It is the output.

You need XML when you have 75+ writers with existing DITA infrastructure. At that scale, moving away from DITA costs more than keeping it. Your writers are trained, your toolchain is configured, your publishing pipeline works. Switching introduces risk with limited upside.

You need XML when your translation workflow requires XLIFF interchange with XML-native TMS systems. Certain translation management systems expect DITA or DocBook as input. They produce XLIFF for translator workbenches. If your localization pipeline is built around that interchange, ripping it out may not pay.

You need XML when your content is the product. A few organizations sell structured data: parts catalogs, technical standards, regulatory databases. Here the XML schema is part of the deliverable. Customers consume it programmatically.

Tools like Heretto (DITA-native, enterprise-only) or PTC Windchill are designed for those cases. A cloud-based CCMS built for teams of 2 to 15 writers is the wrong fit. There is no shame in that.

For everyone else (and that is most documentation teams), XML is a cost with no corresponding benefit.

The migration question

The most common objection from teams considering a move away from XML is: "We have years of DITA content. We cannot just throw it away."

You do not have to. Bring your DITA content, convert it, and never write XML again.

What DITA import preserves

A proper DITA import pipeline handles concepts, tasks, and references (mapped to topics with appropriate structure). It preserves ditamaps, mapped to content maps with hierarchy preserved. Conrefs become reusable components with references intact. Conditional attributes map to condition dimensions. Relationship tables map to cross-references.

What Flare import preserves

Teams migrating from MadCap Flare bring over topics, converted from XHTML to structured blocks. Snippets become reusable components, and TOC files become content maps. Variables map to variable sets, and condition tags map to condition dimensions.

What does not transfer, and why that is acceptable

DITA specializations (custom topic types with extended schemas) have no direct equivalent in non-XML systems. Neither do XSL-FO formatting instructions or DITA-specific linking mechanisms. In practice, most teams use a fraction of DITA's specification. The capabilities they actually rely on (reuse, conditions, variables, topic-based modularity) transfer cleanly.

What every competitor does with XML

One of the most revealing findings from this research: even XML-based CCMS tools hide XML from their writers. The industry has already admitted that exposing XML syntax to content authors is a problem. Its solution is a visual layer on top of the XML. The XML stays.

The pattern is clear. Paligo stores your content as DocBook XML. A visual editor keeps writers away from the angle brackets. Flare uses XHTML under the hood but provides a Word-like interface. Even Heretto, which leans into DITA visibility for enterprise buyers, offers a visual editor mode.

The question is not whether writers should see XML. The industry already answered that with "no." The question is whether the XML needs to be there at all. The visual editor abstracts it away. The writer never touches it. At that point the XML layer is pure technical debt. It adds complexity to storage, processing, and import/export. It adds nothing to the authoring experience.

Fabrizio Ferri Benedetti captured the market gap in a passo.uno blog post. DITA is a "300 kg solution" when developers want "300 gr notepads." But Markdown "painfully shows its limitations when it comes to content reuse, internal references, or even tables." The market needs something between these 2 extremes: structured authoring capabilities with a lightweight authoring experience.

Making the decision for your team

After reviewing 59 practitioner voices, the decision framework is straightforward.

Choose XML-based tooling if your industry mandates XML schema validation for compliance or you have 75+ writers with existing DITA infrastructure. It also applies if your content is a deliverable that customers consume as structured XML. Or if your translation pipeline requires XLIFF interchange with XML-native systems.

Choose structured authoring without XML if your team has 2 to 15 writers who need content reuse, conditions, and variables. This path also fits if you want new writers productive in days rather than months. Or if you need subject matter experts to contribute directly. It fits first-time CCMS evaluations. It fits teams who tried DITA and found the overhead outweighs the benefits.

The phrase "structured authoring without XML" appeared in an STC academic paper as early as 2016. A decade later, the tools have caught up to the aspiration. Content reuse, conditional content, variables, multi-channel publishing, and topic-based modularity once required XML. They do not require it now.

The 59 practitioners in this research are not saying XML is bad. They are saying it is unnecessary for most teams. And the data (declining job postings, majority dissatisfaction, OASIS itself decoupling from XML) agrees with them. For how these findings shaped the product, read why I built Topicary. For the content model that replaces XML, see what a CCMS is.