Universal Interoperability Council

In late 2007, an article by OASIS attorney Andy Updegrove claimed that W3C Compound Document Formats: [i] are non-editable formats; [ii] are not designed for conversions to other formats; and [iii] are therefore unsuitable as office formats. Updegrove could not have been more wrong.

But unfortunately, the erroneous Updegrove article was widely publicized by the usual occupants of the IBM cheering section ⁽¹⁾ in the stadium where the latest big vendor game for the Incompatible File Format Cup is being played, IFFC Games Stadium. ⁽²⁾

Updegrove attempted to add the ring of authority to his relevant claims with what Updegrove says are his notes of a conversation with Chris Lilley of the World Wide Web Consortium ("W3C"). While this writer cannot resolve whether Lilley gave Updegrove erroneous information or Updegrove simply misunderstood what Lilley said, the conclusion that CDF-conformant formats cannot serve as a replacement for ODF (or for that matter OOXML) is certainly an error. ⁽³⁾

Editability — Updegrove attributed to Lilley a statement that "you could only view, and not edit the output." The statement conflicts irreconcilably with a definition in the CDF Compound Document by Inclusion framework draft's conformance section, defining the "conforming authoring tool" class of products.

But more importantly, the claim of non-editability clashes with reality. E.g., the JustSystems XFY implementations of CDF are designed for editing purposes amongst others. The Basic edition is a Java-based free download and runs on Windows, Linux, and the MacIntosh. I invite Updegrove to take the XFY WYSIWYG blog editor for a test drive and then revisit his position that CDF-conformant compound documents are non-editable.

In truth, it defies all informed credibility to claim that CDF-conformant markup languages are non-editable. The various markup languages already combined in the various CDF WICD profiles are all written in plain text ASCII. Electronic documents using ASCII-based markup languages can be edited with tools as crude as Windows Notepad.

To suggest that XML and other ASCII text-based markup languages cannot be written by more sophisticated editors in effect denies the existence of familiar tools such as Microsoft Office, OpenOffice.org, WordPerfect Office, and Lotus Symphony — to name but a few — all of which write to various flavors of XML.

Shorn to essentials, Updegrove in effect argues for the existence of some sort of immaculately conceived data, that data cannot be generated by software editing tools if a homo sapiens operating a keyboard is somehow involved. The existence of his own article on a web page marked up with HTML and CSS argues otherwise, unless one were to posit that Updegrove's article was the product of a automated virtual instantiation of the proverbial infinite number of monkeys. CDF formats are as editable as any other ASCII-based formats.

Conversions — Updegrove hedged somewhat on this issue, attributing a statement to Lilly that the "CDF working group was not chartered to achieve conversion between formats." But one might as well argue that because claw hammers were designed to drive and pull nails they can not be used to hit anything else.

The truth of the matter is that CDF's framework was explicitly designed for creating compound documents from XML formats and one of the hallmark features of well-formed XML languages is easy transformability to other XML languages. See e.g., Wikipedia XSL Transformations article.

Dependence on WICD profiles — The Updegrove article buttresses its claim that CDF is unsuitable for office file formats with a statement attributed to Lilley that W3C Web Intregration Compound Document ("WICD") profiles would have to be used. But what Updegrove failed to grasp is plainly stated in the WICD Core 1.0 specification's discussion of its relationship to other markup language specifications within the Compound Document Framework:

The Compound Document Framework is language-independent. While it is clearly meant to serve as the basis for integrating W3C's family of XML formats within its Interaction Domain (e.g., CSS, MathML, SMIL, SVG, VoiceXML, XForms, XHTML, XSL) with each other, it can also be used to integrate non-W3C formats with W3C formats or integrate non-W3C formats with other non-W3C formats.

To suggest that only W3C WICD profiles can be used with the Framework either flows from or is an appeal to ignorance. There is no wiggle room between those two conclusions. Indeed, an article linked from the W3C Compound Document Formats public home page recounts a history of broad implementation of the framework without using WICD profiles since the framework's introduction in 1995, including its implementation in Microsoft Powerpoint.

Moreover, the Framework's criteria for exiting candidate recommendation status to full recommendation status mentions WICD as only an example of a conforming profile:

