Understanding the Rapid Adoption of the Darwin Information Typing Architecture (DITA)

Bill Trippe, Senior Analyst, Gilbane Group, January 2006

Sponsored by Idiom

Idiom logo

You can also download a PDF version of this whitepaper.

Executive Summary

The Darwin Information Typing Architecture (DITA) has seen rapid adoption and implementation. This is especially true when you compare the adoption of DITA with other standards-based approaches to content creation and distribution. Here we are less than a year after DITA 1.0 has been approved and major companies are shipping large multi-language documentation and Help sets that have been created using DITA. We can also point to DITA-specific user groups and conferences, and a myriad of vendors who are now touting DITA support in their products. All of this activity is over and above the use of DITA at IBM, the company that developed DITA originally and has been actively promoting it through the OASIS standards body.

This rapid adoption speaks to the usefulness, generality, and extensibility of DITA—and also to the clear recognition of the need for this kind of solution among major companies. Why is DITA finding success? Some consistent details emerged from the research.

  1. It’s available, well thought out, and comprehensive.
  2. Users “get it”—the tagging makes sense and accurately models their work.
  3. The ready style sheets and tools are a very solid starting point for implementation.
  4. As a result, DITA encourages repurposing of content into many required formats.
  5. The topic orientation encourages reuse, and aligns well with current thinking about information development.
  6. The reuse model in DITA is strong enough to support robust content management, including applications such as personalization and localization.
  7. There is evidence that DITA interest reaches beyond technical publications and online Help systems. We are seeing use of DITA-encoded content in applications such as call center support and Web publishing.

Together, these aspects of DITA combine to provide significant business value for organizations, including lower content development costs, lower localization costs, faster time to market, improved quality, and improved usability. This paper looks in detail at two major companies—Adobe and Autodesk—who have adopted DITA and are using it for major projects. It discusses the content development problems these companies faced, how they identified DITA as part of the solution, what solution they implemented, and how they have fared in using this solution.

The paper then looks at the implications of these case studies for other organizations creating product support content, and concludes with some thoughts about the applicability of DITA for other kinds of content.

Introduction: Understanding DITA

The Darwin Information Typing Architecture (DITA) is a horizontal industry effort originally designed to provide an XML framework for developing product documentation. Initially spearheaded by IBM Corporation, DITA is now maintained and developed within the OASIS standards consortium. Today, DITA has been embraced by a relatively large number of vendors and end user organizations and there is growing interest in its applicability to more than product documentation.

DITA is obviously not the first industry effort to apply XML to product support content. Numerous vertical industry efforts are long established, such as the Air Transport Association Document Type Definitions for aircraft maintenance manuals, and other similar efforts for the defense, automotive, and telecommunication industries, among others. These efforts date back to SGML, and are well established in their industries. But DITA is a horizontal effort, meant to apply to documents across a broad range of technical companies. And while there has been another significant effort “standard DTD” for technical documentation (the DocBook initiative), DITA takes a more extensible approach. DITA also, unlike DocBook, was designed with both print and online delivery in mind, as the modular, topic-orientation of DITA lends itself better to multichannel delivery.

DITA provides a core DTD and schema that define a “topic.” In DITA terminology, the topic is the basic informational unit. A topic is simply a module or unit of information that addresses a single subject. DITA has a useful notion of topic types, and the topic types already accounted for in the DITA architecture are “concept,” “task,” and “reference.” These types make a lot of sense for technical product information, where you often see user manuals (tasks), reference information (references), and more general background information (concepts).

Not surprisingly, topic-oriented writing is gaining ground in the technical documentation world as the DITA inventors imagined it would. Technical writers and other information developers recognize the value of thinking about product support content in terms of discrete topics of information. This “topic-oriented writing” lends itself to the requirement for a single piece of content to be used in many formats (print, Web, Help) as well as in many contexts (more than one manual or more than one Help screen, for example).

