What problems can single source publishing solve?

If you produce a lot of documentation, do you encounter any of these problems:

Single source publishing can help you solve all these problems.

What kind of publications are best suited to single source publishing?

Single source publishing is useful for all kinds of documents that can be published using your own standard layouts. Examples of suitable documents include technical manuals, user guides, training resources, product brochures, research reports, policies, legislation, court decisions, tender requests and information booklets.

What are the benefits of single source publishing?

A single source publishing system will enable you to:

Single source publishing enables organisations that produce documentation to meet the widest range of user needs with the least amount of manual production effort and cost.

What kinds of organisation can use single source publishing?

Single source publishing is very effective for organisations that:

Examples of organisations that can benefit from single source publishing include:

How is single source publishing different?

Most likely, you are now using office software such as Microsoft™ Word or Open Office to create your documents. If you produce documents to be printed, you might use a desktop publishing application such as Adobe InDesign™.

Another option is that you produce documents for the web using a web CMS that handles all the web publishing issues for you. The web CMS may import content from Word documents.

If you are reading this, the chances are that you have discovered that, while seemingly easy to create, office documents have significant limitations. This is best illustrated by some common scenarios that compare results between the office software approach and single source publishing.

The limitations described in the scenarios arise from the nature of office and desktop publishing software. Such software describes document components by the formatting characteristics used for the primary, inbuilt display format such as print. To change the display format, it is almost always necessary to manually reformat the documents.

Documents prepared using office or desktop publishing software are called unstructured documents.

Single source publishing uses a different approach based what are usually called structured documents that are designed for reliable, automated publishing to any desired display format.

How does single source publishing work?

Single source publishing works by using software tools to generate all user display formats such as print, Word, PDF and HTML from computer readable structured documents. To set up single source publishing, you have to create structured documents.

Structured documents use a storage format that provides a computer readable description of each component of the documents but does not include the formatting information for a specific display format such as Word, PDF or HTML.

When you write structured documents, the editing software will guide you to insert the markup or tags that are needed to make the document computer readable. These tags are similar to the tagging you may have seen if you have written a HTML document viewed the page source of a HTML document in a web browser but have tag names that are more specific to your documents.

With single source publishing, all the formatting for each display format is applied as the structured document is transformed or rendered to a display format.

Single source publishing also lets you break documents into components that can be shared and assembled into new documents as each display format is generated.

When a structured document is transformed into each display format, the original document is not changed. The generated documents are just display versions that can be replaced each time the documents are updated or stored for archive purposes, if desired.

What is special about structured documents?

Structured documents are tagged to provide a description of document components with their hierarchical and other relationships. This tagging makes it possible for software applications can be given rules about how to process document components to retrieve information or produce specific outputs.

Take this document as an example. To prepare it as a structured document, the document title, each topic, the topic title, each paragraph and additional information such as lists, tables, graphics etc must be identified and consistently tagged. This tagging makes it possible to set up a software application to automatically format those components in multiple display formats such as PDF and HTML.

Structured documents must be tagged in a predictable way to make them suitable for automated processing by computer systems. In particular:

A structured document tagging system lets you ensure that every document produced by any writer will conform to a common model or structure. Then, when you use software tools to generate display formats for your documents, you should get the same, predictable results every time. This is not possible with unstructured documents.

What is the tagging system for structured documents?

The most common markup or tagging system for structured documents is XML (eXtensible Markup Language), a public specification developed by the W3C (World Wide Web Consortium). XML is effective because it is flexible, it is a standard and it is supported by a very large number of software developers and consultants around the world.

XML is not itself a ready-to-use document tagging language. Rather, it is a system for creating specific markup or tagging languages that model specific document types. These languages are defined in a schema or document type definition (DTD).

There are many XML languages for structured documentation that can be used to support single source publishing. Each of these languages has particular features and advantages for certain kinds of documents. A key decision in planning a single source publishing system is to choose the XML language that is best for your needs. Often, it is necessary to customise an existing XML language to so it completely effective.

How are structured documents created?

Structured documents are usually created using dedicated XML authoring software.

Structured documents must follow the rules of the structure model defined by your chosen XML language and defined in the XML schema. Those rules define the component names (elements) and the sequence in which they may be used.

Dedicated XML authoring tools can make it easy for you to insert element tags and to follow the structure rules for your XML language. Many XML authoring tools enforce structure as you write by validating your document against the XML schema and preventing the writer from breaking the structure rules. Using a good XML authoring tool is the key to ensuring that every writer produces documents that are consistent and ready for automated processing to your chosen display formats.

Once writers are familiar with writing structured documents and are no longer concerned about document styling and layout issues, they will find content creation much easier and more enjoyable than using word processing tools. This should be one of the benefits of your single source publishing system.

Can we use our existing software to write structured documents?

