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, and 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 finding was clear: the structured authoring community has split into 3 camps. Only one camp (22 percent) considers XML essential. That camp consists almost entirely of aerospace, defense, and large-enterprise teams with specialized compliance requirements. The other 78 percent either actively resent XML or do not care about the format, as long as they get the capabilities they need.

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. Which camp your team falls into determines whether you need XML at all.

"XML is essential": 22 percent

The pro-XML camp exists, and their reasons are legitimate. But they represent a specific profile that most documentation teams do not share.

These practitioners work in aerospace and defense (S1000D, ATA iSpec 2200), or lead teams of 75+ writers with existing DITA infrastructure. They operate in regulated industries where XML schema validation is a compliance requirement, or 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, the pro-XML camp's use case does not apply to you.

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

This is the largest single camp by sentiment intensity, and their frustration is palpable. 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 offered this sobering assessment:

"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, and multi-channel output without XSLT pipelines. They want topic-based authoring without the DITA information model. They also want to hire writers who can start producing on day one instead of 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) and those who are format-indifferent (30 percent). Together, they represent 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. You can have the methodology without the specific implementation. The question is whether your tooling supports the methodology, not whether it uses a particular markup language under the hood.

The data: XML is declining in technical writing

The practitioner sentiment is not an outlier. Every measurable indicator points in the same direction: the technical writing profession is moving away from XML as a default requirement. Structured authoring itself grows in importance, but 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, who tracks these numbers on the DITA Writer blog, 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, 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

Perhaps 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." When the standards body behind DITA acknowledges that XML dependency is a problem worth solving, the broader trend is difficult to dispute.

Industry voices

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

Mike Howes, describing a migration from DITA to Docusaurus, explained 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. These solve the contributor access problem but introduce their own structural gaps. See the analysis of docs-as-code limitations.

The Write the Docs community positions traditional CCMS tools for "non-technical teams" only, and 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), vendor-neutral interchange in XML-native ecosystems, semantic markup for machine processing pipelines, and regulatory compliance where industries mandate specific XML standards.

Of these, regulatory compliance is the only one that cannot be addressed through alternative approaches. 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, and dismissing them would undermine the credibility of everything above.

You need XML when your industry mandates it. Aerospace and defense documentation governed by S1000D or ATA iSpec 2200 requires 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, the migration cost of moving away from DITA exceeds the ongoing cost of maintaining 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 and produce XLIFF for translator workbenches. If your localization pipeline is built around this interchange format, ripping it out may not be worth the effort.

You need XML when your content is the product. A few organizations sell structured data: parts catalogs, technical standards, regulatory databases. In these cases, the XML schema is part of the deliverable that customers consume programmatically.

If you fall into one of these categories, tools like Heretto (DITA-native, enterprise-only) or PTC Windchill are designed for your use case. A cloud-based CCMS built for teams of 2 to 15 writers is not the right fit, and 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. The migration path is: bring your DITA content, convert it, and then 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) and conrefs (mapped to reusable components with references intact). Conditional attributes map to condition dimensions, and relationship tables map to cross-references.

What Flare import preserves

Teams migrating from MadCap Flare bring over topics (XHTML converted to structured blocks), snippets (mapped to reusable components), and TOC files (mapped to 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), XSL-FO formatting instructions, and DITA-specific linking mechanisms do not have direct equivalents in non-XML systems. 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 acknowledged that exposing XML syntax to content authors is a problem. They just solve it by adding a visual layer on top of the XML, rather than removing the XML entirely.

The pattern is clear. Paligo stores your content as DocBook XML but wraps it in a visual editor so writers never touch 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. If the visual editor abstracts it away and the writer never touches it, the XML layer is pure technical debt. It adds complexity to storage, processing, and import/export without adding value 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 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 you need subject matter experts to contribute directly. It applies if you are evaluating a CCMS for the first time, or you have 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. The capabilities that once required XML (content reuse, conditional content, variables, multi-channel publishing, topic-based modularity) are now achievable without it.

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.