Linux Foundation: OOXML is Too Long to Be a Standard

In the wake of curious surges in the memberships of national standards bodies, as well as the ISO, prior to upcoming votes to recommend or approve the adoption of Microsoft's Office Open XML as an international standard, the Linux Foundation today pleaded with voters worldwide (both old and new) to listen to reason before making their decisions. But the reasons they're giving have been heard before, and may not be enough to suppress the sudden surges of support for OOXML among national bodies' swelling ranks.

"The Linux Foundation is not only familiar with, but has a vested interest in the preservation of the validity and integrity of the global standards adoption process," writes the Foundation's marketing director, Amanda McPherson, in a statement released today

Because the use of proprietary formats jeopardizes users' assurances that they'll be able to continue to use existing documents well into the future, McPherson goes on to argue, "it is important for effective and robust document format standards to be developed, and for those standards to be universally adopted."

She then adds, in a gentle reminder that may - or may not - make new entrants to the standards process feel a little guilty, "In order for universal adoption to be achieved, it is equally important for the process that creates those standards to be above reproach."

The number one problem with the OOXML specification as it currently stands, McPherson writes, is that it "is extremely lengthy." Members won't have time to review the specifications with an eye toward their technical integrity or efficiency (especially those who joined yesterday). Those who have taken the effort have discovered that the specification makes numerous references to Microsoft's own internal specifications, she said, which leads to questions over whether Microsoft will ever make that information public.

A Linux Foundation blog post today that references McPherson's statement also directs readers to study a position paper published by Google (PDF available here), which brings up the argument that the world already has one document standard and doesn't need another one - that multiple standards that address the same function are bad.

"If Microsoft wishes to create a document format that is better able to address the problems of the many editable legacy documents created in their older proprietary formats," that statement reads, "Google welcomes them to help extend the existing ODF ISO standard, in order to add the capabilities they require. Allowing OOXML to become a parallel ISO standard will propagate the current legacy situation into what is supposed to be a solution to the problems of long-term document storage."

Granted, the whole issue of document format standardization around something produced by Microsoft has brought a number of new players into this debate, for any number of reasons. But a number of misconceptions may have followed them into the ring, as standards activist and O'Reilly author Rick Jelliffe pointed out earlier this month.

In June 2000, in a completely different realm of endeavor - specifically, two-dimensional barcodes - the ISO was able to approve a patented specification from a proprietary company as an international standard (ISO 18004) even though another standard (ISO 15438). The newer standard's inventor, the Japanese company Denso Wave, maintains that its specification meets the international requirements for openness based on this promise alone: "QR Code is open in the sense that the specification of QR Code is disclosed and that the patent right owned by Denso Wave is not exercised."

The Linux Foundation recommends that standards bodies voters register their impressions of OOXML as "No, with comments," or their local equivalent. The reason, the Foundation's Andrew Updegrove stated today, is not to dump or throttle the specification entirely, but "in order to ensure that any resulting specification will meet minimum quality standards."

© 1998-2014 BetaNews, Inc. All Rights Reserved. Privacy Policy.