• at least one profile conforms to this Framework (ex. WICD)

I suspect that Lilley may have discussed both profiles and WICD profiles but Updegrove did not understand that the latter is but a subset of the former. Or it might conceivably be that Lilley has fallen into the habit of carelessly referring to all profiles compatible with the Compound Document by Reference Framework as WICD profiles.

While the Framework specification does require that markup languages combined to create conforming documents be profiled following strict rules, there is no requirement that the profiles thus used superset one or more of the WICD profiles. It may be preferable to do so for purposes of compatibility and interoperability with web applications, but to repeat, that is not required.

In fact, virtually any plain text-based markup language that can be profiled can be used within the structure of the Framework. But more importantly, a combination of cutting edge W3C markup language versions such as XHTML 2.0, CSS 3.0, XForms, SVG, etc. can, with only trivial extensions, serve as the full-featured metalanguage superset every expert who has spoken to the subject agrees is necessary to convert between ODF and OOXML with high fidelity.

For example, see the conversation in the comments section of this weblog article between Patrick Durusau (ODF TC) and Rick Jelliffe (OOXML advocate), discussing the need for an intermediate "super format" with "standard abstractions" (more commonly referred to as "profiles") ⁽⁴⁾ for exchange of documents between ODF and OOXML. ⁽⁵⁾

What CDF has — and both OpenDocument and Office Open XML lack — is: [i] a proven and fully specified interoperability framework; [ii] developed from scratch as a vendor-neutral framework; and [iii] interoperability conformity requirements that fully satisfy the ISO/IEC JTC 1 Directives (PDF) requirement that:

Standards designed to facilitate interoperability need to specify clearly and unambiguously the conformity requirements that are essential to achieve the interoperability.

ODF and OOXML are designed for easy vendor-specific extensibility useful in Feature War plays executed by the big vendors in the IFFC Games. They are most emphatically not designed for interoperability of implementing software. They are designed for one-way interoperability at best, what IBM vice president Bob Sutor refers to as intraoperability as opposed to interoperability and what the European Community's Court of First Instance refers to as an antitrust violation. ⁽⁶⁾

There are strong reasons to suspect that the ultimate winning formats will not be decided in the Incompatible File Format Games. While we are still at the dawn of a new era of ubiquitous networking, there is enough light to identify interoperability as a fundamental requirement in the new era. An interview with Corel WordPerfect Office product manager Jason Larock is enlightening in that regard:

The evolution of text on the Internet along with the use of Web 2.0 applications is starting to have an impact. It is becoming a contest between a desktop presence and a Web-based format, according to Larock. He compared the situation to the transition from analog to digital formats in the telephone industry.

…

However, if there is going to be a document standards battle, CDF will gain a strong following, Larock believes.

Software architect Kurt Cagle also "gets it" when it comes to CDF:

Already, the number of HTML documents that exist dwarf (by a few orders of magnitude) the total number of Microsoft Word documents. As editing increasingly moves onto the web, its safe to say that the document of choice will be neither ODF nor OOXML, both of which gain their power on the basis of supporting legacy word processing systems. Instead, what seems to be emerging from the W3C is something that is not an office suite because it didn’t evolve from one, but that nonetheless is capable of most if not all of the same functions that office suite documents pose.

Moreover, if you come to realize that XHTML by itself is NOT the only targeted compound document (indeed, the specification is rather clear that it is intended to be extended to other formats, from XSL-FO to DocBook to the aforemention ODF or OOXML) then what becomes clear is that the ability to integrate content itself can be standardized, and like many other W3C formats, this move to the metadata level may very well provide the necessary differential to make the technology succeed in even the most competitive of milieus.

So, don’t worry - if you’re not using CDF yet … you will be.

Another article linked from the W3C CDF public home page written by Jon Udell in 2005 concludes, "arguing about whose XML format should be the office document standard feels awfully retro. Instead, let’s reinvent the office suite for a networked world."

ODF and OOXML are designed for apps from the sneaker net era. Do we choose formats designed for the dinosaurs or formats designed for tomorrow's needs? ODF and OOXML are about the past; CDF is about the future. And yes, there are fully interoperable editors in that future.

