XML in the Publishing Workflow: A Sampling of Success Stories

by Jeff Wood

Mar 2005

Having XML content in some part of the publishing workflow is common these days. In fact, most of the projects we encountered over the past several years centered around helping a publisher move from a print-focused model to one that allows a more content-oriented, less product-centric means of managing and distributing content. Moving XML to an earlier stage of the production cycle is a primary means for many companies to achieve this goal.

There are several reasons for desiring a content-centered approach:

Revenue once dominated by print is starting to balance out, and in some cases being exceeded by, online subscriptions, sales of electronic products, and content licensing arrangements;
Publish-before-print initiatives;
On-demand and custom publishing models that allow both internal editorial staff and customers to pick and choose content from several different "products";
The cost benefit of standardizing on the ever-growing XML-aware editorial tools and production systems;
The ability to use structured markup repositories as a new product development sandbox to repurpose content;
Increased knowledge (and expectations) of editorial staff of XML and related technologies

Many of our more XML-savvy clients are adopting the early XML mantra into their corporate philosophy. The following is a sampling of what some of our clients have achieved by introducing XML in the editorial and production workflows:

Wolters Kluwer Health / Lippincott Williams & Wilkins

The journal production staff members at Wolters Kluwer Health (WKH) are no strangers to XML, or for that matter SGML. Several years ago they deployed a home-grown—and very sophisticated—Word macro package that enabled off-site freelance editors to work with tagged documents in the familiar MS Office environment. During the editorial cycle, the native format of each article was Word, but the final output of the process was valid SGML.

These remote editors had a lot to learn about markup, structured editing, and the specifics of the custom Word interface. The key to their education: a detailed CD-ROM-based training package that would step through each editing task and show the related customization. The CD-ROM served as both tutorial and reference. This was a case in which the investment in computer-based training software was clearly worthwhile, owing to the large and widely spread corps of editors.

An interesting addendum to the WKH case is their choice of an upgrade. Because newer versions of Word have proved incompatible with the macro package, and because there's increasing motivation to migrate to XML in order to further streamline and automate workflow stages, the original Word customizations are being retired. The replacement: a completely new set of customizations built around the schema-based XML-editing capabilities of Word 2003. Keep in mind that Word's advantage over a dedicated XML editor such as XMetaL or Epic is its ubiquity. It's clearly feature-poor in a head-to-head comparison of structured-editing environments. But WKH staff knew they had created a valuable resource in their markup-savvy team of freelance editors. If anyone could handle XML-in-Word, one would assume that they could. That's turning out to be true.

F.A. Davis Company

Philadelphia-based medical publisher F.A. Davis Company saw an opportunity to improve both the revision effort and the reusability of some of its premier reference products—notably Taber's Cyclopedic Medical Dictionary and Davis's Drug Guide for Nurses—by using SGML/XML as the native format as much as possible in the editing process.

Currently there are practical limits to upstream XML use for Taber's. The pool of consultants tends to change over the 4-year revision cycle, so XML training as well as software installations would likely become a recurring expense. And the consultants aren't freelance editors: they're full-time medical professionals, often with little time to dedicate to software training. As a result revisions are usually circulated via email or paper, and then later transferred to the XML repository by internal staff.

In contrast, the Drug Guide has two primary authors and a few other long-established content reviewers. They were willing to try composing and maintaining drug-reference content in a native-XML editor (Epic in this case). The result has been a smashing success. "By putting XML in the hands of content creators, we've substantially improved accuracy and timeliness, and we've reduced the editing burden on internal staff," says Ralph Zickgraf, electronic publishing manager at F.A. Davis.

There's hope that new generations of XML-editing software will reduce both training time and software deployment costs to the point that Taber's, and many other publications, can enjoy those same benefits.

CQ Press

CQ Press, a political science book publisher in Washington D.C., created several online products based on years of previously published material. For that effort, CQ Press sent older books to conversion houses to convert the content to XML. "For the older back-list books we didn't have many other economical options except to send the books out for conversion. When we first started adding front-list books to the online products we initially kept that same model - print the book and then send the book or Quark files to a conversion house to get XML," says Jerry Orvedahl, editorial analyst for CQ Press. "Now we are in a position to pursue better and cheaper ways to get the XML."

Realizing a need for a more efficient process for newer books, CQ Press worked with their composition vendor to do what they call "front-end XML," that is, to have the content converted into XML before composition, use the XML as a base during the composition process, and have the XML immediately available when the book is finished. "Front-end xml is about one-third less expensive than back-end conversion, so it obviously made a lot of sense," says Paul Pressau, production manager at CQ Press, "It is also ready to be processed to online products as soon as bluelines clear, which saves some time in the process."

However, the front-end versus back-end conversion decision is made on a book-by-book basis as there are some limitations to consider. CQ Press wrote detailed specifications for converting old content to ensure the XML structure was exactly what they wanted for their online processing. "With front-end XML you sometimes can get more ambiguous markup as we don't have the necessary information to write detailed specs before the book is fully laid out" says Orvedahl. "Front-end conversion works great for simpler books, new editions, or books that are part of a series, but there are some limitations if the book is new or highly designed."