Thx
Roger

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.

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.

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?

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
President
OSoft.com