Best Practices for Component-Based Authoring: Third in a 3-Part Series

Knowledge Center contributor Eric Severson's 3-part series on component-based authoring began with an introduction of the notion of component-based authoring and a description of component-based authoring's significant business benefits over document-based authoring. In his second part, an explanation was given about how component-based authoring actually works. In this third and final part, Eric provides you with a variety of practical advice to help you get started with component-based authoring and to ensure your success using component-based authoring in your business.

This is the third 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 second article, "How Component-Based Authoring Works: Second in a 3-Part Series."

I will start this third and final part of my 3-part series on component-based authoring with a definition of the content model. Even though DITA (Darwin Information Typing Architecture) is already a defined specialization, the first step is still to determing how your content will be structured. DITA uses a very flexible content model in which many different kinds of topic structures can be defined. This is done through a powerful and unique DITA feature called specialization.

Consistent with the information typing aspect of DITA, specialization allows you to create your own variations of the generic topic structure, each of which becomes a different topic type. Three out-of-the-box specializations are included with the DITA standard: concept, reference and task topic types.

Most pre-DITA applications of XML have required relatively complex and restrictive content models. This has had the advantage of precisely controlling document structure and format, but with the disadvantage of making XML difficult to author and maintain. In contrast, DITA gives us a wide spectrum of choices as to how simple or complex our content models need to be.

Remember that DITA allows any number of stand-alone, reusable topics to be assembled into a map. The map defines the hierarchical structure for each output publication or deliverable-which may be quite complex-while allowing the topics themselves to have a relatively simple structure.

With this in mind, the first question to ask is whether there's really a compelling reason to use anything other than the standard DITA specializations. In fact, for some applications, the question is whether we need to use anything other than the generic DITA topic itself. There is always a cost-especially in usability-when the content model is more complex than necessary.

In cases where specialization is needed, we recommend specializing directly from the standard concept, reference and task types. This is the best way to ensure future compatibility with both changes to the DITA specification and to the off-the-shelf tools that implement it.

If you can't use the standard types as the basis for specialization, then we recommend staying as close to the standard types as possible. This will give you the greatest chance of staying consistent with vendor tools as the standard evolves-and make it much easier to switch back, so to speak, if you find that future versions of the standard specializations fit your needs.