Preserve the source
Native XML should remain the system of record, not an intermediate format.
Standards-first
What DITA support should actually mean.
Support for DITA should not mean just importing XML, running a transform, or surviving a demo. For teams living with structured content every day, DITA support has to be precise, testable, and operationally useful.
Many systems are DITA-adjacent. They may store XML or publish familiar outputs, but still hide semantics, constrain export, or leave specialization behavior scattered across custom code and tribal knowledge.
That is not enough for serious DITA teams. If a platform claims DITA support, it should preserve native XML, understand references and reuse, respect specialization, expose diagnostics, and make conformance claims that can be tested.
ForgeDITA takes the conservative path: claim only what can be proven, keep content portable, and make the semantic model explicit instead of burying it inside editor plugins or publishing scripts.
Practical take
What this means in real DITA operations.
Understand the graph
Keys, conrefs, xrefs, maps, subject schemes, and impact analysis belong at the CCMS core.
Respect specialization
A DITA platform that only understands base element names is not ready for serious specialized content.
Publish the claim
A public conformance statement beats vague compliance language every time.
Early access
Building the cleaner path.
ForgeDITA is moving toward MVP for teams that want native XML, Oxygen-first workflows, reproducible publishing, and fewer systems that punish the people who understand them best.
Talk to ForgeDITA