Adobe exec on Sony BBeB format vs. a true consumer standard: A litte hope

Adobe“Assume the industry successfully establishes an XHTML-based reflowable document format based on the evolution of OEB, with an associated single-file container package with pluggable DRM, then I see no strong raison d’etre for Mobi, BBeB, or any of the other OEB-derivative eBook formats to hang around forever. That doesn’t mean BBeB will go away overnight and indeed Sony has discussed taking steps to make it more open and accessible, but in the long run I believe the momentum behind interoperable XML-based formats is unstoppable.” – Adobe exec Bill McCoy. Related: MobileRead reaction.

3 Comments on Adobe exec on Sony BBeB format vs. a true consumer standard: A litte hope

  1. Bill McCoy is right on here. I’ve studied the reverse-engineered BBeB Xylog format (which is essentially an “all-in-one” or “serialized framework” UTF-16 XML document) and agree with his assessment.

    From my perspective, BBeB Xylog lacks the power, flexibility, and features-enabling capabilities that rich XML-based frameworks, such as OEBPS and the proposed OpenReader Framework, give us.

    One always has to look in the crystal ball, and ask: “What are all the powerful features — and cool things — that we’d like to enable in digital publications? Which make ebooks much greater and more useful than their dead-tree counterparts?” This is what the original OEB working group did in 1999, resulting in the OEBPS 1.0 specification.

    Unfortunately, it appears Sony never bothered to study OEBPS and ask the experts why it is structured as it is. The answer to that question may have led Sony to embrace OEBPS, or at least something close to it (possibly “serialized” into a single XML document as the current BBeB format is, but at least better.)

    Now to comment on Bill’s mention of XHTML. XHTML (including the upcoming XHTML 2.0) is actually a fairly poor markup vocabulary for books and most other digital publications. Other and better content document vocabularies are possible, such as selected subsets of TEI and DocBook, Digital Talking Book, the intriguing FictionBook 2 (the portion which marks up the content itself), and specialized vocabularies such as NewsML.

    One goal I’ve had in improving OEBPS 1.x for the OpenReader Framework is to extricate OEBPS from its tangled reliance on XHTML, so that in the future other markup vocabularies may be natively recognized and used side-by-side to the “Basic” XHTML. (An unforeseen benefit of OEBPS is that its “out-of-spine” construct now makes it much easier for OEBPS user agents to natively support vocabularies which include inline annotative markup such as the TEI <note> and DocBook <Note> elements.)

  2. The FictionBook 2.0 format provides for out-of-spine notes without being based on A) the OEBPS model or anything like it, B) the XHTML vocabulary, or C) the multiple-file construct provided for within the OEBPS.

    It uses the single-file serialization that the XML spec provides for inclusion of binary files and doesn’t seem to have any of the problems that Jon seems to associate with the single-file approach.

    Also, Jon seems to argue that including other markup vocabularies is a better idea than relying on XHTML, but OpenReader shouldn’t do that, instead deferring that to the future. As I suggest in “The really open reader,” the arguments against XHTML apply to any and all predefined vocabularies and the only solution is for OpenReader-compliancy to require acceptance of any vocabulary, perhaps along with some required additional information.

    And unlike Jon, I don’t think you need to defer this step to some indeterminate future. I propose only what is achievable already.

  3. Kailie Quinn // May 12, 2008 at 3:12 pm //

    On the contrary, McCoy is a fool. And not really the fool he claims to be. He doesn’t care about the open source community, just about being on their good side. XML is a very verbose format, which would be a very negative thing on devices like these which have limited data.

    PostScript, BBeB and mobi all have data minimal layout languages that don’t require extensively verbose schemas or background processes to interpret.

    You’re thinking too smart phone and not enough AS400.

Leave a comment

Your email address will not be published.

*



wordpress analytics