25

By Jon Noring

Indiana Jones in the Temple of DoomI have been quite perplexed in reading the many comments about IDPF’s “ePub” format following the release late last year of its underlying specs. A number of very smart people, including several developers who naturally dig deeply into tech specs, have painted ePub as a dark and mysterious digital publication (e-book) format, unlike anything else in the Universe™.

The way some have discussed ePub, if Indiana Jones were to explore the deep caverns of ePub, he would probably find something exotic and other-worldly, maybe even the remnants of a long-lost civilization. [note 1]

In reality, though, the opposite is true. ePub is internally quite recognizable and familiar, very similar to traditional web content that we all know and love.

ePub and web content share a number of important commonalities:

  1. ePub represents the textual content of the publication using standard, ordinary XHTML 1.1. So may web content. [note 2] [note 3]

  2. ePub styles the XHTML documents with CSS. So does web content. It is expected that ePub reading systems will interpret the CSS pretty much as web browsers do.

  3. ePub may include JPEG and PNG images. So does web content. ePub may even include multimedia – the same multimedia that we love to view and listen as we surf the Internet with our web browser.

So what is the main difference between ePub and “web content”?

The answer to this question, given in the next section, puts ePub into proper perspective, making it much less mysterious, and a lot more familiar. But to answer in brief: there’s very little difference between the two where it really matters.

It also suggests a next-generation successor to ePub that is much more compatible with the “web paradigm”, while offering the advantages the current ePub offers for both the digital publishing industry and the reading experience. A merger of the two “worlds”, benefitting both and compatible with each other, is certainly possible – and intriguing to explore.

I see today’s web browsers evolving to be the center of this merger – to be the platform for reading all types of digital publications. Today’s “wall of separation” between the web browser and “e-book readers” is, in reality, quite artificial, and in some ways even unfortunate.

Techese Alert: what follows will be somewhat technical, but hopefully non-technical folk will be able to understand the general points.

The primary difference: How the content is “stitched together”

Singer Sewing MachineMost web sites (which can and should be thought of as a type of online “digital publication”) are comprised of multiple HTML content documents. ePub may also comprise multiple XHTML content documents.

The fundamental difference between the two “formats” (yes Martha, there is an implied “web site format”) is the mechanism of how the content documents are “stitched together” or organized into a coherent whole. That is, how does the user agent (browser; reading system) know which content document to display next when multiple documents represent the “publication”?

There are two ways to instruct a user agent as to what content document to display next:

  1. Internal Reference (IR)

    This is the “web browser model” where all the documents are linked together using hypertext links hard-coded within content. No need to explain this any further – it’s how the whole Web is put together!

  2. Document Organization Template (DOT)

    This is the method used by ePub. A separate file, not part of the publication content, contains information which “sews together” or organizes the publication’s content documents. In the case of ePub, the document organization is accomplished using the <spine> element in the OPF “Package” document. (ePub also allows hard links for the reader to optionally jump to other content.)

    In general, we could term any externally-designated means of organizing content documents a “document organization template” or DOT for short. [note 4]

    The user agent will use the DOT information to either create a seamless reading experience, and/or build the links for the end-user to actuate. With a DOT, it is possible to construct an entire book using a number of independent content documents, yet to the reader the book could be seamlessly presented just like it is one document (depending upon the sophistication of the reading system), without the reader needing to actuate a link.

Obviously, there are advantages and disadvantages to each method, and variations on each (ePub is not the final word on the DOT approach), which I won’t delve into here. [note 5]

What does this mean? (The bigger picture…)

