Times They Are A Changin’ – But Most Publishers Aren’t

Alan J Porter
[This post is part of a planned series of articles that examine how the traditional book industry could benefit from adopting XML.]

In order to prosper, publishers must re-engineer their processes and focus on creating content, not books.
Technology has changed a lot in thirteen years and so has the way that content can be created, handled and made ready for publication. But this publisher is far from being alone in sticking with old processes. My experiences working on other book projects in the last few years have just reinforced my belief that the vast majority of the traditional publishing market still works around a production system designed to do one thing – move paper.
A process that, despite changes in tools, has changed little since the dawn of the printing press.
For centuries the traditional publishing workflow has been:
- The author writes a manuscript (first on paper, then typewriters and more recently word processor software – these days usually Microsoft Word)
- The completed manuscript is then sent to the publishers for editing. Editing involved marking up, with either pen, or now using track changes and comments in the word processor, although sometimes it is just an email list of things to change. The editing phase can go through several iterations before everyone is happy and ready to go to publication – and by publication I mean go to print.
- The book, article, pamphlet or whatever is then recreated in the publishing tool. In the days of the mechanical printing press this meant manual typesetting, then with the emergence of desktop publishing tools it meant importing and converting the content from one for to another. The end result was the same however. Once the content is at the print ready staged it is locked into the format and layout of the physical page. Changes at this stage become costly, time consuming and rarely get reflected back into the source content.
- If the content is going to be published in more than one format, say a paperback and a hardback version, then a whole parallel production process has to be created.
- As systems and software are changed, as inevitably happens, the content becomes locked in multiple different software formats meaning that it either becomes unusable and the book goes ‘out of print,” or that multiple parallel production processes have to be maintained and coordinated for different titles based on when they were originally published.
- Even where publishers are now producing eBooks they are still setting up separate parallel production processes by taking the source content and having it converted into yet another layout driven format, that still uses a page-based paper-like model.

The best way to leverage the power of XML for any project is to use it from the start. This means using XML writing tools during the content creation process.
Once the content is locked into the deliverable format like this, it loses any potential to add value.
As I outlined in my last post, using XML allows the publisher to add real value to the content; it also allows them to fully separate the content from the publishing process allowing the content to be reused and republished many times over in different formats and on different delivery platforms without having to lock the content into the physical design of a page.
With XML the strictly linear production process that we are used to can also change allowing for more flexibility and reduced time between creation and publication.
There are several ways that the XML mark up can be applied to the content, either at creation or as part of a post-creation conversion process.

An XML publishing workflow requires authors to create structured content using XML-enabled authoring tools.
A well configured XML editor can give the same sense of freedom, by having a well thought out schema (mark up template) applied and installed before the author starts.
In the comments section of my last post publisher Richard Hamilton suggests that the biggest issue with getting authors to use XML is that it is perceived as ‘too technical’ and that implies both a step learning curve and a restriction in flexibility and style.
He makes some valid points. The truth is that the XML can be hidden from the author behind a template or a series of basic styles. If this were presented as a specific publisher’s Style Guide, rather than as XML Tagging it would make it easier to accept and implement for a non-technical writer. Most authors are used to working with different style guides from different publishers; working with XML should be no different.
Another approach is to develop the XML markup as the book is being written. In the sprit of full disclosure, Richard Hamilton, mentioned above, is the publisher of my upcoming book “WIKI: Grow Your Own For Fun And Profit”. In keeping with the book’s subject I am writing the book on free wiki software, (PB Works). Once I had a couple of chapters drafted in a totally free form way, Richard then developed a test page on the wiki to map the underlying wiki markup to XML, and associated that with basic styles such as:
Here is the Chapter title (Format = Heading 1)
Here is another heading (Format = Heading 2)
I, as the author, could then apply this style to my ongoing work without having to worry about the mark-up underneath.
By using just the first two chapters of the book we have developed both the required markup, as well as the end page layout and format for the print version. The book design is completed before I have finished the writing task greatly reducing the production time. It also means that changes can be made very close to publication date. The same source will also be able to be used to produce multiple versions for different delivery platforms without locking it into any one production process.

It's no more costly to send your content out for conversion to XML than it is to create and manage it in the inefficient ways most publishers do today.
It may be that to take advantage of XML and the added value it can bring that a book’s production ‘team’ will need to expand from the author / editorial / print to now include intelligent content and multi-media specialists working with the original author or adding value on behalf of the publisher. The production team will become more akin to a movie production with relevant specialists bought in on a per project basis. There may be an incremental increase in initial cost using this approach, but the pay off can be so much greater as instead of just a couple of print versions and maybe a basic eBook page turner, you can now deliver the same content as a full multi-media experience that not only works on today’s emerging technology, but will be positioned to take advantage of tomorrow’s technology too.
Switching to XML does not mean getting rid of paper in favor of eBooks, it means that paper becomes just one option among many. Most importantly it means changing the business model from shifting paper, to delivering intelligent content with real value.
[In the next post I’ll look in more detail at how XML can be used to add value through multi media and different presentation and delivery models.]
About the Author
Alan J. Porter a 20 year veteran of the corporate communications industry is founder of 4Js Group LLC a consulting and services company that specializes in combining creative talent with business expertise to help companies tell their story. He is also the regular writer of the monthly Disney*Pixar “World of CARS” comic book series.
His latest book, “WIKI: Grow Your Own for Fun and Profit” will be published by XML Press in May 2010.
Blog: THE CONTENT POOL http://4jsgroup.blogspot.com
Email: ajp@4jsgroup.com
Phone: 512-968-7362
Twitter: @4jsgroup
Similar Posts:
- None Found






























Good piece and lines up with findings in a recent report I did for our clients on XML–most XML is happening downstream from authoring and most of what XML is being done is structure tags, not semantic tags. Seems like an obvious investment to make but apparently not to some publishers.
[...] the publishing side, things will definitely be changing. They might not be now, but they’ll have to sooner rather than [...]
This is the most cogent summary I’ve come across about the disconnect between traditional publishing processes and the potential of new technology to expand the traditional “print” experience to match the capabilities of the i-Pad and other new delivery platforms. Your clever idea to hide the XML mechanics behind a style guide is brilliant. It will get the job done without scaring away the (non-technical) writers who have never heard of XML, but do know how to follow a style guide. This is a very reasonable recommendation for any prublisher with enough foresight to start evolving to handle evolving technology’s opportunities!