OpenReader, Victorious

The OpenReader Consortium was formed in early 2004 as a grass-roots effort to foster the development of an open, non-proprietary next-generation eBook standard, based on and addressing key limitations of the then-stagnant IDPF OEBPS. The OpenReader vision was to end the “Tower of eBabel” of incompatible proprietary formats that has plagued the nascent digital publishing industry. Recently there has been some strife between leaders of the OpenReader effort. One of them, David Rothman of TeleRead, has suggested that I speak out on the OpenReader situation, inviting me to post on the teleread site (this article may appear there in slightly edited form).
Well, in my book, the squabbling amongst OpenReader folks obscures the real point. OpenReader can justifiably take a bow and declare victory on its initial goals. OpenReader acted as a major kick in the pants to a revitalized IDPF organization, which has in the last year finalized a container packaging standard and released a working draft of the next version of OEBPS, all very much in line with the format-related aspects of the original OpenReader goals, and benefiting from participation of key OpenReader leaders including Jon Noring. Proprietary reflow-centric formats (Mobipocket, .LIT, eReader, Sony BBEB, etc.) are on the verge of becoming obsolete. So the “threat” of OpenReader forking a dormant OEBPS is no longer necessary, and could only make the Tower of eBabel worse.
As Chess great Aron Nimzovich said, “the threat is stronger than its execution”. This principle also implies not sticking with the same threat longer than necessary. What I see as the real core value of OpenReader is a thoroughly independent perspective, a mindset that is inherently (even overly) suspicious of large corporate interests, be they large publishers or large tech vendors. Whether a group be industry-specific, like IDPF or OMA, or broad-based, like OASIS and W3C, commercial interests are generally going to be at the forefront. So speaking as an individual who wants to see digital publsihing blossom, rather than as an Adobe employee, I see the value to the open standards ecosystem of the kind of “irritant” role that OpenReader has played. There are clearly other areas in which OpenReader could stay relevant and constructively agitate for progress, including open source implementations of the new open standards, and the interoperable “friendly DRM” that David, Jon and others have often mentioned (but never detailed).
So how about we (OpenReader leaders and fellow-travellers) declare victory with respect to the base content format – maintaining vigilence with a skeptical eye towards the IDPF and other standards groups – and move on to focus on these other areas, and foster yet more progress towards a future in which all published content is reliably available in digital form?