From the discussion above we can make a few diverse observations:

  1. ePub itself is essentially a flavor of a more general class of digital publication frameworks where a DOT is used to “stitch” together multiple XML documents (such as XHTML, Digital Talking Book, etc.), all styled using CSS. Hard links may also be added within documents to allow the user to optionally move to a new document.

    The OpenReader format developed a few short years ago is an example of a quite similar DOT-based framework whose DOT is more powerful than that of ePub. Our analysis showed that if one were to build either an OpenReader or an ePub reading system, the jump required to read the other format would be very, very small.

    Thus, competing “formats” that use some sort of DOT to organize XHTML content documents (styled with CSS) are quite compatible with each other. It is actually not correct to call them incompatible or that they contribute to the Tower of eBabel since the same reading application for one can be adapted with relative ease for another, and inter-conversion is possible.

  2. Plug-ins for current web browsers to handle ePub and similar DOT-based frameworks should not be difficult to develop. Future web browsers may even natively incorporate the ability to seamlessly present ePub and similar DOT-based framework publications.

    The simplest approach to leverage today’s web browsers for reading ePub Publications, and which avoids the plug-in route, is a straightforward ePub to “web site” converter. This allows the end-user to be able to read their ePub Publication on any device they own which has a web browser. (I’ve thought about such a converter and will be happy to talk to anyone interested in developing this tool. This could be a collaborative open source project.)

  3. As noted in the previous section, we may contemplate merging the “web paradigm” with the “DOT paradigm”, thus supporting both, and getting the advantages of both.

    For example, I see a new generalized DOT standard which future web browsers and specialized digital publishing reading systems can use to organize and present documents to the user. This generalized DOT should be able to handle much more non-linear publications than the quite limited (read: mostly linear) DOT used in ePub.

    Of course, I don’t see DOT as a replacement to Internal Referencing used today on the web, but rather as an option to use when suitable – both could be used simultaneously, as OpenReader demonstrated.

Summary

It is important that we not erect an artificial wall between ePub and web content. Certainly they are different in some ways, particularly how the content is organized. But they share many more similarities than differences.

It is my hope that we will begin to focus on the similarities, and enterprising individuals in the developer community will start building ePub reading systems based on leveraging existing web browsers. This is not to say effort should not be put into building powerful, stand-alone ePub reading systems which optimize the e-book reading experience and take full advantage of the feature-set in ePub.

Anything which promotes the direct reading of ePub Publications on a variety of devices will help ePub to more quickly reach critical mass in the digital publication community. The winners will be both publishers and consumers.

Referenced notes:

Note 1

At the risk of appearing a little too facetious, a couple of folk have even put forth “Grassy Knoll” type conspiracy theories centered around ePub and [insert the name of your most hated company]. It would not surprise me if these conspiracists will next tie ePub with the Trilateral Commission, the Bilderberg Club, or the Bohemian Grove, citing the proof of such a nefarious connection is patently obvious to all. Maybe Coast to Coast AM needs to cover the ePub Conspiracy? <smile/>

Note 2

XHTML is basically a strict, XML-based flavor of HTML. Web browsers seamlessly handle all kinds of flavors of HTML, including XHTML.

Note 3

ePub may also include content documents formatted using the Digital Talking Book markup vocabulary. Since DTBook is quite similar to XHTML, and is renderable with CSS in most standards browsers, it is not necessary to needlessly complicate the discussion in the main section.

Note that ePub was specifically designed to be fully DTBook-compatible, even embracing DTBook’s NCX (navigation center document.)

Note 4

I’m not wedded to the term “document organization template” (“DOT”) as no doubt someone with greater imagination will come up with a more accurate and better-sounding term. DOT will suffice for use in this article.

Note 5

As mentioned in the main article, the DOT information for ePub is placed into the <spine> element located in the OPF Package file.

It is important to note that the OPF Package performs a number of other tasks for digital publication use not easily done with the “bare” web paradigm, such as assigning “publication-level” metadata, and providing machine-understandable (and accessible) navigation aids, such as a table of contents, using DAISY’s NCX.

To provide a historical perspective, back in 1999, when the original OEBPS format was designed, the first proposal was simply a “web site” packaged into some container for single-file distribution. But as the specific requirements came pouring in from publishers, retailers, developers, and other stakeholders, it became clear that a new construct, which became the Package file, was necessary. This explains the early divergence of OEBPS/OPS from the “pure web paradigm”.

Today’s ePub (specifically the underlying OPS, OPF and OCF specs) meets a long list of requirements which were established by publishers and several other stakeholder groups.

 
25