One of the other traits of unix was that ther never really was a central authority defining what unix should do there was a bunch of companies doing their own thing within a set of loose conventions ensuring minimal interoperability.

–C

Moderator: We’ve made a tweak. Thanks, Cerebus. - D.R.

Your assessment of why ePub is designed the way it is, is spot on. I contributed to many of the OEBPS and OPS/OPF/OCF working group meetings starting in 1999, and so understand the many stakeholder requirements and thought processes that went into the specs.

Definitely, leveraging already-established technologies was important in the design of OEBPS for the reasons Liza cites. Why re-invent the wheel without good reason?

The real innovation of OEBPS, which today’s OPS continues, is the “Package” construct (the OpenReader format continued this with the equivalent “Binder”.) During the time OEBPS 1.0 was hammered out in 1999, it was clear from the many requirements (including numerous ones from publishers) that we could not design OEBPS based on the “web site” paradigm. Thus was invented the Package.

(The second most important innovation of OEBPS, which unfortunately is not yet well-known, is the “out-of-spine” feature, now officially called “auxiliary content” in OPF. One of these days I’ll write a blog article explaining this feature and why it needs to become better known and implemented. Interestingly, this feature is trivial to enable in web browsers, and is one reason why leveraging web browsers to render ePub Publications is so intriguing.)

Of course, the Package decision has kept OEBPS in a world somewhat separate from web content and browsers, since the web paradigm does not use anything like the OEBPS Package. Instead, index.html has become the defacto “package mechanism” for most web site “publications.”

Since 1999, Web technologies have evolved and improved, including web browsers. Today we have a richness of web browser technology we did not have in 1999. The real innovators in the web browser space include Opera, Mozilla/Firefox, and the fast-upcoming Safari. This bounty of technology is one reason, among several, why ePub must not ignore the web browser, and as ePub evolves it needs to move closer to the Web world, and not away from it as some others are advocating.

Maybe a full merger is possible in a few short years? I don’t know, but it is certainly worth exploring. I am now exploring a digital publication format that is much more compatible with web browsers, while retaining conversion compatibility with ePub. Possible? Definitely. The current ePub is excellent at representing primarily linear narrative publications. But as soon as one considers other types of digital publications, which tend to be more non-linear and topic-oriented, ePub does not represent those well.

Furthermore, when one looks carefully, linear narrative books comprise only a minor portion of the full digital publication universe. ePub needs to evolve to embrace non-linearity, and the web site paradigm is certainly the best “current technology” way to accomplish this goal at the consumer level since everyone already has a powerful web browser, and web browsers are becoming ubiquitous on nearly all hardware, even cellphones.

No need to reinvent the wheel, as Liza stressed in her article.