3 Responses to OpenReader, Victorious

  1. bowerbird says:

    that’s a very zen-like tactic, bill, to
    “declare victory” for your competitors
    in such a way they give up the “threat”,
    and allow you to keep all the marbles.
    but some of us people out here want
    a solution that’s not bloated, and
    x.m.l. is nothing if not bloated…
    further, when we say “human-readable”,
    we don’t mean “after you have clawed
    your way through a morass of tags…”
    we want books that — when you select
    “copy” — you get something _out_ that
    retains the formatting that went in.
    we want e-books that’ll work superbly
    even on trailing-edge machinery, and
    simple authoring-tools that will too.
    finally, we’re not looking for some
    “gentle” kind of d.r.m., but rather
    we’re looking to create a world that
    is smart enough to know open books
    — and by that i mean books that can
    be opened by anyone picking them up,
    _exactly_ like books printed on paper —
    are what made our world what it is now.
    if/when you can deliver us all _that_,
    then _you_ can “declare victory”, bill.
    but until then, we will keep looking…
    because we believe that when the world
    “decides” on “the” format for e-books,
    it will be _our_ format that wins…
    -bowerbird

  2. Bill McCoy says:

    bowerbird,
    Who is the “we” in your post that reject XML for eBooks, and what do they have to do with OpenReader, the subject of my post?
    OpenReader folks started with the goal to create an open *XML-based* format, and all of their work-in-progress was derivative of OEBPS, which is an XHTML-based XML schema.
    That XML is bloated is inarguable. But, neither ASCII nor Unicode is particularly efficient at conveying information, and at the end of the day they are all “strings of bits” that require computer intermediation to be human readable. JPEG and HTTP are far from optimal either, etc..
    Avoiding technical religion, my view is that (like ASCII, Unicode, JPEG, RSS, HTTP, TCP/IP), XML has reached the “QWERTY position” – it is sufficiently established as to no longer make its technical merits or otherwise the primary factor in whether to use it.
    If we were going to support a non-XML eBook format, I would look to the Wikibook model as a possible solution, and one which could supplement an XML format suitable for professionally-published eBooks, not compete with it.
    But even the Wiki world, which started with a simplified (to be “directly” editable) pseudo-XML-tag model, is rapidly moving towards WYSIWYG editing and cross-Wiki interoperability based on XHTML. IMO the real value of Wikis is community editability and immediate page creation, not BBEdit-ish syntax.
    If a Wiki-centric eBook format is necessary, and it can’t be XML, then I agree we can’t declare victory on that front as yet. But, this has nothing to do with OpenReader.

  3. bowerbird says:

    > Who is the “we” in your post
    i was using the “royal we”, bill. :+)
    > what do they have to do with
    > OpenReader, the subject of my post?
    nothing.
    and that’s precisely why we
    don’t accept your conferring
    on them the title of “victorious”.
    > OpenReader folks started with
    i’m aware of jon noring’s history.
    > That XML is bloated is inarguable.
    at least you refuse to deny stark reality,
    which is a good start… :+)
    > But, neither ASCII nor Unicode is
    > particularly efficient at
    > conveying information
    they might be more “efficient” than you think.
    > and at the end of the day they
    > are all “strings of bits” that
    > require computer intermediation
    > to be human readable.
    more stark reality. that’s good.
    our point of difference here is the
    complexity of that intermediation.
    > Avoiding technical religion,
    > my view is that (like ASCII,
    > Unicode, JPEG, RSS, HTTP, TCP/IP),
    > XML has reached the “QWERTY position”
    > – it is sufficiently established
    > as to no longer make its
    > technical merits or otherwise the
    > primary factor in whether to use it.
    interesting that your analogy uses
    an interface that was _designed_
    to be as inefficient as possible,
    so as to slow typists down…
    > If we were going to support a
    > non-XML eBook format, I would
    > look to the Wikibook model as
    > a possible solution, and one
    > which could supplement
    > an XML format suitable for
    > professionally-published eBooks,
    > not compete with it.
    well, yes, wiki format is a start
    in the right direction of the model
    that i’m talking about…
    you would be better to look at
    “markdown” instead, however —
    plain-text writing that is morphed
    into xhtml for web-presentation.
    and yes, you are entirely correct that
    — for now anyway — this is merely
    a “friendly” front-end for final xml.
    but what happens when the code that
    converts a markdown file into xhtml
    is absorbed into the browser proper,
    so plain-text files can be posted and
    that markdown code makes ’em pretty?
    the xhtml will be seen as a middleman,
    who should do his job quietly without
    bothering us with his complexity, or
    a need to “transform” our files for him.
    > But even the Wiki world, which
    > started with a simplified
    > (to be “directly” editable)
    > pseudo-XML-tag model, is rapidly
    > moving towards WYSIWYG editing
    > and cross-Wiki interoperability
    > based on XHTML.
    i’m in favor of letting the computers
    talk to each other in xml if they want,
    i just don’t want them demanding that
    _us_humans_ use it too. i want my text
    to be free of markup when i edit them,
    yet still be quite beautiful when displayed.
    (not to mention maximally functional too.)
    > IMO the real value of Wikis is
    > community editability and
    > immediate page creation,
    > not BBEdit-ish syntax.
    if you value “community editability”,
    really and truly, then i believe you
    are obligated to make editing simple,
    and that means putting the xml
    “under the hood”.
    > If a Wiki-centric eBook format
    > is necessary, and it can’t be XML,
    > then I agree we can’t declare victory
    > on that front as yet. But,
    > this has nothing to do with OpenReader.
    you’re right that it has nothing to do
    with openreader. just letting you know
    that you’re now doing battle on a
    brand new “front”, as you call it.
    but, just to be clear, adobe can
    — and will, i am sure — work and
    succeed on this front. you have
    a long history of making the creation
    of electronic-books _easy_, and
    — at the end of the day — that
    is what this new revolution is about.
    -bowerbird