Publishing DITA without the DITA Open Toolkit: A Trend or a Temporary Detour?
I estimate that about 80 percent of our consulting work is XML implementation. And about 80 percent of our XML implementation work is based on DITA. So we spend a lot of time with DITA and the DITA Open Toolkit.
I’m starting to wonder, though, whether the adoption rate of DITA and the DITA Open Toolkit is going to diverge.
For DITA, what we hear most often is that it’s “good enough.” DITA may not be a perfect fit for a customer’s content, but our customer doesn’t see a compelling reason to build the perfect structure. In other words, they are willing to compromise on document structure. DITA structure, even without specialization, offers a reasonable topic-based solution.
But for output, the requirements tend to be much more exacting. Customers want any output to match their established look and feel requirements precisely.
Widespread adoption of DITA leads to a a sort of herd effect with safety in numbers. Not so for the Open Toolkit — output requirements vary widely and people are reluctant to contribute back to the Open Toolkit, perhaps because look and feel is considered proprietary.
The pattern we’re seeing is that customers adopt the Open Toolkit when:
- They intend to deploy onto multiple servers, and open source avoids licensing headaches.
- The Open Toolkit provides a useful starting point for their output format.
Customers tend to adopt non-Open Toolkit solutions when:
- They need attractive PDF. Getting this result from the Open Toolkit isn’t quite impossible, but it’s hard. There are other options that are faster, cheaper, and easier.
- They need a format that the Open Toolkit doesn’t provide. The most common requirement here is web-based help. Getting from the XHTML output in the Open Toolkit over to a sophisticated tri-pane help system with table of contents, index, and search….well, let’s just say that it keeps me gainfully employed. AIR is another platform that we need to support.
The software vendors seem to be encouraging this trend. In part, I think they would like to find some way to get lock-in on DITA content. Consider the following:
- Adobe FrameMaker can output lovely PDF from DITA content through FrameMaker (no Open Toolkit). You can also use the Open Toolkit to generate formats such as HTML.
- ePublisher Pro uses the Open Toolkit under the covers, but provides a GUI that attempts to hide the complexities.
- MadCap’s software will support DITA (initially) by importing DITA content and letting you publish through MadCap’s existing publishing engine.
- Several other vendors provide support for publishing DITA, but do not use the Open Toolkit at all.
The strategy of supporting DITA structure through a proprietary publishing engine actually makes a lot of sense to me. From a customer point of view, you can:
- Set up an XML-based authoring workflow
- Manage XML content
It’s not until you’re ready to publish that you move into a proprietary environment.
To me, the interesting question is this: Will the use of proprietary publishing engines be a temporary phenomenon, or will the Open Toolkit eventually displace them in the same way that DITA is displacing custom XML structure?