DITA — the Darwin Information Type Architecture — was the architecture that was going to settle how technical documentation worked. It is still here, it still has paying customers, and it has not had a new version since 2015. What happened to it is more interesting than either dying or winning.
October 2026
DITA 1.3 has more power (and thus complexity) than is needed in some authoring situations.
OASIS DITA Technical Committee, Lightweight DITA: An Introduction, 2018
In plain words first. DITA is a way of writing documentation in which you do not write documents. You write topics — a single task, a single concept, a single reference item — and then a separate file called a map says which topics make up which publication and in what order. The topics themselves contain no navigation and no idea of where they sit. That is the point: the same topic can appear in the installation guide, the online help and the service manual without being copied, and an element inside it can be pulled into another topic by reference.
It came out of IBM in March 2001, from Don Day, Michael Priestley and Dave Schell, built by the user-assistance teams of IBM, Lotus and Tivoli. OASIS made it a standard in June 2005. If you were anywhere near documentation in those years it felt inevitable, and for a certain kind of company it was.
The word nobody explains
It stands for Darwin Information Typing Architecture, and the Darwin is the part worth stopping on. It refers to specialization: you take an existing element type and define a narrower one from it, and the new type carries its whole ancestry in a class attribute, so a transformation written for the general case still knows what to do with the specialized case. The specification’s own analogy is not biological at all — it compares it to a class inheriting methods from an ancestor class.
The famous four types are themselves the demonstration. There is one base, topic. Concept, task and reference are specializations of it, and they do not even live in the same part of the standard — the Base Edition is topic, map and subject scheme map, and the familiar three sit in the Technical Content Edition. The architecture’s best-known feature is an example of its own mechanism.
Here is the thing I did not expect. No specification explains the name. I read the original IBM paper and the overviews of versions 1.1, 1.2 and 1.3: the word Darwin appears in the title and nowhere else. No evolution, no descent, no Charles. The only first-hand account is Don Day in an interview in 2016 — “Darwin: for specialization and how things could ‘evolve’ from a base” — where he also says who coined it: Gretchen Hargis, co-author of Developing Quality Technical Information, who has since died. A standard that names itself after its central idea and then never writes the idea down is already telling you something about how standards are made.
What happened: nothing, for eleven years
DITA 1.3 was approved in December 2015. There have been two errata since, in 2016 and 2018. Version 2.0 has been in the works for years and is still in beta: beta 01 in June 2025, beta 02 that October, beta 03 in July 2026. As I write this, the current standard is eleven years old and its successor has never reached even a committee specification.
And yet the tools are not abandoned, which is the part that makes this interesting rather than sad. The DITA Open Toolkit released 4.4.1 in August 2026. oXygen XML shipped version 28.1 in March 2026. Both support DITA 2.0 features — against the draft grammar files, because there is nothing else to build against. The ecosystem is healthy and the standard underneath it is frozen.
The users are real and they are findable. The DITA Europe conference in Brussels in February 2026 had presentations from Cisco, Oracle, Amazon, Adobe, ServiceNow, Alstom, Grundfos, Synopsys, the KION Group, the Mayo Clinic. Notice what that list is: enterprise software, networking, semiconductors, rail, industrial equipment, medicine. Regulated, translated, long-lived, hardware-adjacent. It is not a list of websites.
The committee wrote the criticism itself
In April 2018 the OASIS DITA committee published a Committee Note introducing Lightweight DITA, and it reads like the case against its own standard. DITA 1.3 is mature with a deep set of advanced features, it says, and that maturity “can be intimidating for those considering adoption, especially for simple scenarios”. It notes that conference talks and practitioners’ blogs “occasionally describe DITA as an intimidating grammar with too many document and element types”. Then it gives the number: the base edition of DITA 1.3 has 189 element types; Lightweight DITA has 48.
The same document concedes the rivals by name, acknowledging that some authoring communities have strong ties to Markdown or HTML, and that although those formats are less expressive they bring tools and practices with them. Lightweight DITA was the answer: a smaller grammar with mappings to HTML5 and Markdown. Eight years later it is still a Committee Note. It never became a standard either.
And the feature it is named after is now advised against
Sarah O’Keefe of Scriptorium published a piece in August 2024 defending the business value of specialization, and the defence contains the concession: managing an environment with specialized tags is “clearly more expensive” than using the default set, because it means changes to the authoring interface, the publishing pipeline, the training and the connected systems. Her practical advice is to use the lighter mechanism instead — setting up constraints is much easier than creating specializations. Norman Walsh, who designed the competing standard, had written in 2010 that he was historically not impressed by specialization and that the overhead concerned him. And oXygen’s own blog, from the people who implement it, lists too many constraints on creating specializations among the standard’s problems.
I want to be careful here, because the easy sentence is not available. It is widely said that almost nobody actually writes specializations, and I looked for a number and did not find one. Nobody has measured it. What can be said is narrower and still remarkable: the architecture is named after a mechanism that its own advocates now recommend you avoid, that its toolmakers find awkward to support, and that the designer of the rival standard thought was not worth the overhead.
Did Markdown win, then?
This is where I had to correct myself, because the story I wanted to tell is not quite the one the evidence supports.
The best numbers come from Keith Schengili-Roberts, who spent a decade counting what technical-writing job adverts actually ask for — and who is a DITA advocate, which is what makes the count worth something. In 2022 he reported DITA appearing in 2.5 per cent of all technical-writer postings, down from a typical 3.5 to 4 per cent, with mentions of Markdown having overtaken mentions of DITA. He has not updated the series since. Separately, Tom Johnson’s 2020 survey of developer-documentation writers found 37 per cent working in Markdown against 15 per cent in XML, and 56 per cent saying yes to docs-as-code — though that was a self-selected audience of API writers, which is a segment and not the profession.
Look at the first figure again. Four per cent was DITA’s peak. It was never the default; it was the serious option for a particular kind of documentation. So “Markdown displaced DITA” mostly mis-describes what happened. Markdown took the enormous new market of software documentation, which DITA had never held, and DITA kept the enterprise it already had. I found no survey showing organisations leaving DITA at scale — only individual cases, documented and worth reading. Veracode moved to Docusaurus, and the reason given was not the output: they had let subject-matter experts into the DITA source and “having them work in XML with special tools wasn’t working out”, and, more damningly, “one of the main strengths of structured authoring is reuse, but we weren’t really using it effectively to justify authoring in XML”. They had been paying the cost without collecting the benefit. Against that, three writers at Cisco published an account of running both and concluded that Markdown is best for products with a small documentation footprint, and that reuse and single sourcing become impossible to overlook as content grows.
Tom Johnson put the real mechanism in one sentence in 2022: given how hard it is to migrate to DITA, migrating away from it is probably hard too, so it is likely to remain the status quo for those who already adopted it. That is not a standard winning. It is a standard being expensive to leave.
What follows is how I would decide it now, for a client rather than for a committee.
When the structure is worth its cost
- Count the outputs before anything else. One publication from one source needs no architecture. Six manuals for six models of a machine, in nine languages, is the case structured authoring was built for and nothing else does it as cheaply.
- Ask who writes. If the people with the knowledge are engineers who will not open an XML editor, the expensive system will route around itself and you will get stale documentation in a beautiful pipeline.
- Do not pay for reuse you will not use. That is the Veracode lesson, in their own words. Reuse is the whole argument for the cost; if nobody is reusing, the cost has no argument.
- Take the smallest grammar that does the job. 189 element types against 48 is not a detail. A structure nobody can hold in their head gets used wrongly, which is worse than no structure.
- Price the exit as well as the entry. Ask how the content comes back out before you put any in. A format that is costly to leave will keep being chosen for that reason alone, which is not a reason.
- Keep the semantics even when you keep it simple. The valuable half of all this is marking what something is rather than what it looks like. You can have that in HTML, in Markdown with a convention, in a folder of named files. You do not need an architecture to have it — you need the discipline the architecture was trying to enforce.
A parallel I have not seen anybody draw
What follows is my argument rather than a reported one. I went looking for somebody who had written it and found nobody: the technical-communication literature discusses DITA as a tooling decision and almost never as an episode in the history of standards. So take it as mine.
This shape is familiar. SGML was the rigorous, complete, correct way to describe a document, and what actually covered the earth was HTML, which was a simplification of it that browsers forgave. XHTML 2 was going to clean up the mess and was abandoned for HTML5, which specified what people were already doing. And the Semantic Web proposed that meaning be declared properly in a shared vocabulary, and what arrived instead was a handful of agreed tags that unlock a search result. DITA is the same story told inside one profession: the full architecture went to the people who had a real need and a budget, and a cruder format took everybody else, and the crude format is now slowly rediscovering why the architecture had those features. The clearest version of that last part comes from a docs-as-code advocate, Fabrizio Ferri Benedetti, writing that Markdown “painfully shows its limitations when it comes to things like content reuse, internal references, or even tables” and calling for new standards — which is where the previous standard came in.
There is a last turn, and it is almost funny. The DITA Europe programme in 2026 was dominated by artificial intelligence: retrieval pipelines, knowledge graphs, one session titled “Why DITA in 2026: The AI Age of Documentation”. The argument is that structured content is a precondition for a model you can trust. Which is, word for word, the Semantic Web’s argument arriving a second time, from a different direction, for a different machine. Maybe it lands this time. It would be the first time being right early turned out to be enough.
Read the originals
- Lightweight DITA: An Introduction — OASIS DITA Technical Committee, 2018. Read this one first. It is the committee writing down what is wrong with its own standard, with the element counts attached.
- Don Day, Michael Priestley and David Schell, Introduction to the Darwin Information Typing Architecture — IBM, March 2001. The founding document, and the place where the name goes unexplained.
- Keith Schengili-Roberts, Has DITA Plateaued? — November 2022. Ten years of job adverts counted by somebody who wanted the answer to be different. The only hard numbers in the whole debate.
- Tom Johnson, DITA and Docs as Code — 2022. The two halves of the argument by one person who uses both, which is rarer than it should be.
- From DITA to docs-as-code and Docusaurus — Mike Howes of Veracode, interviewed 2023. A documented migration away, with the honest reason.
- A Publishing Adventure: From Markdown to DITA and back — three practitioners at Cisco, 2021. The other side, from people running both systems at once.
- Sarah O’Keefe, The business value of DITA specialization — 2024. A defence of specialization that ends by advising you to use something lighter.
- Fabrizio Ferri Benedetti, Better docs, less pain: the case for new docs-as-code standards — 2021. The winner noticing what it gave up.
- The OASIS DITA Technical Committee and its 2.0 beta releases — the approval dates, and the eleven-year gap, from the source.