The Bumpy Promise of XML
The language is flexible, but getting there is harder than it might seem.
Converting content into XML— the language that allows any platform to recognize a particular piece of content and provides the ultimate in content flexibility—is initially not an automatic, invisible process. It’s another step in the production workflow and publishers planning to share their content across multiple platforms need to understand that a new process will need to be established, and new software will need to be purchased.
XML can be automated, but getting there does require some manual labor—think of XML as the last step before sharing content with your CMS. But, fully exploiting the technology requires three steps inherent in building out a publishing technology platform: capital expenditures in hardware and software, building bridges and patches to integrate yet another system, and a substantial workflow reconfiguration.
The Print-to-Web Pathway
For many publishers, content still originates in a print-centric world, meaning it starts with the magazine and then makes its way to the Web. “We still produce magazines and newsletters that originate on the print side and we need to get that to other outlets as quickly as possible,” says Rob Paciorek, chief technical officer at b-to-b publisher Access Intelligence.
For Paciorek, the ability to take content and reuse it across platforms was an undeniable benefit. Two years ago he purchased the K4 system, which has an XML export feature, but this investment was only the start. “It required hardware, software and implementation. It was a pretty sizeable investment. But it was important for us because all of the old processes we were using to convert some of the print content to Web-friendly or third-party content were on the verge of breaking,” he says.
But, like most publishers, there’s one content management system for print and another for Web and patches need to be created to bridge the two. Further, in order for content to be converted into XML, stylesheets need to be developed that identify which elements of a piece of content must be tagged, or styled, as XML. But for many smaller publishers, investment in a robust print-side CMS and the subsequent process of producing well-formed XML is a big bullet to bite. “I think if you’re at a certain threshold of publications it might make sense to invest in this because it’s not off-the-shelf enough that I know of—you can’t just hit a button in InDesign and have it magically go into XML and then have your Web site slurp it in,” says David Newcorn, vice president, e-media at Summit Publishing Company. “So there are two struggles, getting the data out of Quark or InDesign and then getting it into the Web site.”
Even Paciorek admits to a “bumpy” road to well-formed XML. “There have been bumps because of the difficulty of transforming the XML correctly. When we export stories from K4 into XML, unless you have everything tagged properly, like author name, a subject name, a subhead, company names, and so on, it gets complicated and you might miss a few things. It’s the complexity of tagging and trying to automate something that’s not always the same.”