No, unless you already create structured documents. The latest versions of Word and Open Office use their own XML languages for documents. Not all XML languages are designed to create structured documents. The XML languages used by office software are very general purpose so that writers can create documents without structure constraints. Those languages do not qualify as structured data models for single source publishing purposes.

Word and Open Office are not really designed to work with structured XML languages.

How are structured documents formatted?

Generally, a separate transformation or rendering process must be set up for each display format. If you want print, PDF and Word display formats, these are usually created using one process. Another process will be used to create HTML.

An important benefit of single source publishing is that you can control exactly how each display format will be presented. Thus, the HTML display may use different styles and have many different features compared to the print. To achieve this, separate rules may be needed to control how each output is generated, even if you use the same basic software tools for each output.

Many publishing tools are available for use with structured XML documents. These tools may use different approaches to creating the output rules and they may have different capabilities in the quality of outputs and features they provide. It is important to select the tool that best meets your needs.

There is a lot of detail involved in creating automatically generated outputs, particularly for print. Setting up the publishing rules to generate display formats for structured documents requires considerable skill and care to make sure that all the details are handled to achieve your display requirements. You will generally be able to save a lot of time and cost by engaging an experienced professional to help select the right tools and set up your publishing system to make sure things “just work”.

What are the parts of a single source publishing system?

The main parts of a single source publishing system include:

Single source publishing systems can be highly modular. The authoring tools used to create structured documents are usually quite separate from the publishing or formatting tools. This provides great flexibility to let you do exactly what you want with your documents. However, it also means that there is some effort to set up the automation for each display format.

Increasingly, specialist software companies are providing off-the-shelf packages with all the listed components integrated to provide rapid development platforms for organisations with particular kinds of documents. This is now making single source publishing accessible to almost any organisation that is involved in professional document or content publishing.

Can I just buy a single source publishing system?

Not quite. There is a growing range of off-the-shelf single source publishing systems based around standard XML schema models and proprietary models for structured documents.

However, each customer's document types and publishing requirements are likely to be different. Off-the-shelf single source publishing systems cannot offer a “one size fits all” single source publishing system that you can just use without some customisation. Off-the-shelf systems must be tailored to the customer's specific needs to provide the flexibility and consistency needed for things to “just work” in day to day production.

Off-the-shelf systems mainly provide a foundation on which customer specific solutions can be developed.

What does it cost to set up a single source publishing system?

Cost can vary widely, depending on the nature of your documentation, the size and complexity of your operations and your specific requirements.

The whole idea of a single source publishing system is to reduce ongoing costs and enable you to improve your service to customers. Setting up a single source publishing system to achieve those benefits usually requires a significant initial investment because of the inherent detail in most publishing processes and the need to change from manual to automated production methods.

The best way to approach the initial investment is to start with a simple business case. Consider the list of problems (What problems can single source publishing solve?) and identify those and any others that apply to your existing system. Then look at the benefits you could achieve from a single source publishing system (What are the benefits of single source publishing?). This analysis will help you define your main goals for a single source publishing system.

Based on your analysis, assess the reduction you expect in ongoing production costs and the business opportunities that could be pursued with a single source publishing system. If a new system can cut real costs and help you to expand your business more cost effectively, you can define the investment that would be realistic for your business.

Should we use specialist consultants to set up a single source publishing system?

Unless you already have in-house developers who understand XML and single source publishing, engaging specialist consultants and developers should save you a lot of time, effort and cost in developing your solution.

The development of structured documentation and single source publishing systems requires a combination of IT and specialist publishing skills covering business analysis, software development, change management, XML technology, structured document modelling, document writing, publishing workflow, print publishing, web publishing and publishing software tools.

A specialist should help you focus your project on your key business objectives and develop a solution that “just works” with much less effort and disruption than if attempted by someone without the right combination of skills.

Can we use our existing documents for single source publishing?

No. Unstructured documents lack the information and consistency needed for reliable automated publishing and must be converted to a structured format.

Moving from unstructured to structured documentation is more than just a change in file format. If you are trying to reduce content duplication and set up a system to share common content in multiple documents, you may also need to revise your content so that documents read correctly with shared components.

For those reasons, the data conversion may involve content revision as well as the format conversion.

How are unstructured documents converted to structured format?

By definition, unstructured documents lack the computer readable description of document components that is essential for structured documents. In some cases, structure can be inferred from styles or other features of unstructured documents. Unfortunately, inferred structure is usually unreliable because of the inconsistency of manually applied formatting and styles within and between unstructured documents. Almost invariably, there is no direct conversion process from unstructured documents to the structured document format.

Conversion of unstructured documents to a structured format almost always involves a mixture of automated processing and human input.

If there is a large collection of documents that follow a consistent pattern, it may be possible to develop an automated process that will do a large amount of the work. Otherwise, most of the conversion work is usually done manually.

How will our work processes change with single source publishing?

This is a critical issue. One of the biggest mistakes some organisations make when planning a single source publishing system is to think that most existing workflow and processes will be retained. The move from unstructured to structured documentation is not just a change in file format like moving from one office application to another.