To sum up, it is quite simply incorrect to suggest that CDF-conformant markup is non-editable and somehow inherently unable to be written by office productivity software. To hint that compound documents that conform to the CDF Framework categorically cannot be converted to other formats is equally preposterous.

Andy Updegrove is my personal friend, but he got this issue wrong from start to finish. Here's to a fresh start, Andy.

End notes

1. For example, Groklaw's Pamela Jones pushed the Updegrove analysis to hilarious heights, charging that this writer and two associates were "Microsoft reps" spreading "FUD" (Fear, Uncertainty, and Doubt) about OpenDocument by calling public attention to the enormous interoperability advantages of W3C XML standards over OpenDocument and Office Open XML. Of course that is heresy to those who approach OpenDocument with an ideological or financial motive, as an end in and of itself.

Despite Jones' dedication to Free and Open Source Software ("FOSS") principles, she seems more than somewhat challenged by the FOSS concepts that "a thousand eyes make all bugs shallow" and that bug reports are a Very Good Thing, at least when it comes to OpenDocument.

2. For the less informed, the IFFC Stadium is sometimes referred to as ISO/IEC/JTC 1. The Incompatible File Format Cup ("IFFC") is a virtual trophy awarded to the big vendor whose incompatible electronic document format achieves monopoly status along with its implementing software.

The IFFC Games began more than three decades ago, with Microsoft Corp. the first winner. However, evolution of a strong market requirement for XML-based office productivity software formats sparked an incompatible file format challenge to Microsoft by Sun Microsystems and later by IBM after Sun switched sides mid-game. A record large audience forced the hasty transfer of the game to ISO/IEC/JTC 1 with its much larger seating capacity for the championship round and that stadium's rechristening as the IFFC Stadium.

3. The Updegrove article also includes numerous other errors not discussed here because of their lack of relevance to the issue discussed in this article, such as his source's information that the OpenDocument Foundation's reason for ending its support for OpenDocument was based on a single anti-interoperability decision by the ODF Technical Committee. The history of the ODF TC's anti-interoperability maneuvers will be visited in future articles.

4. Of course, the perceived need for an intermediate metalanguage blinks past the more important question: Why bother writing to ODF or OOXML if existing applications can be reprogrammed to write directly to CDF profiles? I.e, both OpenOffice.org and Microsoft Office are fully capable of being adapted fairly easily to reading and writing to a shared CDF interoperability profile using their respective native file support APIs. Writing to ODF or OOXML simply creates a need for an intermediate processor to convert to and from the metalanguage. It would seem more efficient to skip the intermediate process, bypass ODF and OOXML, and simply write to the "metalanguage."

5. Durusau's suggestion in the linked conversation that not everyone needs interoperability and his vision of a web service for performing document conversions are perhaps somewhat biased by his employment. He works for a group of developers whose IT systems perform server-side conversions of documents for enterprise publication, content, and archive management systems.

To suggest that not everyone needs interoperability, in this writer's view, is but a corollary to the widely publicized punt made recently in the IFFC Games, the claim that competing incompatible standards are a Very Good Thing. The benefits of interoperability are multitudinous, including: [i] increased competition in software quality and service; [ii] lower software acquisition and maintenance costs; and [iii] reduction of cyberspace pollution with incompatible file formats.

6. E.g., ¶ 226:

"Thus, as the Commission explains … the 10th recital to Directive 91/250 … does not lend itself to the 'one-way' interpretation advocated by Microsoft. On the contrary, as the Commission quite correctly emphasises … the 10th recital to Directive 91/250 clearly shows that, by nature, interoperability implies a 'two-way' relationship in that it states that 'the function of a computer program is to communicate and work together with other components of a computer system'. Likewise, the 12th recital to Directive 91/250 defines interoperability as 'the ability to exchange information and mutually to use the information which has been exchanged'."

(Citations to Commission briefs omitted.) Compare the last quoted sentence with JTC 1 Directives, pg. 145:

… interoperability is understood to be the ability of two or more IT systems to exchange information at one or more standardised interfaces and to make mutual use of the information that has been exchanged.

Neither ODF nor OOXML specify a "standardised interface" nor the conformity requirements essential to achieve "mutual use" of data. CDF does both.