OpenReader — Major Milestone Reached: Binder Document Spec Released

A significant milestone has been reached, just in time for Book Expo, with the release by the OpenReader Consortium of the first working draft of the open standard OpenReader Publication Format Binder Document Specification, version 1.0. The spec is considered stable enough that developers of authoring and reading software (in techese “authoring and user agents”) now have something concrete for development while the spec goes through further refinement.

The Binder document spec follows the Basic Content Document Specification, first released early this year, which is the first in a series of advanced XML-based specs to markup the actual textual content of digital publications (such as e-books.)

The Binder document is the heart and soul of the OpenReader Publication Format — the glue if you will — which ties together all the files (in techese “resources”) which make up an OpenReader Publication. Just as a typical web site comprises a number of resources, such as HTML documents, images, video, audio, style sheets, etc., so too an OpenReader Publication may comprise similar multiple resources.

However, unlike web sites which have nothing comparable to the Binder, the Binder’s purpose is to organize all the resources in advanced ways not possible in the web “paradigm.” This enables powerful and much-needed ebook-related features and functions that are difficult, and in some cases impossible, to enable with the simple and quite limited web site method of organizing resources.

Why the word “binder” was chosen to describe this document is explained in the Binder Specification Introduction (warning, “techese” alert!):

The word “Binder” is used since the Binder Document is, in a loose sense, the digital equivalent of a book binder, or a three-ring binder, where paper pages (which can be thought of as discrete resource fragments) are ordered and “bound together” to create a single, coherent publication.

The OpenReader Binder document is inspired by, and has far surpassed, the OEBPS Package document, first developed in 1999 but little changed since then. In Internet years, any specification first developed in 1999 is more-often-than-not dated. The Binder incorporates all the improvements and fixes (and adds some new innovations) which publishers, retailers, the accessibility community, and e-book users have being clamoring for the last few years, but which OeBF (now IDPF) has chosen, at least until very recently, to ignore.

What features have been added/improved?

Space does not permit this article to explain all the features and functions enabled by the OpenReader Binder. Some of the features are quite technical and pertain to the inner workings of the publication authoring work flow and user agents— and to improve accessibility and internationalization. Only a sampling of a few of the new and innovative features (not found in OEBPS) will be highlighted here which users of e-books may find of interest:

• Multiple User Sets. The “User Set” is fancy jargon for the Binder innovation where publication authors may optionally designate multiple “looks” into, or “renderings” of, the same publication. For example, Publication authors may use the User Set mechanism to supply a publication in multiple language versions. Or, they may provide a “façade” book (akin to a sampler or movie “trailer”) alongside the full version. Or, in educational textbooks the same publication may contain multiple User Sets, each one targeting a different grade level, all the while drawing upon the same pool of resources and being distributed as a single publication. User agents can provide to the user a menu listing all the User Sets in a publication, if more than one.

• “web” and “oeb” Modes. Let’s face it, the majority of real-world publications are essentially non-linear in nature. Some examples include, among others, reference manuals, encyclopedias, dictionaries, modern hypertext literature, cookbooks, newspapers, and periodicals. In the paper publishing world, because of the physical limitations of binding together leaves of flattened and pulped dead trees, publishers are forced to linearize their content, oftentimes quite arbitrarily (such as alphabetical.) In the digital world, we are not so constrained, and the digital medium needs to recognize this as an opportunity, rather than trying to force all publications into linearity (thank heavens the Web is not forced to be “linear”!) The OpenReader Binder, significantly expanding upon the OEBPS “out-of-spine” feature, offers greater ability for publication authors to handle non-linear content. Even most web sites can now be converted to OpenReader Publications while fully preserving their “webness.”

• Cover Art and Thumbnails. The Binder includes functionality for publishers to designate multiple resources (including audio and video) for the cover art, and multiple images for thumbnails. OEBPS never implemented this, despite many requests by both publishers and retailers the last few years. It’s about time.

• Centralized Styling. A major innovation in the Binder is the centralization of all document styling. On the web, and in OEBPS, styling is still done at the document level which is inefficient, confusing, and limiting. However, in OpenReader, styling is done at the publication-level — in the Binder. Space here does not permit me to go into the many reasons why this is a huge innovation, and the many advantages it gives to publication authors and end-users. However, one advantage is that the publication author can now designate multiple Style Sets for the entire Publication, from which the end-user may select the one they want to use from a menu provided by the user agent.

• Navigation Sets. To aid both accessibility and to improve the end-user reading experience, the Binder requires the publication author to provide at least one Navigation Set, which is fancy jargon for a machine-readable “table of contents” and similar types of linking lists (they may even be hierarchical.) This removes such linking lists out of content, where they do not belong, allowing user agents to present the linking lists to the user in innovative and powerful ways. OSoft’s ThoutReader and the upcoming dotReader prove the value in doing this. Of course, accessibility requires a standardized, machine-readable table of contents, outside of content itself, and similar linking lists, and the OpenReader Binder Navigation Sets feature provides all that the accessibility needs in this area.

We invite your feedback on the draft Binder spec! In addition, you are invited to join the OpenReader Format Working Group to help us refine the OpenReader Publication Format.

(Btw, for those planning to attend Book Expo in Washington, DC this Friday through Sunday, I plan to be there, hanging out near the OSoft and Rosetta Solution’s booth (Booth 3729.) I look forward to meeting you and answering any questions you may have about the OpenReader Format, including how you may implement OpenReader in authoring and reading systems. If you need to reach me by phone, my cellphone number is 801-230-8881.)