Gilbane and Aptara have a new report out this week called “Blueprint for Book Publishing Transformation”. It’s big and thorough (and free), and covers lots of important ground. The focus, naturally, is on XML:
We need to emphasize that the present day for book publishers should involve XML formats as early in the publishing process as possible. We are convinced that e-book formats will evolve and change and that new ones will emerge. XML stands today as the one standard format that will enable publishers to best create, manage, and curate content over time.
Most publishers agree. But implementing an XML-based workflow means climbing a steep learning curve, which involves a serious investment in staff training time and workflow teething problems, even if you’ve used cheap open-source solutions for the technical infrastructure.
One of our clients, for whom we’ve created epub files, asked me recently, “Are our epubs in XML?”. As a non-technical person it’s important to ask this question and to understand the answer. The short answer is Yes, which is great news: creating epubs is a first, easy step towards an XML workflow. It’s a kind of cheap future-proofing.
The long answer begins with: Yes, but not all epubs contain useful XML.
In all epubs, content and metadata are stored in XML. XML is a generic term that refers to any ‘markup language’, a system of marking content elements in <> tags, like this:
<question>Are our epubs in XML?</question>
<answer>Yes.</answer>
There are many kinds of XML, each distinguished by a particular set of tag names and particular rules for how tagged elements are structured. The most common kind of XML is HTML, which uses <p> tags for paragraphs, <h1> for first-level headings, and so on.
Epubs can be created in one of two kinds of XML: XHTML (a stricter form of HTML) and Daisy. Most use XHTML. Here’s the XHTML for the title page of our free, short ebook Embracing digital:
<h1 class="titlepage-title" id="heading_id_2">Embracing digital: Changes and opportunities in educational publishing</h1>
<p class="titlepage-author">Arthur Attwell</p>
<p class="titlepage-publisher">Electric Book Works</p>
(That tags the title as a first-level heading (h1), and the author and publisher as paragraphs (p). The paragraphs are distinguished by their classes: we’ve called them either titlepage-author or titlepage-publisher).
By creating epub files, a publisher is getting their content into an XML form. From there, the next step is to ensure that the XHTML is of a good quality, so that it can be reused in other ways in future, quite separately from the epub. It’s a huge waste to spend money converting print books into epub format only to create them with XHTML you can’t reuse, either as is or by converting it to other kinds of XML. The trick is to get your epub provider to use good-quality XHTML in your epubs from the outset.
It’s very easy to create sloppy XHTML. One of the most common problems with sloppy XHTML is that there is formatting information (fonts, colours, etc.) coded into the XHTML. Formatting should always be kept separate from the XHTML, so that you can later transform/convert the XHTML into other formats (e.g. print, database, website, app, etc.) that may require very different designs and layouts. In an epub, the XHTML should contain only text and links to images, with all formatting determined in a separate CSS stylesheet.
Another common problem with sloppy XHTML is that encoders (the individuals who create or edit the XHTML) make bad decisions about classes of elements, such as paragraphs, headings and lists. Classes distinguish one kind of paragraph from another, so that they can be given different appearances in the stylesheet. I won’t go into exactly how that works here, but here’s a brief example: if an encoder gives a dedication and an epigraph the same class (because they look the same in print), and uses a fairly arbitrary value, like “sig-5”, then that XHTML is almost useless in an automated conversion system or database later on. The dedications and epigraphs can’t be distinguished from one another. That book will have to be retagged manually, with separate, more meaningful classes (like "dedication" and "epigraph"). Those values should clearly describe these paragraphs’ functions, not their appearance (so "centre-italic" is also a lousy class name).
If you know that your epubs are built with good-quality XHTML, you can be confident that you’ll be able to convert that XHTML fairly easily into richer XML formats later on, with very little manual retagging. For instance, you may decide to store your master versions of books in TEI or DocBook XML, which would give you finer-grained control over content than XHTML allows, and provide more options for automatic conversion of multiple titles into other formats. Converting from XHTML to TEI or DocBook can be largely automated only if your XHTML is well-constructed and reasonably consistent across books.
Naturally at EBW we aim to produce XHTML that is as well-constructed and consistent as possible, while accommodating the unique nature of each book. This takes both technical and editorial skill. It’s much like building a house. Anyone who’s ever built or renovated will know: you don’t let just anyone build a new wall or put in a new window. As simple as it looks when it’s done, building well takes craft and experience, technical know-how and a measure of creativity. If your epubs are the first bricks in your publishing renovation, make sure they’re put together right.