Structurally, DITA topics are very simple. A topic starts with a title element followed by a mix of text and images, and supporting information such as index markers and links. Topics can be organized into sections, and the topics themselves can also nest. In practice, many users prefer to nest the topics rather than use the section markup.

Significantly, DITA provides a simple mechanism for extending the core schema through something called specialization. In short, specialization involves creating extensions, or deltas, to the existing DTDs or schemas. This way the specialized DTDs and schemas can be tracked more closely with existing tools such as style sheets and transformations. The DITA Open Toolkit comes with a number of generic transformations for print, online Help, and HTML. Specialized DITA content can use the generic transformations, often with little or no modification. As DITA itself evolves, specialization will enable the earlier versions of DITA content to work with later versions of the standard schemas and transformations.

Finally, we see the application of DITA to content outside of technical documentation and product support content. The DITA topics—task, reference, and concept—potentially can be applied to all kinds of content. We also think the ease of use and the ability to specialize also make DITA a candidate for many applications that call for structured content creation and management. The generic transformations in the DITA Open Toolkit also enable rapid application development, especially as more and more developers regularly use XSLT and other stylesheet technologies.

DITA: Why all the Buzz?

Experienced technology professionals know all too well the hype that surrounds so many new technologies, and how rarely that early hype is realized. Gartner described the “hype cycle” in the 1990s, where an initial period of inflated expectations is followed necessarily by a “trough of disillusionment” as early adopters slough through the difficulties of implementing something new and unproven. Indeed, expectations rise precisely because no one is actually using the new technology yet, so of course it can solve everything. As a writer said about XML a few years ago, “It is the software industry’s latest solution to world hunger.”

Yet we seem to be experiencing something very different with DITA. We are clearly in the midst of a lot of publicity about DITA—vendor announcements seem to be published every day and a DITA-only conference has been announced. Yet, unlike the traditional hype cycle where this period of initial inflated expectations coincides with few people actually using the new technology, in the case of DITA we have many people using the technology. Indeed, the documentation and Help system for Adobe Creative Suite 2—one of the most widely selling software products—was created with DITA-based tools in time for the commercial software release on April 4, 2005. Significantly, the first formal release of the DITA specification by OASIS did not occur until a month later on May 9.

A few other points that emerged from our research:

  • Adobe is not alone in using DITA. This paper also profiles the use of DITA at Autodesk, but other major companies are using DITA today. Both IBM and Nokia use DITA in many areas of their businesses.
  • In the course of our research, we corresponded with or interviewed people from a number of companies including software vendors, hardware vendors, consulting companies, and system integrators.
  • The adoption level around DITA is also clear from user activity. There is both a general DITA user group and a FrameMaker-specific user group on Yahoo.
  • Regional DITA groups have been formed in a number of metropolitan areas, and the CM Pros organization has recently formed a CM Pros DITA Community.

As we have noted before, merely declaring a standard to be a standard is not sufficient. Other things must follow for a standard to be successful—a demand from a critical mass of users, an open process for honing and maintaining the standard, and support from both the vendors and from open source developers. DITA clearly has all of these things.

Case Study: Adobe Systems

The Problem

Adobe Systems is one of the world’s largest software companies, providing best-in-class publishing and document sharing technologies to customers in 20 countries. Adobe’s well-known products for creative professionals, including Adobe Illustrator, Adobe Photoshop, and Adobe InDesign, are now marketed as a suite of products. Adobe Creative Suite 2.0 was released in April of 2005.

Adobe produces voluminous documentation to support their products. The documentation for Adobe Creative Suite totals 196 documents and over 110,000 pages, translated into 14 languages. The documentation is a key part of the localization process, which also includes localization of the software, Web site, and marketing materials. The translation work is done on an aggressive schedule. Typically, Adobe releases the English language version first, and two weeks later ships the French, German, and Japanese versions, though some software releases have all four languages shipping simultaneously.

Why DITA?

As a developer of publishing software, Adobe is in a unique position to do this kind of large-scale authoring and production. Adobe FrameMaker is the tool of choice for many technical writing professionals, enabling them to create full documentation sets in print and in essential complementary formats such as HTML and Help.

