I too would like to know the answer to this question. We face the same dilemma.

Thanks,
josh

I think that there are a lot of variables here. When you (Frank Ralf  ) say "switch to DITA" do you mean just updating the configuration to accept import of new DITA content? Or do you mean converting the existing content in the repository from an older DTD structure to DITA? If the latter, then you would need to export the content (a process which could be automated with web APIs), convert/transform the content, and reimport. Happy to discuss offline the details around this process if you are interested. Also, what  version is the Tridion Docs instance? Is it still supported?

There are many ways to do this depending on the complexity of your existing DTD based XML. The traditional way to do this would be to use XSLT to convert the DTD based XML to DITA. Now that does require you to do a detailed analysis of the existing DTD structure/ data model and map it to appropriate DITA elements and attributes.

But if you have an HTML output for your DTD-based XML, you can use Oxygen's batch convertor to convert that HTML to DITA. I have used it in one of my projects and it does a pretty decent job. So this would be a 2 step process:

1. Generate HTML output of your DTD based XML.
2. Convert the HTML output from step 1 to DITA using OxygenXML's batch conversion tool.

Again, this would be a better route if you already have HTML as one of the outputs for your DTD based XML.

More information on Oxygen's batch conversion tool (available as an add-on and as a script) is here:

• https://www.oxygenxml.com/doc/ug-addons/topics/batch-converter-addon.html
• https://www.oxygenxml.com/doc/versions/27.0/ug-editor/topics/scripting_oxygen_batch_converter.html

Hope this helps!

Hi Frank, Mark Novembrino gave a good overview of factors in converting the content itself.

Assuming that’s what you had in mind — a wholesale switch of all the existing content — then here’s one way to think about it.

In switching to DITA, you’re not only changing the syntax of the content, you’re also enabling various features in Docs which are designed to work with DITA. Such as library features around conrefs, and the ability to use Draft Space — lots of good stuff.

With that in mind, you could almost look at it as a migration to a newer version (and in practice it is likely this would go with a CMS upgrade anyway). So you’re not switching in place, but rather trying out the remapped content in an all-new Docs version in a dev environment. And also probably taking the opportunity to simplify configurations, maybe even prune some legacy content.

In fact there are customers who were using DITA all along who still chose to do a bit of a fresh start in a new Docs instance after say ten good years and building up quite a lot of legacy outputs, LOV values, redundant statuses, and so on!

So maybe it’s a chance for this kind of spring-clean too?