How Component-Based Authoring Works: Second in a 3-Part Series
In the first installation of this 3-part series on component-based authoring, Knowledge Center contributor Eric Severson introduced component-based authoring and described its significant business benefits over document-based authoring. In this second part, Eric will explain how component-based authoring actually works, why DITA is the state-of-the-art XML standard of choice, and why a CMS is needed to keep track of all the components.
This is the second installation of a 3-part series on component-based authoring. Click here to read the first article, "How and Why to Use Component-Based Authoring: First in a 3-Part Series" and click here to read the third and final article, "Best Practices for Component-Based Authoring: Third in a 3-Part Series."
Component-based authoring involves breaking up information into smaller, reusable components which can then be flexibly recombined into a variety of output types and delivery channels. By avoiding the need to redundantly maintain information in multiple places, organizations have typically seen savings of 30 to 50 percent in authoring, review and production costs. Plus, they have seen up to 70 percent in language translation costs.Component-based authoring has also paved the way for dynamic, personalized information delivery--combining exactly the right components to fit each individual user's needs. But how does component-based authoring actually work? Basically, there are four main pieces to this puzzle: 1. A new way of writing: thinking of your information in terms of reusable components rather than as a set of documents, books or Web pages.
Within each topic, it's also possible to apply filtering criteria to individual elements. For example, two topics about installing a software module might be exactly the same--except for detailed differences between specific Unix and Linux commands. Rather than maintaining two parallel topics, DITA lets you put both types of commands in a single topic, marking each as applicable to either Unix or Linux.Using a CMS to keep track of all the components When information is split up into reusable components, change management becomes complex. This is especially true when components are shared across a large number of output types. Not only is it necessary to track all the changes but also to ensure that updated components will continue to make sense in all the contexts for which they're reused. Meeting these needs requires a CMS (Content Management System). A CMS prevents components from being changed without proper permission, and explicitly controls the change and review workflow. The CMS also provides a "where-used" capability, which automatically tracks the linkages between components and all the outputs in which each component is used. This prevents reused components from being deleted (causing broken links) and gives the author a view into all the various contexts which will be affected by a change. Those who own these other contexts can also subscribe to component changes, and can be notified automatically each time an update is being proposed. When choosing a CMS, it's very important to ensure that the CMS is tightly integrated with your XML authoring tool. This allows authors to perform key CMS functions from within the authoring tool, while letting the CMS control permissions, workflows and where-used relationships. From within the XMetal tool, for example, users can browse and search a CMS, check individual components in and out, review changes in multiple contexts, and participate in formal review and approval workflows. Assembling and delivering final output Using a set of DITA maps, reusable topics can be mixed and matched into virtually any combination of output documents, Web pages or other assemblies. By applying the proper XML-based style sheet to each map, XML source can also be transformed to virtually any output format or media. Special assembly and deliver engines are used to process XML content. For example, an open source module called the DITA Open Toolkit is often used to process DITA-based content. In general, these modules perform specific steps: 1. Assemble all topics according to instructions in the DITA map. 2. Include any information linked into the body of each topic (for example, an error message description linked from a list of error messages). 3. Filter the content inside each topic based on profiling instructions (for example, Unix vs. Linux operating system). 4. Apply the appropriate XML style sheet to produce the desired output format. In a static publishing scenario, DITA maps are created in advance for each pre-defined publication type (documents, Web pages, help systems and so forth). Each of the maps contains references to the topics that should be included for that particular publication. DITA offers the flexibility to create a different map for each personalized scenario you wish to support. For example, rather than publish one book that covers multiple products, we could have a different DITA map for each. But DITA can go even further than this. Since DITA maps are just XML files themselves, they can be automatically generated to support a fully personalized, dynamic publishing scenario. In this case, the dynamic map can be used in conjunction with a real-time XML query to pull the right topics from the repository. In fact, the XQuery standard, which is normally used for this purpose, can find relevant topics, filter or "profile" topics so that only applicable content is included. Plus, it can dynamically transform DITA XML into the desired output format (e.g., HTML and PDF)--all as part of a single, real-time process. Taking the next step Now that you have some understanding of component-based authoring and how it works, it's time to move on to the details of how you get started and what you need to do to ensure success. These kinds of practical advice and best practice examples are the subject of the next and final installment of this 3-part series. Stay tuned! This was the second installation of a 3-part series on component-based authoring. Click here to read the first article, "How and Why to Use Component-Based Authoring: First in a 3-Part Series" and click here to read the third and final article, "Best Practices for Component-Based Authoring: Third in a 3-Part Series."
Eric Severson is co-Founder and Chief Technology Officer for Flatirons Solutions Corporation. Eric is also on the board of directors for IDEAlliance and is a former president of OASIS--both XML industry consortiums. He can be reached at Eric.Severson@flatironssolutions.com.