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?
Julio Vazquez
Hi Sarah,
I think that one of the important points that most folks miss is the intent of the DITA Open Toolkit. In publishing the toolkit, IBM and OASIS were trying to do one thing: establish a reference implementation of the DITA specification. This is not the language itself but what processing engines might do in specific cases. There is little investment in making the OT a production environment and that’s probably a good thing. Basically, the client who decides that DITA is a good solution, with or without specializations, should be free to choose whatever implementation of the specification best fits them as long as that implementation follows the specification. Whether it’s an open solution or a proprietary solution depends on the needs and abilities of the user. Some can afford the licensing expenses and some cannot.
If you’re very well-versed in XSLT and XSLT-FO, you could even roll your own implementation and publish it to the world for use. You are free to do what you will to create whatever output you need. That’s one of the beauties of DITA; the language and the specification allow the freedom to do myriads of things depending on your comfort level with various aspects of the entirety.
Will the Open Toolkit ever go away? I doubt it. There’s a need for a reference implementation so those with the resources and imagination can build the best transform engine they can for specific needs. Will more folks go to implementations other than the Open Toolkit? Yes. I fully expect that all clients will find some method to produce the elegant output they need from the available semantics and metadata and that’s how it should be. A standard should not restrict but enable.