‘OpenReader manifesto’ ignores business realities of e-book industry

My friend David Rothman, one of the other folks behind the OpenReader e-book standard, owns at least three machines capable of running Mobipocket. Two of them won’t work with a supposedly compatible server at a library near him.

Difficulties like this are why I must take issue with another friend, Roger Sperberg, and argue for our practical standard to address publisher’s concerns and serve readers in the near future — not years or decades from now. I appreciate Roger’s candid thoughts on OpenReader, of course. For those who don’t know, I’m one of the co-founders of the OpenReader Consortium, which is the fledgling organization overseeing the development of the OpenReader Publication Format. Obviously, I have a different perspective on a few points made in Roger’s article.

I assume the reader will have first read Roger’s article. I’ll address my reply comments in approximately the same order that Roger presented them.

Warning: This article gets fairly technical in spots. I’ve tried to keep “tech-talk” to a minimum, but since Roger’s original reply is fairly technical and not written entirely for a non-technical audience, this reply must occasionally address certain technical issues on a similar level.

DRM

Contrary to what Roger seems to imply, until recently DRM did not form any integral part of the OpenReader purpose and strategy. That is, DRM was not the raison d’être for OpenReader — not one iota. OpenReader was motivated and developed for a host of other reasons, which would take too long to discuss in this reply article.

Nevertheless, as David commented, we cannot ignore DRM, since many publishers (particularly the larger publishers who hold a lot of the commercial content) are going to want it, at least in the short-term. We prefer that no encryption layer (to enable DRM) be added on top of the OpenReader Publication Format and to sell e-books (and other types of digital publications) totally DRM-free. But, DRM is a reality we have to contend with today.

Now, John Mark Ockerbloom, the moderator of the must-read Book People mailing list, has proposed that OpenReader establish requirements whenever a DRM encryption layer is applied and the name “OpenReader” is used. I agree with his proposal in principle but the devil is in the details — I hope to start soon a special working group, which both Roger and John Mark are invited to join, to address this issue. (Anyone interested in joining this group, please let me know.)

OEBPS

It is true that everything which OpenReader adopts could be applied to an “OEBPS 2.0” Specification. But then that’s because OpenReader is quite compatible with OEBPS — the fundamental paradigms between the two are quite similar. (To address a point Bill McCoy made a while back, OpenReader is actually quite compatible with OEBPS when one looks at it from both the user agent development and the authoring workflow perspectives — and these are the things that most count.) There are other reasons, as Roger touched upon (but not completely), why OpenReader has remained independent from IDPF up to the present. We continue to talk with some of the IDPF people about the future of both OEBPS and OpenReader. We share a similar general vision — it’s the sundry details that have to hammered out.

Note, too, that at present I am an invited contributor (they call it an “invited expert”) to the current OEBPS upgrade (which is not intended to be the full “next-generation” upgrade that OpenReader is today) and like to think that I am faithfully contributing my share to that effort. So there is not the schism that Roger makes it seem to be, but rather it’s more of a “let’s keep talking and hash things out” situation. These things sometimes take time to resolve — the history book is not yet ready to write on this topic.

OASIS

There is definitely interest in moving OpenReader Specifications development under the umbrella of a well-established and well-regarded standards group such as OASIS. But Roger is not correct in saying that we could be kept out of OASIS if someone else is working on a standard that may be considered competitive, or that OpenReader is deemed “unnecessary”. This is not true. I’ve talked with several OASIS bigwigs, and they make it clear that they do not disallow a new technical committee from starting if it is somehow competitive with an existing technical committee specification — it is not part of their evaluation process to ascertain “necessity”. All that is required is to have the minimum number of sponsors (which is their measure of “necessity”), and meet the other general and “paper-work” requirements, and the technical committee will be chartered. That is, OASIS tries to remain agnostic. (Note, anyone reading this who is interested in the OpenReader format, and who represents an organization or company that is a member of OASIS, contact me.)

OpenReader features, markup vocabulary agnosticism, and accessibility for the print-impaired

Roger apparently disagrees that the current draft OpenReader specification (particularly the Binder Specification) is innovative, even though it goes well beyond the current OEBPS in many new features and functions, and even surpasses the “OEBPS 2.0” spec whose work on it was suspended three years ago. It is more revolutionary than Roger gives it credit for. Of course, I realize that one person’s “revolutionary” is another person’s “ho-hum”, but this illustrates that there can never be agreement on how one interprets the importance of an event. I like to think that revolutionary sometimes sneaks in as “ho-hum”.

