Briefing
Two Standards, One Year
The Coincidence
Both, in the Same Twelve Months
S1000D Issue 7 is out and listed as the current issue. By the specification's own numbering rules a first-digit change is a major revision, which it states plainly “is not backward compatible and transformation of information will require some degree of human intervention.”
DITA 2.0 reached Beta 03 in July 2026 and is still pre-release. It is also not backward compatible, and for a more deliberate reason: the technical committee spent the release removing markup rather than adding it.
These two specifications have nothing to do with each other. Different governing bodies, different industries, different decision processes, no coordination. And they reached the same conclusion in the same year, which is either a coincidence worth ignoring or a signal worth reading. It is the second one.
Why Now
Specifications Grow by Saying Yes
A maintained specification has a structural bias, and it is toward growth. Someone needs a capability the current version cannot express, a change proposal is raised, and the committee agrees. A new element, a new attribute, a new permitted structure. Every one of those decisions is defensible on its own terms, and the ones that get rejected are usually rejected for being unclear rather than for being additions.
Twenty years of that produces a specification larger than any individual can hold in their head. The symptoms are consistent across both of these standards and anyone who has worked in either will recognize them: tools implement different subsets, so a file that is conformant in one system is unusable in another. Two teams solve the same problem with entirely different markup, both correctly. New authors face a learning curve made of history rather than concepts. And the flexibility that was the selling point becomes the reason nothing interoperates.
At that point there is exactly one remedy, and it is subtraction. Take away the redundant paths, collapse the near-duplicates, retire the markup that solved a problem nobody has any more. It is the right call and it has one unavoidable cost: subtraction breaks existing content. Both committees reached that point, looked at the same trade, and made the same decision within about a year of each other. That is not coordination. It is two mature specifications aging at the same rate.
The Difference
Same Shape, Different Project
Here is where organizations running both get into trouble, usually by being sensible. Two major migrations, similar shape, so they get scoped together, staffed together, and planned as one program. They are not one program. They differ on every axis that decides cost and timing:
- S1000D Issue 7
- Your customer, through the contract and the business rules layer.
- DITA 2.0
- You do. Nobody will ever require it.
- S1000D Issue 7
- When a contract cites the issue, or a service rules revision moves. Often years away.
- DITA 2.0
- Whenever you choose, which usually means when a tool upgrade forces the question.
- S1000D Issue 7
- An acquisition authority. The date is set for you and is not negotiable.
- DITA 2.0
- A vendor dropping 1.x support, or content that can no longer be processed.
- S1000D Issue 7
- Business rules, the BREX, and everything a program decided that the specification left open.
- DITA 2.0
- Markup doing jobs the specification never intended, which only your authors can explain.
- S1000D Issue 7
- Low. Programs run old issues for a decade quite happily.
- DITA 2.0
- Compounding. Every topic authored today in removed markup is another topic to fix.
The last row is the one to sit with. An S1000D program can defer Issue 7 almost indefinitely and suffer nothing, because the issue a program works to is a contract fact and plenty of live programs are still running Issue 4.2 quite happily. A DITA library that defers is not standing still: every topic authored this year in markup that 2.0 removes is another topic on the eventual bill. The migration that nobody is forcing is the one that quietly gets more expensive.
If you run both architectures, the useful framing is the one our comparison of the two already sets out: one is contracted and one is chosen, and that difference governs almost everything downstream, including this.
What It Means
The Free Half of Both Projects
The practical response to both revisions is the same, costs nothing, and almost nobody is doing it: stop authoring the markup that is going away. Both specifications published their removals before the migration became urgent. Both can be avoided inside the current version. A team that adjusts its authoring rules this quarter is performing half of a migration for free, in advance, without a project code.
The rest is the part that always costs money, and it is the same in both cases: finding out what your own markup is actually doing. A transform handles the mechanical removals in an afternoon. What takes the time is the content where somebody used an element for a purpose the specification never had in mind, which is every library over five years old, and which no script can resolve because the information needed to resolve it exists only in the heads of the people who wrote it. That is the argument for sampling before committing rather than estimating from file counts, and it applies to both of these migrations for exactly the same reason.
FAQ
Questions Worth Answering Now
Are S1000D Issue 7 and DITA 2.0 related?
Not organizationally, and that is what makes the timing interesting. They are governed by different bodies, serve different industries, and made their decisions independently. S1000D is maintained by ASD, AIA and A4A for aerospace and defense; DITA is an OASIS standard used across software, manufacturing, and industrial documentation. Neither was waiting on the other. They arrived at the same conclusion in the same year for the same underlying reason, which is the genuinely interesting part.
Why did both break compatibility at the same time?
Because both are old enough to have accumulated twenty years of additions, and both hit the point where the accumulation had become the problem. Specifications grow by saying yes. Every new capability is a new element, a new attribute, or a new permitted structure, and each one is individually reasonable. Eventually the specification is larger than anyone can hold, tools implement inconsistent subsets, and two conformant files look nothing alike. The only fix is subtraction, and subtraction breaks compatibility. Both bodies reached that point within about a year of each other.
If we run both, is this one project or two?
Two, and treating them as one is a common and expensive mistake. They share a shape, an inventory, a transform, and a review pass, but almost nothing else. The S1000D move is driven by a customer on a contract timeline, and its hard part is the business rules layer. The DITA move is self-directed with no deadline, and its hard part is archaeology into what your own markup means. Different owners, different triggers, different skills. What they can share is the discipline: sample first, count what needs a human, and stop authoring the markup that is going away.
What should we do in the next quarter?
Very little that costs money, and one thing that costs nothing. Neither migration is urgent for most organizations right now: Issue 7 will not reach your program until a contract or a rules revision brings it, and DITA 2.0 is not yet an approved OASIS standard. But both have a free action available today, which is to stop authoring the markup each one removes. That is possible in Issue 6 and in DITA 1.3, it requires no tooling change, and it means the eventual migration covers your back catalog rather than your back catalog plus everything you wrote while waiting.
Get In Touch
Running Both?
We work in S1000D and DITA, and we will tell you plainly which of these two migrations deserves your budget first, including when the answer is neither.