Single-sourcing strategy I used for a Developer Guide

I utilized single-sourcing for most of my documentation projects. Here is an example of  how I accomplished single-sourcing for a Developer Guide:

1) The document needs to be delivered to two different formats: internal developers as PDF and external developers as HTML. The PDF version includes more topics than the HTML version. To accomplish this, I wrote the source file in DITA XML, and created two different ditamaps: one for PDF and one for HTML. The PDF version ditamap includes several topics that are specific for internal users but most topics are reused by both ditamaps.

2) I used conditional text for content within a topic that is intended for different audiences by applying @audience:

<p audience=”internal”>Information for internal users</p>
<p audience=”external”>Information for external users</p>

3) I used content reference for content duplications. For example: Some APIs have same input parameters. When a parameter was first motioned, I added @id for it:

<p id=”parameterA”>Information about parameter A</p>

If the same parameter appeared later in a different document, I used @conref to reference to it:

<p conref=”filename.xml#topicid/parameterA” />

4) I used application name as a keyword variable in my document to avoid manually updates if the application name changes later. At the beginning of the ditamap, I used to define the application name as a keyword:

<keydef keys="AppName"> 

 <topicmeta>
 <keywords>
 <keyword>ACTIVE Passport</keyword>
 </keywords>
 </topicmeta>
</keydef>

Anywhere in a topic, when needed to mention the application name, I used the reference:

<keyword keyref="AppName"></keyword>

The application name always changes for a new product. If it happens, I only need to change the keyword in the ditamap.