Since 1995 Adobe has been using FrameMaker to simultaneously produce their documentation and associated Help files. With FrameMaker, FrameMaker plug-ins, and custom scripts, the Learning Resources group had a very effective process for single source publishing, but found that the scale of their work demanded further automation.

It was significant that Adobe was moving to the model of selling their creative software tools as a suite, instead of as standalone programs. A critical measure of success for the suite would be to provide an integrated user interface and user experience, and the documentation and Help would be key to this. Moreover, releasing the products as a suite would bring an additional requirement to share content authored by different groups, including documentation, support, and training.

With the need to do so much localization, the group found that reuse could also lead to greater efficiency in the localization work itself. With greater reuse and more granular management of the content, they could more efficiently translate the content into the different locales. However, using unstructured FrameMaker files, the group was only able to share large chunks of content, typically whole chapters. Moreover, the content was inevitably rewritten during editing and review for each locale. The result was higher development and localization costs, long lead times, and lower quality and usability.

Together, these requirements pointed to a need for the Learning Resources group to adopt a content development process that would make more use of reusable modules of content. Further analysis pointed the group to DITA, which they felt offered the following advantages over their prior process of using unstructured FrameMaker:

  • A specific and declarative schema that helps clarify the documentation
  • Easy to understand markup
  • Topic-based, as opposed to book-based organization to facilitate reuse
  • Ability to share modules of content across products within the suite

Technology and Tools Used

The Adobe team had in FrameMaker a tool that could support the DITA XML tagging. FrameMaker includes an application called an EDD (Element Definition Document) that maps the XML tags to the internal FrameMaker formatting commands and validates the XML markup. To begin using the structured version of FrameMaker, the Adobe team had to convert the unstructured FrameMaker files to the DITA XML elements. FrameMaker has an embedded technology for doing such a conversion, and the Adobe team used the conversion mechanism along with XSLT scripts to convert all of the files.

But the larger issue for the Adobe team was the need to manage the content at a more granular level and with a more automated workflow through the authoring, localization, and production cycles. To move beyond what been a primarily manual process, the Adobe team implemented WorldServer from Idiom Technologies. With its built-in support for DITA as well as other content formats WorldServer enabled Adobe to combine the topic-oriented DITA approach with translation and localization automation.

DITA would have provided significant benefits to Adobe even if only a single language was used but significantly higher levels of efficiency and global content reuse were achieved when DITA combined with Idiom WorldServer.

Adobe also uses WorldServer workflow capabilities to automate the global content lifecycle. For example, the Adobe team added a filtering mechanism that allows them to show content modules to the translators only when ready for translation. This way, the translators only work on the modules when required—at a key state in the workflow or when a significant amount of the content has changed. When the module is ready for translation, the author can change a flag and the module is made available for translation.

The Adobe team also created a workflow tool for review. At certain stages in the workflow, review copy content is automatically created and posted to a server. The reviewers then receive emails alerting them to the location of the document.

Result

After an initial pilot period with a smaller group of evangelists, the new system is in place and being used with Adobe’s own content creation and production tools to deliver print and online documentation for Adobe Creative Suite 2 , globally. The process has benefited from both the DITA XML tagging and from the new globalization technology.

XML Authoring and Production

  • Adobe writers now have centralized and uniform access to XML-encoded content through a Web-based client interface.
  • All content is validated, and cross-references can be made to all DITA content.
  • Previews (print, HTML, Help) can be generated on any topic before related topics have been completed – or later when all related topics are ready to be assembled into larger units (e.g., chapters, books, etc.).

Globalization

  • The corresponding translation and localization workflow at Adobe is fully integrated with the authoring workflow, tying in localization project managers in several locales into the process as early as possible.
  • Translators and other localization team members have the same preview capabilities as the authoring team.
  • By making ongoing translation and localization practical at the topic level, work can be completed on smaller units of content saving time and money versus traditional approaches.

