The term single-sourcing is too simplistic to describe today’s content creation environments.
Back in the 1990s, single-sourcing meant creating content in one format and then converting that content into another format. So, for example, you authored content in FrameMaker. The FrameMaker files were print-ready and you could generate PDF from them. For online outputs, there were converters, such as Harlequin WebMaker, WebWorks Publisher, or (much later) ePublisher Pro.
The key to single-sourcing is that you put all of your content into a single format and workflow, then push the content (with varying degrees of pain and rework) to multiple output formats.
Many single-sourcing workflows were print-first. You created the print files and then figured out how to derive online formats from those files.
Introducing separation of content and formatting
Then, along came SGML and XML. The premise of these and other markup languages is separation of content and formatting. We mark up the text with a tag, and that tag is interpreted differently in print than in HTML. The <emphasis> tag might result in italics in print and in boldface online.
In general, though, we have been trying for a world in which all authors work in a single environment (such as DITA XML, the Darwin Information Typing Architecture), and we pushed their content through the same workflow to generate output. We have oceans of posts on “how to get more people into XML” or “how to work with part-time contributors.” The premise is that we have to somehow shift everyone into the One True Workflow.
But today, we have a complex landscape with lots of different places to create, store, manage content. Different software vendors are promoting different ways of doing things.
Some component content management system vendors offer integration their system and a variety of delivery portals. Some vendors offer end-to-end solutions that include authoring, CCMS, and delivery.
I believe that our future is shared pipes; that is, a shared infrastructure for terminology, information architecture, and localization.
To ensure a minimum level of quality, all content must go through the pipes.
Where appropriate, we’ll have single-sourcing, but not all content needs the same level of quality review. Instead, we’ll have make a distinction between “quick and dirty but good enough” and “must be the best quality we can manage.”
In a shared pipes environment, all of your content might use the same rendering and localization workflows, but diverse source formats and authoring tools.
What do you think? Is single-sourcing still the right term? Are we evolving toward a more complex workflow?