Some of the important goals of single source publishing are to replace redundant, manual tasks with automated processes wherever possible and to improve the accuracy and consistency of published documents. This means that many parts of your production processes may need to be changed.

When working with unstructured documents, documentation managers need to focus their efforts on content accuracy and formatting in published documents. When working with structured documents, the focus on content accuracy is retained but is separated from document formatting. In a single source publishing system, all formatting is applied automatically by the application.

Automated systems can produce the correct results only if the input documents are absolutely consistent and conform to the rules of your XML structure model. Structure quality is mainly applied by the structured authoring application but it is also necessary to provide overall management of the system to ensure that document writers and editors have the right tools and training.

To ensure that your documents are correctly structured, you will need to learn new skills and work with new production processes. Planning and introducing these changes will be an important part of the development of your single source publishing system.

The benefits of these change will be substantial because so many publishing processes and file movement tasks can be automated in ways you may not have experienced when working with unstructured documents.

How do we maximise the benefits from single source publishing?

The essence of single source publishing is the automation of publishing processes. The more you can standardise and simplify your published outputs, the greater will be the benefits of single source publishing.

Assume you currently produce a range of lengthy report documents each year that you want to publish in print and on your website in searchable HTML. Under manual production systems, it is very likely that each report is distinctly formatted, probably by a desktop publishing consultant.

These documents may look attractive but it is worth considering whether there is really any benefit to your readers in using a different and complex layout for each document. If you try to replicate this variation in an automated publishing environment, the complexity will quickly destroy any benefits from the system.

The object of single source publishing is to avoid the need to manually style new reports so they can be quickly and automatically published in all desired outputs. This provides users with the document formats they need and reduces your production costs.

To achieve these objectives, you should plan to develop just one or a small number of standard layouts for your documents. Perhaps different kinds of reports are for different user communities. In that case, some differences in document layout may be necessary.

If you can simplify, minimise and standardise your document layouts, you will be able to minimise the cost of system development and maintenance and maximise the benefits. Planning this simplification and standardisation is the foundation to an effective single source publishing system. You may also find that those changes improve the accessibility of your content for readers of your publications.

OK, single source publishing sounds good, how do I introduce it in my organisation?

There are usually three groups of people in the organisation who must be convinced to establish a single source publishing system: content writers, document or product managers and senior management.

Content writers need to be reassured that the new system will make their work easier. If writers oppose change, it is very hard, even counter productive, for management to try to introduce a new system. While writers are critical to the success of the overall strategy, they are not usually the group to start with to promote a single source publishing system. Just make sure you include them when planning the system and defining the benefits.

If you are a content writer and believe that single source publishing would be good for your organisation, the place to start is with the managers of your documentation.

Document and product managers have day to day responsibility for delivering documentation to users. They are aware of the limitations of existing services and the costs and frustrations of the existing production and publishing processes. Often, they may not be aware that there is an alternative to using common word processing or desktop publishing tools that are the source of the problem. The first place to start is to help documentation managers be aware that there is another way to approach their document publishing work.

Documentation managers may then consider these questions to decide if a single source publishing system could be worthwhile:

If you are responsible for management of your firm's documentation and you answer “yes” to each of those questions, then you have the foundation for convincing senior management that some resources should be devoted to investigating improvements to your document production and publishing systems.

Don't expect senior management to be instantly convinced or immediately approve a procurement budget. Management will need to understand the problems in financial terms and be satisfied that there is a feasible solution with real benefits. Unless management is already familiar with publishing technologies, they may be reluctant to consider that anything other than using Microsoft Word is necessary. You may need to convince them by explaining the real problems you are encountering and that those problems have real costs for the business.

A useful approach is to prepare a short vision statement or white paper that defines the current problems and attempts to identify the associated costs. The vision statement should then describe an alternative approach (single source publishing) that will overcome the problems and also define the expected benefits.

At this stage, you won't know the level of investment needed to establish a single source publishing system. You are only looking for approval to investigate a solution. You may need to find expert assistance to help define your requirements, describe a realistic solution to your needs and quantify the required investment. Your initial request to management may be for approval to engage a consultant to assist with that process.

When planning your project, consider an incremental approach that minimises the initial investment, disruption and risks. Often, it is much easier to establish a small initial project that you can use to demonstrate the benefits and build on in later stages.

Armed with a solution proposal, you should then be in a position to develop a business case on top of the vision statement prepared earlier. The business case should further quantify the costs of the existing system, the expected benefits and the investment needed to obtain those benefits. It should also address the soundness of the proposed solution and the associated risks. If your business case shows real benefits, it will provide the basis for executive management and the board of directors to approve funding for the project.

Most organisations have competing claims for project funding. Your project may not be approved the first time but if your business case is credible and positive, you will have enhanced your reputation and laid the foundation for acceptance at a later time.