Challenges: Some Ugly Truths
The challenges of building—and living with—an XML workflow are clear enough. The return on investment is a long-term proposition.
Regardless of the benefits XML may provide, the starting reality is that it represents a very different way of doing things than the one we are familiar with. The Word Processing and Desktop Publishing paradigm, based on the promise of onscreen, WYSIWYG layout, is so dominant as to be practically inescapable. It has proven really hard to get from here to there, no matter how attractive XML might be on paper.
A considerable amount of organizational effort and labour must be expended up front in order to realize the benefits. This is why XML is often referred to as an “investment”: you sink a bunch of time and money up front, and realize the benefits—greater flexibility, multiple output options, searching and indexing, and general futureproofing—later, over the long haul. It is not a short-term return proposition.
And, of course, the returns you are able to realize from your XML investment are commensurate with what you put in up front: fine-grained, semantically rich tagging is going to give you more potential for searchability and recombination than a looser, more general-purpose approach, but it sure costs more. For instance, the Text Encoding Initiative (TEI) is the grand example of pouring enormous amounts of energy into the up-front tagging, with a very open-ended set of possibilities down the line. TEI helpfully defines a level to which most of us do not have to aspire.[5]
But understanding this on a theoretical level is only part of the challenge. There are many practical issues that must be addressed. Software and labour are two of the most critical. How do you get the content into XML in the first place? Unfortunately, despite two decades of people doing SGML and XML, this remains an ugly question.
Gary Edwards on 08 Jun 11Roger Black is a publication designer, and Filipe Fortes was the project manager for Microsoft's Windows Presentation Foundation - Silverlight project. Today he specializes in dynamic layout algorithms written in Open Web JavaScript. Roger is a reknown publication designer, and describes here the genesis behind TreeSaver. Fascinating story certain to become a key explanation of how digital media ran away with the print publishing industry. I'm wondering what kind of authoring tools will evolve that can publish directly into the TS JavaScript templates? My first inclination would be to adapt OOo Impress. It has an outline view, a notes editing capability, and provides a decent visual canvas. The problem is that it's locked into "slides". Can Impress be unlocked and flowing? That might work. excerpt: when Microsoft put together a dynamic page layout for The New York Times Reader, did they know that it was the future? It certainly wasn't the immediate present, since they couldn't pry the WPF visual layer off of Windows, leaving it a single-OS solution. (The Times' Reader later was taken up by Adobe, which at least got it to work on both Mac and PC.) Filipe Fortes, PM on the MS news client project, knew. I'd met him when the group invited me out to Redmond to help design the first templates for the Times. Later I saw him at the 2007 Mix conference in Vegas, and I asked him how to make the dynamic page size idea work multi-platform. He said, "We could do it in HTML."
