Top eight signs it’s time to move to XML

How do you know it’s time to move to XML? Consult our handy list of indicators.

Versione italiana (Alessandro Stazi, January 28, 2016)

This list is in rough order from problems to opportunities. That is, the first few items describe situations where the status quo is problematic. Later in the list, you’ll see items that are more focused on improving the quality of the information you are delivering.

1. Overtaxed system

Your current system (tools and workflow) worked well in the past, but now it’s overburdened. Tasks take too long because you don’t have enough software licenses, or enough people, or too many manual steps in your workflow.

XML-based content is not the only way to solve this problem, but you can use an XML-based system to improve the efficiency of your operation:

• XML content files have a smaller footprint than the equivalent binary files (because formatting is not stored in each XML file but instead centralized in the publishing layer).
• You can use a variety of editors with XML files. Software developers might use their favorite programming text editors. Full-time content creators likely prefer an XML authoring tool. Getting software is less of a problem because not everyone needs a (potentially expensive) authoring tool.
• Content creators spend a shocking amount of time on formatting tasks—up to 50% of their time. XML-based publishing replaces the ongoing formatting tasks with a one-time effort to create stylesheets.

2. File management problems

Your days are filled with administrative problems, such as the following:

• Trying to manage increasingly fragile authoring tools in which formatting spontaneously combusts when you so much as breathe near your computer. (I’m looking at you, Microsoft Word.)
• Searching through shared network drives, local file storage, and random archives for a specific file and, most important, the latest version of that file.

File administration is overhead at its worst.

The authoring tool problems are addressed by the simplicity of XML files—formatting is applied later in the process, so it cannot muck up your source files. (Note: Some software offers the option of saving to “MySoftware XML” format. In most cases, that XML does include formatting information, which destroys much of the value of an XML-based approach.)

The file search problem is a source and version control problem. The best solution for content is a component content management system (CCMS), in which you can track and manage the files. If, however, you cannot justify a CCMS for your organization, consider using a software source control system. Because XML files are text, you can use common system such as Git or Subversion to manage your files. This approach doesn’t give you all the features of a CCMS, but the price is appealing. It’s also possible to manage binary files in a source control system, but you will experience additional limitations. (For example, you cannot compare file versions using source control system.)

3. Rising translation and localization demands

Your “creative” workarounds to system limitations were acceptable when you only translated a few minor items into Canadian French, but now the company delivers in a dozen languages (with more expected next year), and correcting these problems in every language is getting expensive and time-consuming.

Localization is by far the most common factor that drives organizations into XML. The cost savings from automated formatting across even a few language variants are compelling. Furthermore, because most organizations use outside vendors for translation, it’s quite easy to quantify the cost of translation—you can just look at the vendor’s invoices.

4. Complex conditions

Most unstructured authoring tools offer a way to label information as belonging to a specific content variant and produce two or more versions of a document from a single file. For example, by flagging test answers as “Instructor,” a teacher could generate both a test and an instructor’s answer key from a single file.

In software documentation, a requirement to label information as belonging to a high-end “professional” version as opposed to the baseline product is common. Authors can then create documents for the baseline version and for the superset professional version from a single source.

With more complex variants, however, the basic flagging and filtering is insufficient. Consider, for example, a product that has the following variants:

• U.S. product and European product with different safety requirements
• Product used in different environments, like factories, mines, and retail establishments
• Optional accessories, which change the way the product works
• Product components are shared across different products with small changes

In this example, you would need to create the following types of filters and have the ability to generate combinations of filters:

• Regulatory environment
• Operating environment
• Accessory
• Product (to identify variance in shared components)

In XML, you can use metadata to create these flags and filter on various combinations.

5. No off-the-shelf solution meets your requirements

If your output requirements are exotic, it’s quite likely that no authoring/publishing tool will give you the delivery format you need out of the box. For example, you might need to deliver warning messages in a format that the product software can consume. Or you need information in strings that are compatible with web applications, perhaps in PHP or Python. JSON is increasingly required for data exchange.

If you are faced with building a pipeline to deliver an unusual format, starting from XML will be easier and less expensive than starting from any proprietary system.

6. More part-time content creators

In many XML environments, the full-time content staff is augmented with part-time content creators, often subject matter experts, who contribute information. This helps alleviate the shortage of full-time content people. Another strategy is to use XML to open up collaboration across departments. For example, tech comm and training departments can share the load of writing procedural information. Interchange via XML saves huge amounts of copying, pasting, and reformatting time.

Part-time content creators have a different perspective on authoring than full-timers. Their tolerance for learning curves and interface “challenges” generally decreases with the following factors:

• Level of expertise. Subject-matter experts want to get in, write what they need to, and get out.
• Level of compensation. Put too many obstacles in front of a volunteer, and your volunteer will simply drop out.
• Scarcity of knowledge. The fewer people understand the topic, the more likely that your part-time content creators resist any workflow changes.

The solution is to focus on WIIFM (“What’s in it for me?”). If the content creator is accustomed to managing content in complex spreadsheets with extensive, time-consuming copy and paste, an XML system with bulletproof versioning and reuse will be quite popular.

7. Metadata

Text is no longer just text. You need the ability to provide supplemental data about text components. For example, you need to be able to identify the abstract section for each magazine article. Or you want to create a link from a book review to a site where you can purchase the book. Conveniently, a book’s ISBN provides the unique identifier you need, but you don’t want to display the ISBN in the review itself, so you need metadata.

Most unstructured tools let you specify metadata for a document (often, in something like “Document Properties”). XML lets you assign metadata to any document or document component, so you can include more detailed background information. (And you can use that metadata to filter the output results.)

8. Connectivity requirements

In some contexts, your text connects to other systems. These might include the following:

• For a repair procedure, a link from a part to your company’s parts inventory, so that you can see whether the part is available and order it if necessary.
• For software documentation, the ability to embed error messages and UI strings both in content and in the software itself.
• For medical content, the ability to accept information from medical devices and change the information displayed accordingly. (For example, a high blood pressure reading might result in a warning being displayed in your medical device instructions.)

Does your organization show signs of needing XML? Can you justify the investment? Try our XML business case calculator for an instant assessment of your potential return on investment.