Business Benefits

The Adobe team can point to a number of business benefits of using DITA together with their WorldServer system.

  • The principal benefit has been a more flexible workflow with smaller, timelier handoffs during the content development and translation processes. This differs markedly from the past, where the handoff to translation involved entire documents or large portions, and the core English content had to be completed as early as possible. The result is significantly shorter time-to-market.
  • The reused content improves the user experience and also helps to reinforce the goal of the product suite—cross-product workflow.The products in Creative Suite are widely used and often used together. A photo retouched in Photoshop becomes an element in an Illustrator design or in an InDesign page layout. A uniform interface—including the documentation and Help—is key.
  • The new system supports a number of content reuse and sharing scenarios that the Adobe team envisions using in the near future.These include customized Help, training, and support.
  • The structured content positions Adobe to do more things with product support in the future. They could do additional reuse and customization of the content, adapting it and repurposing it for different products and different audiences.

Lessons Learned

The new system is in place, successful, and in full production, and has given the Adobe Learning Resources group a productive platform for their ongoing work. Of course, implementing any new system has its challenges. The Adobe team faced and overcame a number of challenges in the course of specifying and implementing the new system:

  • Data Conversion. The team had to convert a massive base of documentation from unstructured FrameMaker files to the DITA XML tagging. The tool to convert unstructured FrameMaker to XML assumes consistent paragraph styles and character formats are in place, so the documents had to first be edited to ensure proper formatting. FrameMaker was augmented with XSLT scripts, and a number of iterations were made to the process until it was able to convert about 90% of the markup automatically. Minor fixes were then made manually.
  • DITA Specialization. The team was not able to use the DITA Document Type Definitions “as is,” but was able to limit the specialization of DITA to a small number of minor changes to the base DTD.
  • User Acceptance. The team converted a large documentation set and began using a new system in the midst of ongoing product development. To ensure an orderly transition to the new system, evangelists from each functional team were identified to help design and pilot the new system. Only when the new system was as productive as the existing one were the larger groups transitioned to working on it.

Case Study: Autodesk

The Problem

Autodesk, Inc. is to users of computer-aided design software what Adobe is to users of graphic design and illustration software—the undisputed market leader. Founded in 1982, Autodesk markets AutoCAD, the leading CAD software with widespread use in construction, manufacturing, and a number of other major industries.

Beyond the flagship AutoCAD product, Autodesk develops and markets a wide variety of software products. Many of these products are vertical applications built on top of the AutoCAD design platform, re-using AutoCAD features and AutoCAD documentation. These include industry-specific three-dimensional design products such as Architectural Desktop 2006, three-dimensional design products such as Inventor Professional 10 and Civil 3D, and project management and product lifecycle management products such as Buzzsaw, Streamline, and DWF Composer. Together, these products comprise a $1.2B annual software business for Autodesk, with over six million users in over 100 countries worldwide.

With such a large and diverse set of products, Autodesk is a significant publisher of product support content. Beginning with AutoCAD, the products are full-featured and complex, and need to be supported with a variety of product documentation. Deliverables include online Help, PDF documentation, online and PDF tutorials, installation guides, reference guides, and more. For the vertical applications built on top of AutoCAD, a Help system is usually a complex conglomerate containing many separate modules, like product Help, AutoCAD Help, driver and graphic card Help, and more. And because Autodesk has a global business, this product support content needs to be localized into 18 different languages.

These requirements are significant, and Autodesk has been on the leading edge of using new technology to address these requirements. Autodesk’s documentation group was using unstructured FrameMaker to create their documentation and online deliverables. Several years ago, Autodesk began using structured FrameMaker for authoring, first making use of the underlying SGML tagging and more recently the XML tagging. The various outputs (print, Help, other online) were created using the FrameMaker publishing tools and tools and a FrameMaker add-in, WebWorks Publisher.

