Sun's McNealy Proposes Merging ODF with Chinese Counterpart
In a trade conference convened earlier this week by the Chinese Ministry of Commerce, Sun Microsystems Chairman Scott McNealy suggested that what he described as the world's #2 and #3 office document formats - OpenDocument Format (ODF) and the Chinese standard Uniform Office Format (UOF) - could go up against the #1 format from Microsoft more effectively if they were to be merged.
The news comes from Andy Updegrove, a respected Massachusetts attorney and a member of the board of directors of the Linux Foundation, who is a featured speaker at this conference and who attended McNealy's keynote speech. As Updegrove reports on his ConsortiumInfo.org blog, McNealy's suggestion appears to be the first signal made by any ODF proponent of that side's willingness to partner with one of Asia's burgeoning business standards.
The concept of "harmonization" between the two formats is not at all new, however; representatives of government, industry, and higher education in China have all actively pursued the idea. In November 2005, the Open Standard Lab of Beijing University commenced a one-year study into the possibility of fostering a technological and social harmony between the proponents of both open formats.
The results of that effort, published the following October, were - like Chinese poetry - subtle, balanced, and yet profound at the same time: After having met with ODF architects and representatives of IBM, the Lab concluded that a degree of harmony was attainable through "bi-directional conversion between the ODF and UOF document formats."
But that conclusion stopped well short of suggesting a merger of the formats. The reasons for this may be found in a Lab document comparing the two format's respective schemas for purposes of creating a conversion plan. Without making the argument directly, the document could lead knowledgeable people to the conclusion that UOF was the superior format.
One reason has to do with the formats' allocation of their respective namespaces. The Lab described the UOF schema as being much more structured, replete, and flexible, while certain parts of the ODF schema seem more arbitrary.
While the XML of ODF documents put styles, layout elements, and appearance properties first and foremost, the UOF document structure is based more around function and context. Hyperlinks and embedded objects in UOF are actually given first-tier precedence, rather than actually being embedded within the body section, as in ODF. As a result, the precedence differences between the two formats make translation extremely difficult, though as the Lab later concluded, not impossible.
For instance, every UOF document makes a first-order distinction between text, presentation, spreadsheet, graph, and math data. Think of a UOF document as universal across all applications in its office suite, so its spreadsheet and its presentation graphics application essentially produce the same XML document, when viewed in terms of first-order categories. Thus, a layout element description for something like a "table" might be completely different for the spreadsheet section of a UOF document than a "table" for the text section, and the two descriptions could co-exist within the same document.
Meanwhile, "text" and "table" are first-order categories in ODF, so the contents of a table could pertain to the word processor document or to the spreadsheet portion - same table, different contents. For ODF, the application is called upon to map the table properties to whichever program in its office suite happens to be open at the time.
"Different with ODF, UOF schema redefined many elements in [a] different namespace," the Beijing University Lab concluded. "And some of the element is limited to use in particular type of document... So it is hard to set up a mapping of namespace between ODF and UOF. And for some namespaces imported into ODF, there is no corresponding element in UOF."
Furthermore, there's a contextual gulf between the mindset a UOF document would have its developer adopt, and that of an ODF developer, the Lab demonstrated. What ODF utilizes as an attribute of an element - for instance, underlining, boldfacing, highlighting, or embossing - is treated by UOF as an element unto itself. So while ODF is limited to 40 attributes, UOF has at least as many corresponding "sub-elements" whose descriptions map themselves to locations in the body of the document, like "highlight-ers" rather than "highlight-ing."
Because of this, the UOF document format is more open to amendment by new and different types of sub-elements, without having to convene an international consortium to pull it off.
The Lab's document refrains from any and all directly subjective arguments with regard to the quality of the two formats. But the demonstrations and the accompanying diagrams achieve a result as striking as Prof. Feynman dumping NASA's O-ring into his ice water: They make it clear that any "harmonization" that takes place between UOF and ODF should not try to muddy the waters for the Chinese version, whose underlying principles are both transparent and convincing.
So why is McNealy making this pitch now? Updegrove notes that McNealy was personally invited to this conference, so his proposition may not be entirely unilateral. While plug-ins may be employed for both format's respective suites to enable them to save to, or convert to and from, one another's format, Updegrove does foresee the possibility of a merger of formats, which Chinese officials apparently concede is technically possible.
But the motivation for such a merger may have zero to do with increasing market share, Updegrove believes, and instead "may have a lot to do with China's overall strategy, which for the last several years has been oriented towards developing 'home grown' standards in areas where high foreign royalty payments, or product prices, would otherwise be encountered."
In other words, perhaps - just perhaps - China perceives this as an opportunity to leverage its patent portfolio. ODF vendors owing royalties to Chinese concerns could become the wildest twist in the history of the open source movement's most prolific format.