CDF

I have heard suggestions that CDF (Compound Document Formats) is a good alternative for ODF or OOXML and I suppose by extension, for PDF. I want to explain a bit about CDF and connect the discussion to my last blog on Communication via Documents. CDF is a set of candidate W3C recommendations (their term for standard; candidate meaning not quite baked). One of the things I want to get to in this article is the "s" on the end of Compound Document Formats. But let start at what CDF is or isn't.

In my opinion the name CDF, in general, is a little off because these recommendations (aka, standards) are aimed at DOM processing (Document Object Model) and defining how heterogeneous web languages, when processed into a common DOM, can communicate more effectively and have more impact upon each other. To me it doesn't address "document formats" very directly. The W3C has developed a modest set of XML markup languages for various specialized forms of document content (e.g., XHML, XSL, XForms, SVG, SMIL, MathML and VoiceML  [see here for the recommendations for any of these]). The basic CDF idea is to specify how to make a unified document out of a bunch of these content types. So the first steps of defining a "format" has already been done for the components of a "W3C" compound document.

The proposed recommendation talks about a document root in a "host" language (only example XHTML) that includes subordinate content in some "child" languages either by "reference" or by "inclusion".  By reference is the most commonly used today. Web pages are put together with the host HTML page using URIs to reference images, SWF (Flash), SVG, etc.

CDF uses <object> in XHTML to reference children. Since they mostly talk about XML markup languages, then inclusion is just a matter of sucking up the child into the host XML using name spaces to distinguish which is which. Another possibility, but not discussed, is to do as OOXML, ODF, and Mars have done and use ZIP archives to collect all the document components into a single file (package). Like it or not, the CDF folks will have to face the idea that a fully self contained compound document will need: JPEG images (not in an XML markup language), OpenType fonts (not in an XML markup language), ICC color profiles (not in an XML markup language) and much more. So inclusion by "sucking up" into one XML file is not a very universal solution. Of course, they may not be interested in self contained compound documents.

The real technical content of the CDF recommendations is in details of how to glue these various (XML markup) languages together once they all have been processed into their respective DOMs. It establishes conventions for how a script might reach across DOM boundaries, how events might get propagated across DOM boundaries and stuff like that. I won't go into this any deeper because you will get more accurate information by just reading the W3C documents. But the main idea of CDF is to bring these variously defined content types into a uniform "framework" so that scripts can operate more at a document level instead of being confined to their own document child.

But one thing that is really interesting to me and that I disagree with is that they set up a "framework" for an arbitrary set of recommendations (remember that translates loosely to "standards") one for each different compound document "profile." You will find the following candidate recommendations on the website: Compound Document by Reference Framework 1.0, WICD Core 1.0, WICD Mobile 1.0 Profile, WICD Full 1.0 Profile (WI is for Web Integration). So we do not get one compound document format but an arbitrary set of formats that all follow similar rules on how things are glued together. On the surface that sounds like a nice modular approach. But what I worry about is the proliferation of the profiles in what I believe is a "Communication by Documents" scenario. Given that this is about Web/Internet documents, they are by nature communication documents. Please read my previous blog where I describe this notion and claim that that was the design point for PDF. It seems strange to me that others haven't picked up on this notion and been more conservative about defining language profiles.

So what is wrong with language profiles. Well in a communications application, where you are trying to send document information from one person in the world to another person in the world you really want a very limited set of standards that have to be followed on both ends to make the communications work. In my previous blog I talk about having red telephones and blue telephones and blues can only connect to blues and reds to reds. If you let the colors (profiles) proliferate you get a totally useless mess.

CDF seems to be on a path to institutionalize such a mess. Most of their work so far has been on the framework and that is great and is a long time coming for the web XML markup languages. But to leave the door open to multiple profiles for compound documents, and it seems like they are thinking many, is where things go astray. 

It is still salvageable if they pick one set of XML markup languages and edict that all conforming processors must process exactly this set, probably their Full profile. This has been another missing element of the web as we often get documents that do not come out correctly because we are missing some browser plug-in or other.

And of course, PDF has gotten this right!

Contact me at: jking@adobe.com