The Autodesk team saw the process of moving to XML as an opportunity to reengineer their processes, and not merely to transplant existing processes. In their words, they did not want to “make XML do what they were already doing today.” Like Adobe, Autodesk saw an opportunity to leverage XML to improve single-source publishing, to increase the reuse of core content modules, and to make their content device- and application-independent.

The Autodesk team also knew they would be moving at some point to a system that, ideally, would also help manage the localization processes. So the adoption of XML was seen as a natural stepping-stone toward the more formal management of the content and the editorial, production, and localization processes.

Why DITA?

The Autodesk team had a long-term vision for their implementation of new technology for producing and managing their product support. The transition to XML was a necessary but not sufficient part of this process, which would also include:

  • Structuring their content into more discrete modules to enable greater reuse and more flexible publishing.
  • Adopting a content management and globalization management solution that would include workflow management and the ability to query the content.
  • New and more flexible tools for creating various print and online output, such as using XSLT for creating HTML and XSL-FO for creating PDF.

The ideal system would be able to support a much more flexible, user-driven publishing model with features such as dynamic, user-customizable Help, profile-driven content, and customized deliverables of standard documents.

The Autodesk team identified DITA as a useful model for their product support content, but also recognized that the core DITA Document Type Definition (DTD) would need to be customized to meet their needs. They also recognized that a single DTD would not sufficiently address the many different documentation needs across the company, so they specialized the core DITA DTD. As the Autodesk team saw it, the combination of a core DTD and the ability to specialize it provided the following benefits:

  • Even with the specializations, the documentation shares a common set of elements and attributes, enabling significant reuse of the XSLT and XSL-FO stylesheets.
  • The common elements and attributes also enable more ready sharing of content between departments.
  • The common elements and attributes also enable Autodesk to evolve the content over time.

Technology and Tools Used

Like the Adobe team, the Autodesk team had in FrameMaker a tool that could support the DITA XML tagging. The Autodesk team developed a FrameMaker EDD (Element Definition Document) to map the DITA XML tags to the internal FrameMaker formatting commands. As with Adobe, the Autodesk team also had to convert the unstructured FrameMaker files to the DITA XML elements. One significant way that the Adobe and Autodesk teams differ in their approach is with the published output. While the Adobe team relies on FrameMaker to produce the various outputs, the Autodesk team has instead gone with a combination of XSLT and XSL-FO scripts and tools to produce the various outputs. In this way, FrameMaker is used as a pure authoring tool, and the output tools are independent of the authoring program.

As with Adobe, the Autodesk team had the broader goal of managing the content at a more granular level and with a more automated workflow through the authoring, localization, and production cycles. The Autodesk team implemented Idiom WorldServer for managing the global content delivery process.

Significantly, the Autodesk team felt they had achieved a high level of automation even before they implemented the Idiom solution. The move to XML, and the automated output using XSLT and XSL-FO, had already given the team a number of process and quality improvements. However, their analysis showed that the most compelling improvements and greatest return on investment would come with the savings on localization and translation gained from moving to a formal platform for globalization management.

Result

Autodesk has successfully implemented the new system, and is now creating a wide variety of documentation, Help, and instructional materials from the XML source. Component files of content are managed within the Idiom system, and automated workflow tools enable writers, translators, and other personnel in a collaborative, continuous process. Changes to the core (English) content are flagged for translation, and the globalization system is leveraged to keep track of the changes and mange the translations.

The Autodesk team has been able to implement some new features to the documentation that aid the end users. For example, the Autodesk team wanted the documentation to highlight new features in the software. To enable this, the team created XML attributes that could be added to the documentation to highlight new features. When the XML is then transformed into Help, a New Features “jump list” is created automatically and a special icon is added to the table of contents.

Business Benefits

The biggest improvements and time savings come in a) localization where AutoDesk is enjoying significant savings, and b) in the desktop publishing and production of the various documents. The new system replaced manual, time-intensive tools with automated XSL and XSL-FO scripts that take the DITA-encoded content and produce the final output automatically. For example, a single-chapter can be produced in 2 minutes using the automatic tools, and a full, 3000-page Help product can be generated in 45 minutes.

