Publishers have a tendency to idealize technology. Like Ann-Marie Metten’s Excel Pivot Tables, XML is an essential implement, according to Kathleen Fraser, but ultimately success is still in the hands of publishers. In Mary Schendlinger’s words, “The key here is the same as for other technological advances for editors over the last couple of decades: use them as helpful tools; do not expect automation.” Fraser’s examination of XML delves into pragmatics and terminology for the XML novice, and, more importantly, how publishers can use XML to facilitate their workflows.
Kathleen Fraser is a dedicated editor, agile publishing enthusiast, and enveloper of mountains. A bird of many feathers, she loves fine literature, good grammar, sneakily progressive pop culture, tofu brownies, and handknit sweaters.
keywords: XML, unicorn, tags, HTML, automated workflow, semantic content, stylesheets, accessibility, format
Roger Sperberg asks, “Why do publishers need XML?” and concludes that an understanding and exploitation of markup will lead to “structural elements … in e-books that will make them more valuable than p-books” (Sperberg 2010). This rhetoric doesn’t sound much different (if a little less hyperbolic) from the predictions that the Apple tablet would be a unicorn, a time machine or simply the future of literature (Abell 2009, Stone and Clifford 2010, and Akst 2010). Although a device like the iPad is unlikely to “undo mistakes of the past” or “blow up the book business as we know it” (Stone and Clifford 2010 and Akst 2009, respectively), strategies that incorporate XML are capable of changing the game. XML may not be a unicorn but, to the people pulling the plough themselves, it does look like a workhorse.
So what is XML? eXtensible Markup Language is, according to Kevin Goldberg, “a specification for storing information. It is also a specification for describing the structure of that information” (2009, xii). Like HTML or other markup languages, it allows users to describe information in a way that is legible by computers or (trained) humans. Unlike HTML, XML and its ilk have no set tags; rather, the organizational system is designed and customized by users. While this makes the language very flexible, it means users have to agree on a set of tags (or schema) (Goldberg 2009, 114). XML tags can be used to mark formatting, by describing text as bold, for example. More usefully, however, it can describe the semantic content of text, by describing it as a heading, body paragraph, sidebar, biography, test question—whatever designation is most useful. A document marked up for content can be used, in combination with stylesheets that dictate formatting rules for specific types of content, in a number of formats with relative ease.
The utility of XML is important for publishers because, in the words of Michael Tamblyn, it allows reusability, segmenting, format conversion, and portability of files (Tamblyn 2009). Similarly, Jean Kaplansky, in her article “XML and the many facets of publishing,” lists a number of benefits to an XML workflow applicable to particular realms of publishing (Kaplansky 2010). First, XML can minimize intervention: XML markup allows consistent processing and a partially automated workflow. Once content has been tagged, it requires less intervention from editors, designers, and compositors to reorganize, reformat, or reuse. Second, structural markup can help maximize accessibility. In educational publishing (urgently) and all other fields (ideally), accessibility of texts to persons with disabilities is crucial. Tagged content and segmenting (i.e., clearly marked structural elements) make it possible to tie text to audio and to navigate smoothly from one section to another with an accessible interface. Finally, an XML workflow paves the way for innovation: it allows publishers to experiment with format and novel uses of content. Kaplansky gives examples of educational publishers creating tests with the capacity to judge and adapt to responses; book content repackaged as merchandise like playing cards or calendars; and content marketed to multiple audiences simultaneously (e.g., student and teacher editions of a text, or different editions for different age groups).
Kaplansky writes from an educational publishing slant, but these opportunities should be priorities for all publishers. Accessibility for persons with disabilities is a necessity in every case. Canadian publishers, already on shaky footing after a global recession, are losing arts funding; the efficiency of an automated workflow can free up limited resources, allowing these publishers to take on more projects. Publishers are very familiar with content repurposing but unfamiliar with new platforms, and experimenting with format takes on new importance in an age of iPhone apps, social networking sites, and multimedia endeavours.
XML is already a staple for a number of businesses (O’Reilly 2008; Klopotek 2010; Wiley; Tamblyn 2009). As Sperberg points out, most of these are large educational or scientific, technical and medical (STM) publishers, as such companies can more easily afford to invest in technology and professional development and are also more apt to repurpose content than trade publishers. Initial resource investment can be higher in an XML-based project, but for most publishers that repurpose content (i.e., publishers that produce at least hardcover and paperback editions of the same book), it is a lower resource investment overall. However, many independent companies are working with small margins and limited cashflow, and for these companies, any transition that requires upfront expenditure or increased demands on staff is impossible to make.
As it stands, these demands on staff are significant. XML can be used most efficiently when text is marked up for semantic content (the O’Reilly model), which means authors and editors need to be trained in the markup language and must take on more work per project. Current XML editing tools, like oXygen, are complex and lack the intuitive quality that makes technologies successful (Tamblyn 2009). Wiley Publishing’s model, using custom styles in traditional word-processing software and converting these to XML with custom software, requires a huge initial investment of resources in terms of expensive software and staff training, so this option is out of reach for most companies. Free, open-source programs are a good option for these publishers, but such programs lack in user friendliness even as they excel in utility and accessibility.
These limitations notwithstanding, XML glimmers like a mythical beast to some. Consider the Agile Publishing Model discussed by the owners of the publishing company Pragmatic Programmers, Dave Thomas and Andrew Hunt, at the 2010 Tools of Change conference. The Agile Manifesto, co-created by Thomas and Hunt as a software development model, privileges individuals (employees and customers both) over traditional business strategies, as well as innovation over routine (Beck et al. 2001). Companies that practise agile strategies are, therefore, faster to adapt to changing technology and more inclined to take risks. Pragmatic Programmers, is hosted entirely in the Cloud, and authors submit manuscripts already tagged with XML (Rankin 2010). Thomas and Hunt boast not only about the portability of their business but also about their low overheads and high royalties—made possible, in large part, by the efficiency of XML and an automated workflow. The company is able to prioritize authors and customers as a result: more resources can be devoted to royalties and customer service. The company is also on the bleeding edge of developing technology. However, the nature of their books (largely manuals about software development or agile strategies) means that the authors and employees are already competent with XML and that the layout and design are formulaic; as one blog pointed out, Pragmatic Programmers is lucky to be “at the nexus of Awesome and Automation” (Pragmatic Bookshelf 2010 and Rankin 2010). Few other publishers find themselves at the same intersection.
One reason Pragmatic Programmers is able to cut costs and increase royalties is the extra work taken on by the authors. This option is unavailable to most publishers not only because most authors are not equipped to use XML, but also because the language is sometimes unique to the user or organization. Authors would need to be trained in both the language and the company’s tag system or chosen schema; it is difficult to imagine Random House or even D&M Publishers undertaking this. O’Reilly and Wiley have it right: semantic markup must fall to in-house editors.
So what do editors need from XML? To begin with, any training required must be fast and cheap. Most publishers will make the transition only if investment cost is low: the software must be cheap or free, and training time short. More than this, though, Tamblyn jokes that editors are still resistant to moving from pen and paper to the screen (Tamblyn 2009). A successful user interface will incorporate the aspects of a pen-and-paper editing experience that are currently lacking onscreen. These might include the ability to judge progress through a document and to pull up and compare any desired pages, the portability of a paper manuscript, and the satisfying sensation of striking through an errant adverb with one’s sharpest pencil. In addition, many editors find errors in print they miss onscreen (Hart 2000); whether this is an effect of psychology or image clarity, it merits consideration. This is a tall order: software with the intuitive navigation and inherently tactile benefits of pen and paper but the utility and extension of XML. Perhaps this combination is the true unicorn of publishing. Plain old XML is nothing magical—just a trusty steed.
References
Abell, John C. 2009. Apple tablet could cement Jobs’ legacy. CNN.com. http://edition.cnn.com/2009/TECH/11/09/apple.tablet.jobs/index.html (accessed April 8, 2010).
Akst, Daniel. 2010. Apple’s tablet and the future of literature. Los Angeles Times. http://articles.latimes.com/2010/jan/24/opinion/la-oe-akst24-2010jan24 (accessed April 8, 2010).
Beck, Kent, et al. 2001. Manifesto for agile software development. http://agilemanifesto.org/ (accessed April 8, 2010).
Goldberg, Kevin. 2009. XML: Visual quickstart guide, 2nd ed. Berkeley: Peachpit Press, 2009.
Hart, Geoff. 2000. Effective onscreen editing. http://www.geoff-hart.com/resources/2000/onscreen1.htm (accessed April 8, 2010).
Kaplansky, Jean. 2010. XML and the many facets of publishing: Why publishers DO need XML. TeleRead. http://www.teleread.org/2010/01/16/xml-and-the-many-facets-of-publishing-why-publishers-do-need-xml/ (accessed April 8, 2010).
Klopotek North America. 2010. http://www.klopotek.de/enindex.htm (accessed April 8, 2010).
O’Reilly XML Blog. 2008. http://www.oreillynet.com/xml/blog/ (accessed April 8, 2010).
The Pragmatic Bookshelf. 2010. http://www.pragprog.com/titles (accessed April 8, 2010).
Rankin, Mike. 2010. Tools of Change round-up day 3. InDesign Secrets. http://indesignsecrets.com/tools-of-change-round-up-day-3.php (accessed April 8, 2010).
Sperberg, Roger. 2000. Why do publishers need XML? TeleRead. http://www.teleread.org/2010/01/15/why-do-publishers-need-xml/ (accessed April 8, 2010).
Stone, Brad and Stephanie Clifford. 2010. With Apple tablet, print media hope for a payday. New York Times. http://www.nytimes.com/2010/01/26/technology/26apple.html (accessed April 8, 2010).
Tamblyn, Michael. 2009. An XML publishing workflow that doesn’t suck. BookNet Canada Tech Forum 2009. http://www.slideshare.net/booknetcanada/bnctechforummichaeltamblyn (accessed April 8, 2010).
Wiley Publishing. 2010. http://ca.wiley.com/WileyCDA/ (accessed April 8, 2010).
XML: More Like a Unicorn than the iPad, But Still Not Really a Unicorn by Kathleen Fraser is licensed under a Creative Commons Attribution-Noncommercial 2.5 Canada License.
Whaaaat? If XML’s not a unicorn, is it also not the centre of the universe? My new worldview is shattered!
Seriously though, I agree with you, Kathleen. XML is a valuable tool – but it can only be a valuable tool when surrounded by proper applications, knowledgeable and trained editor/taggers, and intuitive software. After all, XML doesn’t, in and itself, actually do anything; it’s applications that can use XML to do things. So maybe it’s time for everyone to stop preaching about the salvation that XML (or the iPad, or any other technological tool) is going to bring, and start figuring out how this process is going to work in different sectors of publishing. Because surely the O’Reilly or Wiley models aren’t going to work for every kind of publisher.
I was very interested to read your point about how, in most cases, semantic markup needs to be done by in-house editors. I’ve had an unresolved issue in my mind about getting authors to write in XML themselves, and you figured it out for me when you said that authors would need to know both the language and the company’s tag system. It does seem unrealistic to me to ask authors to learn a complicated, company-specific language. But maybe that’s short-sighted of me… many authors a few generations ago didn’t even dream of typing their own manuscripts. Maybe in the future publishers will provide a XML style guide to authors as a part of their submission guidelines. It’s possible! But I still have trouble imagining it and think that something more like what you describe – what editors need to use XML (however elusive) – is the ideal scenario.
I’m very interested to learn more about how XML can be used to increase accessibility – I haven’t quite figured out what the connection is. But I wonder if there could be funding out there somewhere for that – making texts of all kinds more accessible – and whether smaller publishers that might not otherwise have the resources to start working with XML could access special funding to get into the XML game. Any idea if something like that might be available?
Thanks for an excellent read, Kathleen!
Thanks for the very thoughtful feedback on my paper. The accessibility thing is kind of neat: if you have semantic tags in your document, people using programs to read text aloud can navigate the document more easily, especially through voice commands (like “jump to the next chapter” or “next paragraph” or “next heading” or “read the corresponding figure/footnote/caption,” rather than having an undifferentiated block of text you can only move through in a linear way). The funding idea you bring up is really good, and I hadn’t thought of that! Maybe something to tackle in policy class, too.
Thanks again for the great comments.
This is a really nice treatment of XML in book publishing contexts, because you’ve taken the necessary step of going beyond the technical level and pointed out that what book publishers really need is the flexibility that XML promises within an editorial and production environment that allows editors (and designers, I might add) to do what they do best. We are not about to replace one with the other, nor will we subsume the editorial process to one of tagging content.
I, for one, welcome our new Unicorn: an XML-based publishing system that presents itself as a convivial tool to the kind of professional practice that editors and designers embody after many, many generations of books and book culture. Truly a worthy beast to mythologize! Much moreso than a tablet.
Great paper, Kathleen. Such a clear, succinct description of what XML is and does, and a good overview of questions for editors. Some comments for your consideration:
“XML markup allows consistent processing and automated workflow. Once content has been tagged, it requires little to no intervention from editors, designers and compositors to reorganize, reformat or reuse.” – I’ve never used XML directly, but whenever I hear or read the A-word (“automated”), a red flag goes up. Nothing else in editorial or design software requires “little to no intervention.” Later, for example, you mention that the interfaces, even open-source ones, are not intuitive. More on this in a minute…
“Canadian publishers, already on shaky footing after a global recession, are losing arts funding; the efficiency of an automated workflow frees up limited resources, allowing these publishers to take on more projects.” – We have heard this many, many times before, starting in the 1980s with Wordstar on the old KayPro. As you say in the next paras, only larger houses can afford to buy & deploy the software, and it takes a hefty investment of time to get things running. And no workflow is automated.
Markup transition, on the other hand, ought to be swift – editors have been working with markup of some kind (ascii codes and “styles” for word-processing and page composition programs, and html for web) for 20 years that I know about.
“Semantic markup must fall to in-house editors.” So true. For most books, the author is not even the best indexer, andin this I include authors who are quite tech-savvy. These “meta-tasks” are specialized intellectual/business ones, not technological ones. Always were, but even more so now, when the markup person ought to be thinking not only of content per se, but of its re-use in many media as well as the SEO implications of any headings and taggings.
Requirement for “an interface that requires little to no training” – What is the evidence for this? As mentioned above, I don’t know any editors who haven’t developed a strong conceptual grasp of markup in one form or another. This seems the least of the worries – a much easier transition than, say, from ascii word-processing to (shudder) MS Word.
“Tamblyn jokes that editors are still resistant to moving from pen and paper to the screen” – Again, evidence for this? Maybe it’s true, but sometimes when a few high-profile North American trade editors make this claim, we get the idea that they speak for all editors.
“A successful user interface will incorporate the aspects of a pen-and-paper editing experience currently lacking onscreen.” In this area the software may be a worse culprit than the editor. My understanding is that with tablet technology, we are just now starting to be able to mark corrections on a PDF proof in a way that works for designers – i.e. hand-thrown marks on a composed page. The method we have endured for the last few years – sticky-note-type functions in PDFs – is not only laborious & time-consuming for editors, but also conducive to designer error.
Paper vs screen proofing: “whether this is an effect of psychology or image clarity, it merits consideration.” The other possibility is that proofers simply are not used to screen proofing yet. Time will tell. We’re all getting better at it. It must also be said that certain onscreen functions, such as search and spell-check, are super handy aids to proofing (though never never never to be relied on exclusively).
It is important to note that XML is attractive to editors, just as computer memory was in the 1980s, because it saves boring, repetitive work. The key here is the same as for other technological advances for editors over the last couple of decades: use them as helpful tools; do not expect automation. I don’t know how many gigabytes the regular human brain has, to say nothing of the human editorial brain that remembers every negotiation on punctuation and wording with the author, and every marketing nuance worked out with the sales & promo people, but it’s a heck of a lot more than any computer. The same goes for design. These are not inherently automatable activities because they involve as much art (customized attention to tone, flow, music, etc.) as science. In my experience, it is not new technology that editors resist, but the claims of new technology: Just click the button and … presto! a grammatically correct passage, a beautiful page, an accurate index, a cliché-free catalogue blurb. As if this were the essence of editing!
Editors too love the image of the unicorn, but (to invoke one of your metaphors) we know the difference between that and a plow that runs on human energy.
Tiny thing: you’ve got an extra “s” in eXtensible.
Well done! Thanks again.
This was an interesting synthesis of ideas about XML workflows. Please forgive my very low-level comments:
Your introduction to XML suggests that XML has “no set tags”, “unlike HTML.” While that’s technically true, I think it’s probably worth pointing out very early on that the schema of XML that is most important to publishers, XHTML, is simply the way of expressing HTML (the web) according to the rules of XML. On top of that, I think it may be appropriate to introduce that bit of vocab, schema, very early on. “XML and its ilk have no set tags; rather the organizational system is designed and customized by users. XML tags can be used to mark formatting…” might become something describing XML as infinitely flexible, but only useable if many parties agree on a shared structure. The schema is the mechanism for describing the structure of some XML document and different schemas would allow a web page (XHTML) or a recipe, or a Word document’s formatting (bold, italic) to be shared between computers.
It may also be valuable to point out that while XML may see widespread use for representing _data_, the highest value _for publishers_ comes when XML is used to “describe the semantic content of text.” On that note, I’ve found that “semantic” is often opaque to many folks, so you may want to discuss the difference between the “display and the meaning” of the text element (or some synonyms).
It’s probably more accurate to describe this as “transformed” rather than “used”: “content can be used, in combination with stylesheets…, in a number of formats.”
Will your intended audience understand the meaning of these technical-/buzz-words? “This utility is important.., it allows reusability, segmenting, format conversion and portability of files.” It’s probably also worth explicitly restating exactly which utility you’re describing.
Your benefits, as described by Jean Kaplansky, are too strongly worded. “XML markup” _may_ “allow consistent processing and automated workflow,” but I would absolutely not agree that “Once content has been tagged, it requires little to no intervention from editors, designers and compositors to reorganize, reformat or reuse.” There are certainly publishers and imprints where this may be the case, but I do not believe they represent the majority of titles or houses.
What do you mean by “segmenting” in “Tagged content and segmenting make it possible to tie text to audio”? Clear structure of sections/headings?
As above, “Finally, an XML workflow paves the way for innovation: it allows publishers to experiment with format and novel uses of content.” feels a little strong. It’s certainly true that XML-centric workflows can enable publishers to experiment more cheaply, but I’d be careful to not suggest that playing-card repackaging comes absolutely free via XML.
Would it be appropriate to point out that building an “automated workflow” will require real commitment (harder, in many cases) and investment before it “allow[s] these publishers to take on more projects”?
I think it’s also worth pointing out that these “large STM and educational publishers” that “are also more apt to repurpose content than trade publishers” have been experimenting with XML _much_ longer than other parts of publishing and also that they potentially benefit more from the rigid structure of many XML-centric workflows because of their consistent, reliably-structured content. That’s not to say that a novel (fairly consistent, reliably-structured content) couldn’t benefit from the same…
…it’s probably more accurate to describe oXygen (which should be linked) as an XML editing tool rather than an “interface,” and to explicitly compare it to Word, which may represent the “intuitive quality” you’re referring to.
(this is a strong paragraph) Thomas and Hunt were part of the group that developed The Agile Manifesto, so it’s probably worth explicitly mentioning that and that it was initially developed as a way to improve software projects. It may be worth mentioning that their contract itself requires “authors submit manuscripts already tagged with XML”
While the Prags impose “extra work taken on by the authors,” both the Prags and O’Reilly do this by presenting the _benefits_ to this approach. O’Reilly offers on-demand, print-quality PDFs to any author writing in DocBook XML from the moment the *very first* word is put into the manuscripts. The Prags offer similar benefits, which prove to be very compelling for their (limited) authoring pool.
I don’t believe the following is accurate: “but also because the language is unique to each user or organization. Authors would need to be trained in both the language and the company’s tag system.” While the Prags have decided to design their own schema, O’Reilly, Penguin, and many others publishers all use openly standardized schemas like DocBook (http://wiki.docbook.org/topic/WhoUsesDocBook), DITA, TEI, or others, to ensure that this is not the case. The benefit of using a public, open, shared schema like DocBook or DITA is that publishers do not have to invent ePub, HTML, or PDF transformations from scratch, but can benefit from the extensive open source software that exists for these communities….
…Is it realistic to think an XML-centric workflow requires “an interface that requires little to no training”? Did these publishing professionals not spend a tremendous amount of time learning all of Word’s peculiarities?
I agree that “many editors find errors in print they miss onscreen,” but there’s no reason to imply that XML manuscripts cannot be printed.
I like Kelsey’s ” XML doesn’t, in and itself, actually do anything; it’s applications that can use XML to do things”
I’m not sure of Mary’s comment that “only larger houses can afford to buy & deploy the software” if you’re talking about open standards for XML manuscripts that are surrounded by vibrant open source communities. There’s certainly still investment, but it tends to be more about time rather than money.
Wow, Keith! Thanks for the great comments. I really appreciate your expertise, especially as I have no hands-on experience with XML.
I disagree with you on one minor point: I think “use” is a better term than “transform” in that particular context (although “document” may be the wrong term) because I think it’s important to see the content as a sort of nexus, from which a number of media can be generated, rather than seeing one format (say, a print book) as a primary output that can be transformed into secondary outputs (i.e. ebook).
You and Mary are totally right: I’ve overstated the potential to automate the conversion process. I’ll definitely revise that.
Your idea that an XML manuscript would be “nexus, from which a number of media can be generated” is right on, I’m just describing the process to get from a semantically-rich master XML manuscript into N other formats is a “transformation” process rather than a “use” of that master format. I say “transformation” rather specifically here, as the most common technique when trying to get master XML manuscripts into other outputs (PDFs, InDesign, ePub, HTML) is to use stylesheets written in XSLT, “a language for *transforming* XML documents into other XML documents.”
It’s probably worth saying explicitly that this is not what you want to promote: “one format (say, a print book) as a primary output that can be transformed into secondary outputs (i.e. ebook).”
I wouldn’t say at all that you overstated the “potential” to automate the conversion process, it just may be that there are certain outputs where readers find more value if the publisher adds some human polish.
Kathleen’s paper has been updated to reflect the comments above as of April 7, 2010.
“Authors would need to be trained in both the language and the company’s tag system or chosen schema; it is difficult to imagine Random House or even D&M Publishers undertaking this.”
A small comment: professional writers who work outside the book trade are often required to label the parts of their text in a similar fashion. In the system I used to work in, the person in the editorial role would verify the various text labels were correct and consistent across the project before publication, so several types of documents could be cross-referenced easily and accurately. In other words, it may not be as difficult as you imagine!