A few months ago, I was deployed to the Joint Field Office (JFO) in Baton Rouge, LA before, during, and after Hurricane Gustav (September, 2008). I was there to help edit and update FEMA’s Hurricane Response Plan.

During the course of that time, my colleagues and I compiled a comprehensive timeline of activities that each Emergency Support Function (ESF) must accomplish as the clock ticks down to hurricane landfall. As a necessary part of completing the plan, we found ourselves working with stakeholders by detaching, distributing, and re-attaching parts of the timeline for the purpose of getting their input and buy-in for the final edition.

It sounds fairly straightforward but in practice version control can quickly spiral into nightmare territory. My associates and I talked about compiling all the “time hacks” into a centralized database. Then we could control each published version of the plan using database controls instead of word processing and/or spreadsheet controls.

Unfortunately, with the deadlines we were working under, we didn’t really have the time to implement what would have amounted to a major paradigm shift into the JFO’s workflow pattern.

Now flash-forward to April, 2009. I came across a presentation by BookNet Canada CEO Michael Tamblyn, called 6 Projects That Could Change Publishing for the Better. Number two on his list was — and I quote — “An XML publishing workflow that doesn’t suck.”

Allow me to digress briefly.

XML stands for eXtensible Markup Language. It is somewhat similar to Hypertext Transfer Protocol (HTML) the markup language that makes webpages visible in a browser. Whereas HTML focuses on how data looks, XML focuses on what data is. XML was also designed to transport and store data, which makes it very attractive for sharing via the Internet. What this means is that XML can be used to share information between different kinds of computers, different operating systems, different applications, and different organizations without needing to pass through many layers of conversion.

Which brings me back to the hurricane plan. Because we needed to send and receive multiple pieces and multiple versions of some (or all) of the plan to a far-flung group of stakeholders — while on deadline — XML would seem to be a natural solution.

In simplified terms, here’s how it would work.

First, we’d create a text version of the hurricane plan and store it on a server. Then, because XML is extensible, We’d create our own XML tags to mark up the document describing which part of the text is about ESFs, which part of the text is about time-hacks, and which parts of the text is about specific activities to be undertaken. Using other XML-friendly tools (many of which are open source and free) we could extract those parts of the plan and notify the stakeholder that their review is required.

Using a simple web browser, the stakeholder can transport the document to their location for their review. The stakeholders will find that editing the plan is easy because it is simple text. Once editing is complete, the stakeholder would store the finished document on the same server, notifying the editors of its completion. The editors can then pull down the document, re-compile it and format it using other XML-friendly tools. Storing, describing, formatting and transporting made easy.

In his talk, Tamblyn showed a couple of “before-after” slides. In one, he indicaties how current publishing is a kind of hodgepodge of standards and software/hardware platforms. In the other, he shows how XML can be instrumental in streamlining the publishing workflow.

This resonated with me. I’ve worked in corporate libraries, I’ve been on document teams and I know from experience that publishing is a core part of any consulting business. Clearly, XML is not a panacea. After all, Tamblyn’s point was not simply to implement it — that’s easy. It has to be implemented in a comprehensive, cost-effective way so that (internally and externally) all corporate stakeholders and clients would benefit.

Tamblyn:

From the perfect XML workflow we really want two things: we want markup that denotes content (which is what the author and editor are concerned with) and we also want markup that denotes structure (which is what the designer and production manager are concerned with). The key that unlocks economies of scale is XML: it is the over-arching standard that allows all parties to easily share, with each other, what they know and want.

That is easier said than done. But major publishers (O’Reilly is one) are participating in an industry wide project called StartWithXML to understand spread the knowledge publishers need to move forward with XML.

Tamblyn again:

Whether we’re talking about editor-friendly XML, or less torturous production workflows, the organization that takes this on and cracks the code is not only going to be a hero but is probably going to make out like a bandit because everyone is struggling with this now.