Even more significant savings rise from the reuse of the core AutoCAD documentation. Because the AutoDesk team bases so much of the specialized product support content on the core AutoCAD content, the team is able to reuse the core platform content with only slight transformations. They are also able to share and modify content between the various vertical applications with minimal effort, thereby gaining further savings.

The AutoDesk team is currently using the DITA-based system to produce product support content in more than 15 languages.

Lessons Learned

Autodesk is five years into an ambitious project to reengineer and retool all of their mechanisms for creating and managing product support content. They have made the transition from unstructured content to XML-structured content, and they have established a centralized system for managing their content, managing their workflow, and managing their processes for translation and localization. The Autodesk team can point to a number of lessons learned from this project:

  • The focus of the effort should not be on “getting the content into XML” but on arriving at better processes for creating, managing, and reusing content going forward. The transition to a new system is an opportunity to reengineer, so adopting companies should caution against migrating existing problematic processes into the new system.
  • Adopting organizations should also focus on the needs analysis and the use cases for the new system, and should caution against jumping to any particular solutions or tools. As one of the principals cautioned, “don’t fall in love with a particular XML authoring tool or system” before you have determined if it will in fact meet your needs.
  • Adopting organizations should consider how they will prototype or pilot the new tools while continuing to ensure the delivery of the content. The Autodesk team decided to not run a separate pilot with the new system, and instead worked with production prototypes of the new content and tools at the same time they were producing their newest product documentation. This added some risk to their delivery cycle but also gave them the ability to fully test the full content set in a live production environment. The team felt that using the new system with live data was a much more realistic way to test the new system than if they had run a separate “sandbox” pilot.
  • The specialization mechanism in DITA has proved to be a valuable tool for Autodesk, allowing them to satisfy the requirements of a large documentation community while also ensuring reuse of the content and wide reuse of key supporting tools such as the XSLT and XSL-FO transformations.

Conclusions

Common Threads

The two case studies and the other interviews we conducted point to some clear common threads among the organizations who have adopted DITA in product support applications where globalization is a critical requirement.

  • The DITA tagging system is well suited for product support applications. The core DITA information types—concept, task, and reference—and the topic orientation of DITA align well with the kinds of content created for product support. In these two case studies, both teams transitioned from unstructured authoring processes to using the full DITA tag set. The organizations were able to readily map their unstructured content to the DITA tag set, and the users began using the new tagging scheme with a minimum of training.
  • Success in single-source publishing is a positive step toward implementing the more formal mechanisms of XML. Both case studies involved organizations who had used single-source publishing tools as a means to create print, Help, and other electronic formats. Their success with single-sourcing led them to explore the logical next step in automating their production, which was to structure the content in XML and modularize the content to facilitate reuse.
  • For all the success with XML publishing, the greatest business benefits seem to come from the savings in globalization. Both organizations found the most compelling reason for implementing the new system in the potential savings in translation and localization costs. And the new systems have borne the fruit that that the organizations hoped for—giving them much more efficient and cost-effective means for translating and localizing their content. This confirms our analysis that the combination of modular content, XML encoding, and globalization can yield significant benefits for the adopting organization.

Potential Future Directions: DITA for the rest of us?

While this paper and these case studies focused specifically on product support documentation, we do think there are some implications about how DITA-encoded content can find broader use in organizations. Our research pointed us to several uses of DITA in applications outside of technical product content.

The core DITA topics—task, reference, and concept—while articulated for product support content, apply to all kinds of content. This white paper, for example, could readily be tagged in DITA, as could other kinds of marketing content, reports, policies and procedures, and a myriad of other routine document types. While such an argument has been made before about XML in general and certain generic XML schemas (e.g., Docbook), we do feel that DITA has certain characteristics that make this more general applicability much more feasible. These include:

  • Ease of use.
  • General applicability of the core information types (task, reference, concept).
  • The ability to specialize.
  • Existence of generic tools and transformations (stylesheets, publishing tools, authoring tools).
  • As a result, we see the use of DITA emerging in a number of applications outside of product support content.

