Abstract

What is DITA?

Business case for DITA

Architecture overview

Implementing DITA versus implementing custom XML architecture

Resources

Business case for DITA

DITA is an XML vocabulary, so the rationale for XML implementation also applies to DITA. A publishing workflow based on XML can:

• Enable content exchange
• Support automated database content extraction
• Lead to reduced content duplication and increased reuse of information
• Extract information based on structure and metadata
• Improve formatting consistency
• Reduce author learning curve
• Reducing repetitive desktop publishing tasks in house and in translation
• Improve compliance with required document structures

For a detailed discussion of the rationale for XML implementation, please refer to our Structured authoring and XML white paper.

DITA may offer additional benefits, which are described in the following sections.

Reducing content modeling requirements

The transition to XML-based authoring typically includes a significant content analysis effort. The DITA architecture offers a modular, flexible architecture designed to support software documentation efforts. By assuming that DITA structure is a reasonable match, some organizations are bypassing the content modeling effort.

Eliminating content modeling allows for a much faster transition to structured authoring. The trade-off is that DITA, out of the box, probably is not an exact match for the organization’s content. Without doing content analysis, though, it’s hard to know ahead of time whether the mismatch will be significant. Using more general markup is a potentially serious problem for content in specialized industries. For example, the metadata required to support medical device documentation or financial services information probably goes beyond what DITA provides by default. If, however, your organization is creating basic documentation for consumer software, DITA structure might be a good fit.

Making content truly portable

The XML file format is application-neutral and easily read by many different applications. But when two organizations choose different XML structures, exchanging information can still be problematic. Consider the example shown in Figure 1.

XSL transformation would allow you to convert the element structure shown in version A to the element structure shown in version B. For this example, the transformation would be simple as the two element trees are basically compatible. Notice, however, that Version A contains author and modification date information and Version B does not. That means that when you transform from A to B, you will discard some content. If you author new content in B, transformation to A will result in a document that is missing some information.

One argument for implementing DITA XML is that the content will be compatible with any other organization using DITA. This can be especially important for companies that license their products to other organizations. IBM, for example, has standardized on the use of DITA for technical publications, so if you are required to deliver content to IBM, it’s likely that they will request (or require) DITA-based content.

Supporting content reuse

For many organizations, reuse is a primary factor driving XML implementation. DITA supports reuse of topics and smaller bits of information. This is discussed in more detail in the architecture overview. A custom XML implementation can also support content reuse, but the work has already been done in the DITA architecture.

Tools support

The Big Three XML authoring tools—Arbortext Editor, structured FrameMaker, and XMetaL—provide support for DITA authoring. In your evaluation, be sure to look at the following:

• Support for map files
• Integration with the Open Toolkit
• Creation and resolution of content references (conrefs)
• Support for specialized elements

Software vendors are some of the most ardent supporters of DITA. For a software developer, supporting all the possibilities of XML presents a formidable challenge. Focusing on DITA, a specific implementation of XML, makes it much easier to create user-friendly authoring -applications.

In other words, if you choose to implement DITA, you will probably reduce the cost of configuring the authoring and publishing tools you choose. Keep in mind, however, that the up-front implementation costs are only a small component of the overall cost structures that you need to evaluate. Reducing integration cost is obviously a plus, but it probably won’t make or break your business case analysis.

Generating output

The DITA Open Toolkit (DITA-OT) provides transformation files to create output for several common formats, including PDF, HTML, and HTML Help. Using the Open Toolkit as a foundation for your publishing efforts can reduce the cost of building output generators.

For a custom XML architecture, no default transformations are supplied, so you must build the output generators on your own.

The toolkit files provide basic output. If you want to customize this output, you need to modify the transformation files provided with the Open Toolkit. If your output requirements differ significantly from the default, or if you do extensive customization work on the default DITA structure, the effort required to customize the toolkit files may be just as great as the effort to build output generation files on your own.

Next page:
Architecture overview

Copyright © 2008 Scriptorium Publishing Services, Inc. All rights reserved.