Like Roger, I want to see OpenReader evolve to content document vocabulary agnosticism (“roll your own vocabulary”). But this is a very tricky issue, and it first requires that the fundamental structure of the Framework is prepared to allow this (which the current OEBPS does not.) In addition, it requires the very active participation of the accessibility community since they are most affected by agnostic vocabularies — there are a few things that have to be worked out which I won’t delve into here.

Note that accessibility is critical. To ignore it or consider it an annoyance (as many do) isn’t only morally wrong, but will also interfere with the creation of a better standard for e-books and other digital publications. Satisfying the needs of the blind, the vision-impaired, the dyslexic, will impose a much-needed discipline on the standards-creation process. It will result in better navigational approaches for audio books, for example, and in general lead to better structuring of content for everyone’s benefit. In the future, I’ll write more on accessibility matters. Beyond the immorality of ignoring the blind, the e-book industry will suffer legal and public relations nightmares if it does not build accessibility into standards from the very start.

As an aside, the seeming lack of consideration for accessibility is observed in other recent endeavors to build new e-book standards, such as the Sophie project where I have yet to find an accessibility commitment statement. (Of course, the Sophie developers are invited to the TeleRead blog to share how their format will meet robust accessibility requirements — I’d like to know. Hopefully they are in constant touch with the accessibility community, such as George Kerscher, and that their format can be made compatible with the upcoming NIMAS education textbook requirements.)

Packaging/encapsulation

Roger essentially proposes that the multiple resources (files) which make up an OpenReader Publication be packaged into a single XML document — for example, the binary files, such as images, would be encoded as blocks within the XML package. Functionally, at least at the end-user level, there is no difference between packaging the resources in a zip file (as proposed by IDPF in its OCF Spec), and placing them into an XML document. In fact, there are problems with the all-in-one XML approach, such as compression, and more critically, possible patent issues (as the Open Office people found out early on when they tried to use an all-in-one XML-based packaging approach as Roger proposes, and found Microsoft breathing down their neck.) Now, if there are some important end-user advantages to the XML rather than zip packaging approach which we are not aware of, we are all ears. But at present, OpenReader plans to follow the lead of IDPF in this regards — for our packaging mechanism to be compatible with the IDPF OCF (which, in turn, is fairly compatible with the OASIS OpenDocument Format packaging mechanism, which, in turn, is compatible with JAR — notice a pattern here?)

By the way, to address Roger’s comment on openness and long-term use of zip (such as for archival purposes), if there is any “binary” format which will be long-lived and processible centuries from now, it is zip. It is so ubiquitous, and with the OpenDocument people, Java, Adobe, Microsoft, and many others now embracing zip for everything under the sun, I see zip being as easy to access 500 years from now as that other binary format called “ASCII”. The original version of the zip spec is a defacto standard not controlled by anyone — even those who believe someone must control it, well that someone is not an 800-lb. gorilla, and who can’t do much of anything to steer the original zip standard which everyone else (and their mothers) are whole-heartedly embracing in droves.

End-user alterability of published content

Roger addresses the need for end-users to alter/edit content. However, as should be clear from the recent flurry of TeleRead blog articles, the concept of annotation, where every annotation is a separate stand-alone file, has many advantages over the actual alteration of content, so I do not see the importance for an OpenReader Publication to be readily editable at the user side, even though in actuality it is readily editable (the content, after all, is simply placed in XML documents)!

Multimedia

The OpenReader Format is capable of embedding all kinds of multimedia objects just as web pages now can (and in some ways OpenReader can make it more powerful since it is not constrained to conform with usual web practice.) We plan to support XLink for embedding of non-text media objects, and establish it real soon.

SVG, etc.

I agree with Roger that OpenReader should natively support SVG, MathML, and other specialized “fragment vocabularies.” But the key is that the underlying framework needs to be fixed first, and then expansion to SVG be done methodically and carefully, because if that gets screwed up, it messes things up for years. There’s issues, too, which the OEBPS Working Group is now addressing with regards to using SVG (accessibility, fallbacks, which flavor of SVG to support, user agent issues on limited hardware, etc.), and OpenReader will learn from what OEBPS WG is doing, just as I’ve shared with OEBPS WG what we’ve learned with OpenReader such as the use of Navigation Sets — it’s a two-way street. I see incorporating SVG into OpenReader 1.1, not 2.0, with MathML support to be added sometime soon thereafter (possibly at the same time.)

To conclude

Anyway, this should provide a different perspective on Roger’s article, which again I want to thank him for writing, since it gave me the impetus to write something about OpenReader! Roger always keeps me on my toes, and I always respect his opinions — I definitely enjoy his many articles in the TeleRead blog and others.