Organizations are looking at DITA for user-contributed content in applications such as call center support and community applications such as message boards. Consumer-product companies, for example, are expanding their Web sites to allow users to post product reviews, tips and suggestions, and other kind of editorial content. This user-contributed content often becomes an integral part of the Web site, but the challenge emerges to maintain this content over time. How can this content be effectively managed—perhaps even translated for different locales as the company expands its markets and offerings? DITA could provide an easy to use—but robust enough—encoding mechanism for this kind of content.

  • Web site content itself has typically not been done with XML encoding. Early generation Web sites especially relied on on-the-fly creation of pages from relational databases. Often, the content is a mix of this fielded data and HTML encoding. A more XML-based, structured approach to Web content development would serve organizations much better. Over time, the Web site would be more maintainable, more extensible, and more easily localized. However, for all the common sense of using XML, XML-based standards for Web site content have not emerged. We see in DITA an excellent framework for Web site content.
  • eLearning is a significant undertaking for many large organizations. Training is a critical success factor in everything from policies and procedures to new product information to the adoption of new tools and technology. John Hunt from IBM, one of the early DITA architects, has been writing about DITA for eLearning (he also spoke at a recent Gilbane conference). John wrote recently, “Core DITA provides the starting point to develop a content model for learning. However, learning content and delivery have specific needs that go beyond what’s available with the core DITA topic types and processing model. Fortunately, the DITA specialization architecture provides a built-in method to extend DITA to support new content needs associated with learning.”1.
  • Some recent discussions with XML vendor Blast Radius (XMetal) have pointed us to another significant application of DITA, and that is for the creation and management of customer-facing and customer-created content. Paul Wlodarczyk, Director of ECM Strategy for Blast Radius notes that while DITA was conceived for tech pubs, its benefits make it well-suited for other types of content, “particularly the kinds of granular, customer-facing content that we typically see on the Web. For example, product or services descriptions, reviews, and FAQs are inherently topic-oriented, but today are implemented in ad hoc or proprietary formats. Companies can benefit from using DITA specializations for these types of content through streamlined flow of content within and across enterprises and between systems, and can also benefit from lower costs of localization. And because of these benefits, we expect to see DITA applied to a number of scenarios, such as e-Learning, CRM, and e-Service. We may even see industry-specific DITA specializations for enabling unstructured content interchange between trading partners, such as the syndication of product descriptions between manufacturers and retailers.”

Finally, some key business requirements point to the need for a generic XML mechanism for encoding more business content. These include the need for more structured authoring given the growth of content management systems, recognition of the value of single-source publishing and modular management of content, and the growing recognition of the need to globalize more content. Taken together, these requirements could lead many organizations to look to DITA as a generic mechanism for encoding critical business content.

1. An XML-based information architecture for learning content, Part 1: A DITA specialization design: Use DITA XML to develop reusable learning content , John P. Hunt (john_hunt@us.ibm.com), DITA Learning Architect, IBM and Robert Bernard (bbernard@us.ibm.com), DB2 Training Developer, IBM, August 5, 2005. http://www-128.ibm.com/developerworks/xml/library/x-dita9a/

Sponsoring Company Information

Idiom Technologies, Inc.

For more information, please contact:

NORTH AMERICAN HEADQUARTERS:
Idiom Technologies, Inc.
200 Fifth Avenue
Waltham, MA 02451 USA
Phone: +1 781.464.6000
Fax: +1 781.464.6100

EUROPEAN HEADQUARTERS:
Idiom Technologies
Quatro House
Frimley Road
Camberley
Surrey GU16 7ER UK
Phone: +44 01276 804488
Fax: +44 01276 804489

www.idiominc.com

Idiom and WorldServer are trademarks, or registered trademarks of Idiom Technologies, Inc. All other brand names, product names, or trademarks belong to their respective holders.