Everyone’s OpenReader

Welcome matBill McCoy of Adobe has challenged the "openness" of the OpenReader Framework specification that the OpenReader Consortium is now developing. Some of his points I agree with — others I don't. I won't analyze everything he wrote; this is a commentary, not a novel. Instead I will focus on a few of his major claims. Meanwhile I'll remind the Biblically inclined of Proverbs 18:17, which admonishes everyone to get all the facts, from different perspectives, before deciding on anything. Now, first, let me thank Adobe for the informal, unofficial technical advice already provided for the OpenReader format — both the framework and the associated encapsulator/container. Brilliant contributions from Adobe I'm especially appreciative of a few contributions to the OpenReader format from Jon Ferraiolo, a senior computer scientist at Adobe. He is an editor of the SVG specification, which OpenReader plans to support in its Framework. JonF (and I'm known as JonN) reminds me of several of the brilliant people I observed who authored the original OEBPS Specification in 1999. Adobe as a company does not currently support the OpenReader Consortium, but with people like JonF, I hope that it will.

I also want to note that I follow Bill’s blog for his many insights, and several of his past articles are definite “must reads” for e-book industry people.

Where Bill and I agree

And now to get to the latest post in Bill’s blog…

First, I believe Bill and I agree that any technical standard or specification needs to be developed by a dedicated group of experts to assure the stability, usefulness, extensibility and adaptability of the specification .

Moreover, a specification should meet the most important needs and requirements of its primary users.

That’s what we are striving to do with the OpenReader Framework specification. We have a dedicated core group, and have an open, standing invitation for others to join us.

Our consortium values input from anyone believing in the need for an open standard, universal, consumer digital publication format based on a next-generation OEBPS-like framework. Or at least people who believe this approach should be tested in the marketplace. That is hardly a high hurdle to participation.

Open to participation from most anyone

Contrary to what Bill seems to imply, then, our working group is open to participation, contribution and decision-making by pretty much anyone. All the participants need to do is to contribute, and then, presto, they are part of the decision-making process. Dues are $0.00. Contrast this with IDPF, whose annual dues for companies start at $1000.

Interestingly, as noted above, Adobe has been a significant contributor to OpenReader by the few informal comments already made. I personally agreed with every recommendation Jon Ferraiolo has made to us so far. In fact, we’re implementing them in the initial draft spec, parts of which have already been shared with members of our open group for developing the format.

I’m working on the rest of the draft specs now for submission to the group. What I’m authoring now is the first draft — a starting point for deliberative discussion — not the final format. Interestingly, many of the organizations we talk to continue to ask,”Where are the draft specs?” Bill’s criticism of those efforts falls into the “No good deed goes unpunished” category — the first of various “Catch-22s” we have to contend with.

(As an aside, but relevant to this discussion, the OpenReader Framework specification is essentially a “next-generation” OEBPS. It will incorporate many features asked for the last few years by publishers and user agent developers, plus more recent requirements for enabling powerful linking into and between OpenReader Publications. The hard work behind OpenReader was already done in 1999, when the basic foundation of the “OEBPS Framework Paradigm” was established in OEBPS 1.0. Thus, the approach of authoring the draft spec first, and then deliberate on that, is not only possible, but preferable since it allows working group members, as well as specification implementers, to have something tangible and organized to work with.)

Furthermore, Bill is reminded that it is tough to solicit technical contributions to a standard, to get decisions even from very supportive organizations. I have served on IDPF’s Publication Structure Working Group (PSWG) since 1999 (with a short “sabbatical”), and know first-hand about this. It is often frustrating.

Our outreach — lots of interest in OpenReader

Regarding our outreach, we have been quite active of late in contacting a broad range of “stakeholders” in the digital publication ecology, making new alliances on a weekly basis. (Our website is behind with regards to the organizations who have endorsed OpenReader in some manner.) This growth will continue to increase our technical and organizational base.

The OpenReader format vision is striking a real resonance among many forward-thinking organizations representing various stakeholders: publishers, document conversion houses, e-book retailers and distributors, device manufacturers, librarians, etc. Many are tired of the plethora of incompatible, proprietary, and inadequate formats, along with the onerous DRM systems that are taking a real heavy toll on e-book retailers and distributors (a topic worthy of its own blog article — Bill wrote an excellent article on DRM.)

OpenReader is not YAF

Even though some see OpenReader as simply “Yet Another Format” (YAF), a position we do understand, OpenReader is not YAF. Rather it is a breath of fresh air in the digital publication ecology.

Why? Many of the current crop of e-book formats have been developed by high technology companies to support specific, proprietary business models, with the ultimate goal of benefiting short-term shareholders. The philosophy is, “Do what’s expedient for short-term market share — rather than doing what’s best for the long-term, and what’s best for the digital publication ecology as a whole.”

Given the needs of the market, this actually harms the long-term shareholders. Perceptive and responsible shareholders will care more about sustained revenue than about quick gains from continued domination of the still nascent market for e-books. What’s the size of the e-book market today in the United States? Perhaps well under $25 million a year, which is a drop in the bucket of total sales of paper books.

Beyond the status quo

Simply put, standards must exist not for the perpetuation of the status quo, with all its clashing proprietary formats, but for the long-term growth of the market for e-books and other digital publications. The “Tower of eBabel”, as David Rothman calls it, baffles and alienates consumers.

In contrast, the motivation behind the OpenReader format is to benefit publishers and end-users. We want to meet important, long-term needs and requirements of publishers and users alike — in fact, of society in general. So this is not business as usual driven by quarterly earnings. That’s why we are thinking long-term. What features and functions should e-books have 10 years from now? 50 years from now? The pathway to meeting these future requirements starts today, not sometime in the indeterminate future.

Shouldn’t publishers and end-users come first, second, and third, when developing a digital publication standard, if a long-term market is to grow for companies such as Adobe? We have the advantage in that we are not encumbered with such proprietary/commercial restraints, and thus can focus on doing what’s best for the long-term growth of the digital publication ecology. Let’s not forget that this growth will be fueled by end-users who spend their hard-earned money to buy content provided by publishers. Notice in this equation the mention of only publishers and end-users? Everyone else plays a supportive role.

Time will tell if OpenReader will succeed in becoming a major e-book and digital publication format, but no one can blame us for not trying!

The value of PDF/A

What’s more, we do not see OpenReader replacing all of today’s formats. We are for “everyone” in the sense of trying to be responsive to a wide range of needs. But we’re happy to let the marketplace test us vs. other formats. We see a need for fixed page formats in the digital publication ecology, such as PDF (preferably PDF/A, which I’m glad that Bill had good things to say about) and the intriguing Microsoft XML Paper Specification (which I hope will be released as a real open standard). OpenReader addresses the important market segment that requires a truly adaptable/reflowable, yet typographically rich format (a possible topic for a future blog article?).

Moreover, I disagree with Bill’s comment that the OpenReader Consortium as an organization “disses” PDF. In fact, last year we were in touch with the PDF/A group which Bill lauds (specifically we talked to Stephen Levenson), and we are exploring how PDF/A fits in with the OpenReader vision. One of the co-founders of OpenReader, Rick Barry, is very well known in the Archives and Records Management area (we call him our “ARMist”!) See, for example, Rick’s thoughts on OpenReader for records and archives management wherein we discuss PDF/A, among other topics.

A move to an established standards organization

On another point, I will note Bill’s encouragement that we move to an established standards organization; I do not disagree with that in principle. In fact, we began to consider this in late November, making contacts, and several days ago we decided for certain that we would approach such groups. It is time to see which we might be compatible with. Our support base has substantially grown and a couple of the core founders and technical consultants believe we should explore this in earnest.

Needless to say, moving to a standards organization is something not to be taken lightly, nor rashly. There are also many downsides in moving to an established standards group, particularly if the group is mostly “generic,” or if it has too much “political” stuff going on internally (which I’m all too familiar with.) So we have discovered in talking to various experts. I won’t delve into the details here unless Bill discusses this in a follow-up blog.

By the way, to address a related comment Bill made or implied, I have publicly stated more than once that we will consider submitting the OpenReader Framework Specification to IDPF/PSWG for consideration as the next-generation OEBPS. This would happen when the specification is stable and proven “in the field” with commercial implementation(s).

Avoiding DOA standards

It is also more than obvious that what a standard really needs to succeed in the marketplace is not the backing of some major standards organization, but the implementation of the standard in the real world — that is our prime focus these days. We recognize the truth in a famous saying: “The nice thing about standards is there’s so many to choose from.” A large number of standards are published by many well-known standards organizations which became dead-on-arrival, “DOA,” the moment they were approved, because there was no serious emphasis on implementing the standard, even with a “reference implementation.” While standards fail to take hold for other reasons, too, this is no small factor.

(Here I am reminded of the adage “A camel is a horse designed by committee.” This means the success of a spec is not guaranteed by it being developed through a starchy, formal process, even though the various formalisms are useful.)

Another point Bill raised — even while seemingly denying he agreed with it — is that the OpenReader format is a “NoringOSoftReader.” He implied OpenReader really is a proprietary format masquerading as an open format, but this is totally unsupported by the facts, both by what we have said, and by our actions.

Just the first implementer

Our goal at present, and all last year, in promoting OpenReader, is to find companies and organizations interested in developing/implementing the specification, and/or to become founding partners of the Consortium. OSoft stepped forward last summer to offer to implement the OpenReader Framework specification in the next version of its Thout Reader. But even though OSoft is the only company yet to commit to implementing the OpenReader format, we continue to seek, and will welcome, others to implement their own OpenReader user agents, and other OpenReader-based applications, including those who may want to compete with OSoft. Let a thousand flowers bloom!

Significantly, OSoft intends to open source its OpenReader application codebase — in effect, this is very much like a SourceForge project. So a competitor to OSoft can use the codebase to build a competing product! Thus, Bill is incorrect to paint OSoft as a proprietary company, at least when it comes to OSoft’s plans for implementing OpenReader, where it is best compared to an open source SourceForge project. Contrast this to major Adobe products. Are any of them open source? From this perspective alone, Bill’s comment of invoking OSoft to repaint OpenReader as “ClosedReader” (my phrase) is rather off the mark and disappointing.

Adobe DRM: Will it be nonproprietary?

The other comment, about OSoft patenting its particular DRM/TPM method, I’ll leave it to OSoft to comment since that’s its product, outside the scope of OpenReader. But I do want to ask how many “public domain” DRM standards are currently available? Will Adobe free up its DRM technology to open source/open standards — for example, turning it over for very little cost to a non-profit run by and for publishers, retailers and distributors? And I’m also curious to know if Adobe holds any patents associated with its DRM system?

I’m sure it was not Bill’s intent, but he is also placing us into a classic “Catch-22” position that would make Joseph Heller proud. We’ve been working hard to find major organizational support for the OpenReader idea and to become co-partners in the development of the specification and the Consortium. To move to an established standards organization essentially requires we already have a core group of companies/organizations backing us up. I won’t elaborate further on this point unless asked, but I think the “Catch-22” should be obvious to all.

Breaking through the Catch-22s

In fact, any project like this has to break through several Catch-22 barriers. And when we succeed, we are even criticized for doing that! (I am not referring to Bill’s article specifically, but to other feedback we’ve had.) To a few we can’t win no matter what we do, so we may as well do what we believe to be the right thing.

Now, to reply to another comment Bill made, we did consider IDPF a year ago for hosting the OpenReader Framework specification development. Two individuals I highly respect encouraged us to formally ask IDPF to move our activities there. But at the time, because of various “political realities,” of which Bill is undoubtedly aware, it did not appear feasible. Also, OEBPS 2.0 has been in the works for more than four years and never got much past the advanced conceptual stage (some “specese” was written.) And there are currently only two “active” people in PSWG at the moment, including yours truly.

Thus, I did not have warm fuzzies all last year that the specification would get the priority support from the IDPF Board that it needed to move forward at full throttle. It would end up sucked up into some black hole to be deliberated on for years while the proprietary politics continued to swirl. To its credit, IDPF recently seems to have renewed interest in standards development, with the establishment of the Container Working Group, ably led by Garth Conboy and John Rivlin at Ebook Technologies, Inc., and which I serve as an invited expert. Hopefully this will lead IDPF to make open standards, including at the consumer level, a top priority rather than the low priority “by the way, we also do standards,” characteristic of the last few years.

Still the “de facto” acting chair of PSWG

Of course, I maintain contact with IDPF because its membership includes quite a few great companies, organizations and individuals that want a vibrant e-book and digital publication industry and who believe that goal (which includes full accessibility) is best reached with open standards, including at the consumer level. As already noted, I continue to assist with standards work in IDPF, such as being the “de facto” acting chair of PSWG, which maintains the OEBPS spec. (To clarify, I’m holding down the PSWG fort until the IDPF Board formally selects a new chair since I understand the chair must represent a dues-paying member — I’ve maintained my independence since 2000.)

Since I’ve been involved with OeBF/IDPF longer than most others, have hung in there longer with the hope it will renew its emphasis on open standards, and still believe in the innovative OEBPS paradigm for native use as an end-user format (as well as the need to improve it), I do not take lightly our decision to maintain OpenReader’s independence from IDPF last year. Time will determine whether or not we made the right decision.

Invitation’s open!

Hopefully this clarifies my thoughts on some of Bill’s comments.

Although Bill may decline at this time, I once again invite Adobe to become a major supporting organization of the OpenReader Consortium, and in good faith support the general goals and vision of OpenReader.

And of course, I invite anyone who supports OpenReader’s goals to contribute as you can. Feel free to email me regarding your interest and what level you can contribute.

(Moderator’s note: For another, less diplomatic perspective, see my personal thoughts on Bill’s commentary. – D.R.)

6 Comments on Everyone’s OpenReader

  1. Jon,

    I don’t know how much more “open” OSoft can be. Just two weeks ago I sent out an invitation to the entire 3,000+ member Yahoo eBook Community to participate in live demos of the ThoutReader. We were interested in both publisher and end user feedback on features, user interface, desired DRM requirements, and other functionalities. We have not been disappointed with the comments.

    Keep up the good work.

    Mark Carey

  2. Hello, I uses Adobe reader already some years for me gives not better, at present the version 7,0 and the Adobe Photoshop the 3.0 version. I use both programs for the Shop treatment, could to me without the two programs this with difficulty present. Before 8 years in the catalog age used I Pagemaker with the version 4,0 has I begun now possesses I the version 7,0, but the program is so extensively if man 50-60 % is beherscht one professional. wish still kind regards from Austria, and sorry for my bad English

  3. I thank Bill McCoy for promptly replying to this article in his blog. Those interested in standards development strategies are encouraged to read his blog article.

    So, what do you think? Does Bill have a point, or is OpenReader’s current standards-development strategy (outlined in the above TeleRead article) also viable?

  4. John Mark Ockerbloom // January 30, 2006 at 2:37 pm //

    I’t’s nice that OpenReader group plans to release a draft spec of its “framework” part soon. But it’s the “associated encapsulator/container” part, not so much the “next generation OEBPS” part, that I’m most concerned about with OpenReader. Getting the spec for *that* right is going to be crucial if OpenReader is going to be able to satisfy its promises to the reader.

    Consider the poll currently on the OpenReader site about negatives of proprietary formats (which are implicitly contrasted to what OpenReader will be like):

    — Can’t reliably upgrade to new PDA or other gizmo
    — Low limits on the number of machines that can display my books
    — I’m worried the company will be bought out or go out of business
    — The vendor might not always support the format
    — Why should my choice of operating systems influence what books I can read?
    — I hate the idea of one company rising to the top and bossing publishers around

    All of the above are still problems with an open “framework” format wrapped in a proprietary “encapsulator/container” packaging. Making the underlying “framework” more feature-ful than existing standards like OEBPS 1.2 doesn’t in itself solve any of these problems. So if OpenReader wants to change the situation, it will have to specify both framework and packaging. (And the latter should not lag the former, lest someone run with the inner format and wave the “OpenReader” banner over all kinds of new encumbered customer-hostile ebooks.)

    As far as the underlying document formatting goes, a next-generation improvement on OEBPS sounds nice, but I’m personally happy to just have some good-enough existing standard there for starters. Whether that should be the current version of OEBPS, or XHTML, or ODF, or eventually some new better format that the OpenReader group comes up with, doesn’t matter much to me as long as it’s something that’s clearly and openly specified and easy to implement. How the user and the user’s software can (or can’t) get access to this open standard in actual OpenReader books they acquire is what makes the format as a whole “open” or not from a consumer’s point of view.

    So I’d suggest that OpenReader needs to concentrate its attention there, if anywhere. Even if it doesn’t have a full spec right off the bat (which the “we’ll deal with DRM in the next release” comments I’ve seen hint at) it at least needs to nail down clear and firm requirements about what kind of packaging/encapsulation is acceptable and what isn’t for a book that claims to be an OpenReader title. If specifying a new “next generation” document representation format is postponing that, I’d argue that that’s a distraction that could be fatal to the project’s stated mission.

  5. In reference to John Mark Ockerbloom’s well-written comment, when one looks at the user agent codebase requirements to unpack an XML-based framework (such as OEBPS and the proposed OpenReader), versus the requirements to render the framework once unpacked, we find that the unpacking step borders on the trivial (e.g., unpack a zip file.) That is, from an application point of view, the container is pretty much a triviality.

    For example, let’s assume we have three quite different container formats which encapsulate the same XML-based framework (e.g., one is ZIP, another is multi-part MIME, and the third is serialized XML akin to those used for the FictionBook 2 and Sony’s BBeB Xylog formats.) A user agent, originally designed to process and render the framework inside one of the container formats, will be able to readily unpack the other container formats and process the framework inside. The same cannot be said if the framework inside is fundamentally changed, such as to some oddball non-XML format. Now we are talking about major software changes, and likely major changes in the end-user reading experience.

    Thus, it is what is inside the container that is the most important to get right since that is what really defines the format as the user agent renders and as end-user accesses it: features, functions, etc. I agree with Bill’s latest blog article, where he keeps the focus on the XML-based framework and is not distracted by container issues. (I believe we need to think of separating container and framework, akin to the mantra in XML of separating content and presentation.)

    Nevertheless, it is important that the design of the container itself be well-done so it facilitates the ability of user agents and other applications to access the framework resources inside of it (both content and important metadata, particularly publication identifiers), as well as meet other miscellaneous requirements of publishers and end-users.

    Obviously, there is the issue of someone developing a proprietary container format to encapsulate an open standards XML-based framework, and in so doing attempt to destroy open standards containers encapsulating the same framework. But this issue is tackled three ways:

    1. the digital publication industry develops and promotes an open standard container format,
    2. the fact that it will be trivial for a publisher to package the same XML-based framework content into various container formats, as well as trivial for user agents to unpackage the various containers (as noted above), and
    3. the growth of open source user agents to render the XML-based framework and which can handle different container formats as already mentioned.

    I believe these three factors will act as a sufficient check to prevent runaway “proprietization via container” of the open standard framework.

    For (1), the Container Working Group in IDPF is indeed working on an industry-wide open standard container which I’m an invited expert (representing the OpenReader Consortium.) I urge John Mark Ockerbloom to follow that work (and do consider asking Garth Conboy, the co-chair of CWG, for permission to attend the CWG Face-To-Face meeting in NYC on Feb. 7/8 — I’ll put in a good word for you!)

    Item (3) is interesting. The other day I downloaded Fictionwise’s “lite” desktop reader, which is a freebie, and noticed that it unpacks and renders non-DRM’d (Sealed) Microsoft LIT files. After all, Microsoft LIT is essentially an OEBPS 1.0.1 Publication (an XML-based framework) encapsulated with a proprietary container. (Of course, Fictionwise reader’s quality of rendering leaves a lot to be desired — it is not designed to be a high-quality XML-framework rendering engine. But “rich” XML-framework user agents will be able to do a great job in presenting existing Microsoft LIT publications, and could surpass the presentation quality and feature-set of MS Reader, if they wanted to.)

    So far I’ve not talked about DRM/TPM, but then this is a difficult topic (a “sticky wicket” as our friends across the Pond would say) no matter what types of containers and frameworks we are talking about. Encryption is pretty agnostic to what is being encrypted, and the issues of decryption (such as faced by end-users, including libraries and archives) are essentially independent of underlying framework.

    Certainly, most of us would like the DRM/TPM issues to be resolved in some uniform, industry-wide, consumer-friendly fashion by the time open standard consumer-level digital publication formats are embraced and become commonplace, but I believe this requires a dialogue orthogonal to (but not wholly separate from) the issues of container and framework.

    I’m certainly open to further discussion on these topics, and can be persuaded to change my mind on some of my conclusions above as I read different perspectives.

  6. Jon, you mention here and the OpenReader.org website describes the operation as a nonprofit. Is OpenReader.org been granted 501(c) nonprofit organization status? If not, has it been applied for? I ask here because I can’t find any information on this at the website.


2 Trackbacks & Pingbacks

  1. Idiotprogrammer » Blog Archive » Ebook Creation Links
  2. Dear Author.Com | The Limits of an Open Reader Standard

The TeleRead community values your civil and thoughtful comments. We use a cache, so expect a delay. Problems? E-mail newteleread@gmail.com.

wordpress analytics