Briefing
DITA 2.0 Is Coming, and It Will Break Your Content
Where It Stands
Close Enough to Plan Against
The OASIS technical committee published DITA 2.0 Beta 03 on 2 July 2026, after Beta 02 in October 2025 and Beta 01 in June 2025. All three are marked pre-release, and the specification has not been approved as an OASIS Standard. So nothing here is final. What makes it worth reading now is that the grammar files are stable enough for the tooling to ship preview support against them, which means the shape of the release is already knowable.
And the shape is unusual. DITA 2.0 is not backward compatible. That sentence does a lot of work, because it inverts the habit of everyone who has run a DITA library. Every previous version added things. This one spent its effort removing markup that accumulated across 1.x, on the reasoning that an architecture nobody can hold in their head is not actually flexible. Content moved forward without being updated will not validate.
The window that creates is narrow and genuinely useful. Between now and approval, a team can inventory its own content against a known list of removals, at its own pace, with nobody applying pressure. After approval, the same work happens under a tool upgrade deadline with a vendor waiting. Those are very different projects with identical scope.
The List
What Is Actually Removed
Published change lists are organized by module, which is correct and unhelpful. What decides the cost of a migration is not where a removal sits in the specification, it is whether a machine can fix it. Grouped that way:
Attributes that become elements
Mechanical, but everywhere- @navtitle on <topicref> is gone. Use the <navtitle> element.
- @alt on <image> is gone. Use the <alt> element.
- @copy-to is gone. The <resourceid> element specifies the copy target.
These are the ones that touch the most files. A map that sets @navtitle on every topicref touches every topicref.
Elements replaced by a generic
Mechanical- <substeps> and <substep> are gone. Nest <steps> directly instead.
- <itemgroup> and <sectiondiv> are gone. Use <div>.
- <topicset> and <topicsetref> are gone. Use <topicref>.
- <index-sort-as> is gone. Use <sort-as>.
- <linktext> in maps is gone. Use the new <linktitle>.
Cheap to transform and easy to miss, because none of it fails loudly until validation.
Elements that need a judgment call
Editorial- <titlealts> is gone. Alternate titles now live in the topic <prolog>.
- <state> is gone. It becomes <data> if it carried metadata, or <keyword> if it was content.
- <unknown> is gone. Use <required-cleanup>.
A script cannot decide these. Someone has to know what the markup was being used for, which is why an inventory beats an estimate.
Renamed and narrowed
Low volume, high blast radius- @domains is replaced by @specializations.
- @chunk now accepts only “split” and “combine”. Every other value is invalid.
- Hazard statements are redesigned to align with ANSI Z535.6, with support for multiple hazard symbols.
Few instances, but they sit in specializations, shells, and safety content, which is where mistakes are expensive.
There is more, and most of it is housekeeping: a long tail of elements retired across the 1.x era, the glossary module trimmed, and various attributes dropped from <object>. DITA 2.0 also adds, quietly and usefully: <include>, real <audio> and <video> elements, <strong> and <em>, and <simpletable> gains titles and spanning. The additions are not the story. The removals are.
The Real Cost
Where the Money Goes
Read the removal list again and notice which line items a script can close. Attributes becoming elements: a script. Generic replacements: a script. @domains to @specializations: a script. If that were the whole job, DITA 2.0 would be a weekend.
It is not the whole job, for the same reason every conversion project costs more than its transform. Three of the removals need a person who knows what the markup meant. <state> becomes <data> or <keyword> depending on whether it was carrying metadata or content, and only the people who wrote it know which. Alternate titles moving into the prolog is a structural edit with editorial consequences for navigation. And the hazard statement redesign is not a rename at all: it is an alignment to ANSI Z535.6, which has its own rules about signal words and message types, and touches the one part of a manual where being wrong has a consequence worse than a failed build.
So the estimate that matters is not how many files you have. It is how much of your markup is doing something the specification did not intend, which is exactly the question our conversion costing piece answers for S1000D and answers the same way here: sample first. Take your worst hundred topics, run them through the transform, and count what needs a human. That number, multiplied out, is your project. Every other estimate is a guess wearing a spreadsheet.
What to Do Now
The Free Migration
Here is the part worth acting on today, because it costs nothing and shrinks the project later. Stop authoring the markup that 2.0 removes. All of it is avoidable in DITA 1.3 right now. Use the <navtitle> and <alt> elements instead of the attributes. Nest <steps> instead of reaching for <substeps>. Use <div> rather than <itemgroup> or <sectiondiv>. Keep @chunk to split and combine. Then put those rules in the place rules actually live, which is not a style guide nobody opens but the validation layer, where a Schematron rule can fail the build the moment someone types the old markup.
Everything written from this week forward is then already 2.0 content, and the migration shrinks to the back catalog. Teams that do this quietly for a year discover the project was mostly done before it was scheduled. Teams that wait discover the opposite, and they discover it in the same quarter their tool vendor drops 1.3 support. The direction of travel is the one this site keeps naming: content that outlives its tooling is content whose structure was maintained deliberately rather than inherited by accident.
FAQ
Questions Worth Answering Now
Is DITA 2.0 released yet?
Not as an OASIS Standard. The technical committee published DITA 2.0 Beta 03 on 2 July 2026, following Beta 02 in October 2025 and Beta 01 in June 2025, and those releases are explicitly marked pre-release. The grammar files are stable enough that the DITA Open Toolkit ships preview support for them, so the shape of the specification is knowable now even though the final vote has not happened. That gap is the useful window: you can plan against it before your vendors start selling against it.
Is DITA 2.0 backward compatible with DITA 1.3?
No. This is the single most important fact about the release and the one that surprises people, because DITA has been additive for its whole life. The 2.0 effort deliberately went the other way and removed accumulated markup rather than adding more. Content moved forward without being updated will not validate. The practical consequence is that adopting 2.0 is a migration project with a transform, a test pass, and an editorial review, not a version number you change in a DOCTYPE.
What actually breaks first?
Maps, usually. The removals with the widest reach are attributes that became elements: @navtitle on topicref, @alt on image, and @copy-to. A large map set can carry thousands of instances of those, and they are the kind of markup that gets written once in a template and repeated forever. After maps, the next surprises are typically @chunk values that are no longer legal and any specialization that declares @domains, which is now @specializations.
Should we wait for DITA 2.0 before starting a DITA project?
No, and that instinct costs more than it saves. Tools will support 1.3 for years, the specification is not finally approved, and a project that waits produces nothing in the meantime. The useful move is to author in 1.3 while avoiding the markup that 2.0 removes, which is entirely possible today and costs nothing: use the elements rather than the attributes, avoid substeps, avoid itemgroup and sectiondiv, and keep chunk to split and combine. That is a free migration you are performing in advance.
How is this different from the S1000D Issue 7 situation?
The timing rhymes and the economics do not. Both specifications are making a major, non-backward-compatible revision in the same year. But S1000D issues reach a program through its contract and its business rules layer, so the move is someone else's decision and usually years away. DITA is adopted rather than contracted, so the decision is yours, the timeline is yours, and nobody will force it. That sounds easier and is actually harder, because projects that can defer a migration indefinitely usually do, right up until a tool upgrade makes it urgent.
Get In Touch
Holding a DITA Library?
We can sample it against the 2.0 removal list and tell you what a migration actually costs, in files and in judgment calls, before anyone is waiting on the answer.