Group items tagged

Frankly, from Microsoft's perspective, the danger may have been overstated. Though the free open source crowd talks a good fight, the truth is that they keep missing the real target. Instead of investing in new features that nobody will use, the team behind OpenOffice should take a page from the SoftMaker playbook and focus on interoperability first. Until OpenOffice works out its import/export filter issues, it'll never be taken seriously as a Microsoft alternative. More troubling (for Microsoft) is the challenge from the SoftMaker camp. These folks have gotten the file-format compatibility issue licked, and this gives them the freedom to focus on building out their product's already respectable feature set. I wouldn't be surprised if SoftMaker got gobbled up by a major enterprise player in the near, thus creating a viable third way for IT shops seeking to kick the Redmond habit.

How come I am the one to notice how deficient ODF really is?

The ODF-Converter translates OpenXML documents (.DOCX) to Open Document Format (.Open Document Format) (and conversely) for Open XML processing applications. You will find below the list of unsupported features which may be due to standard compatibility issues, or to the translator itself (see rendering issues as discussed in the blog)...

We wish to make it completely clear that we support DIS 29500 becoming an ISO Standard and are in complete agreement with its stated purposes of enabling interoperability among different implementations and providing interoperable access to the legacy of Microsoft Office documents.

A fatal flaw in your analysis By Marbux Posted Saturday 21st April 2007 08:15 GMT Your analysis contains a fatal flaw, Martin. That is your belief that adequate Microsoft XML <> OpenDocument translators will be available. In fact, all of the translators suck mightily and there is no prospect at all of them being perfected. The major problems are: (i) that Microsoft's XML formats seem deliberately designed to thwart their parsing with XPath, which is essential to XML transformations; (ii) that Microsoft's "XML" file formats include binary blobs, bitmasks, and multiple Windows and Microsoft dependendencies, all of which defy XML transformations; and (iii) OpenDocument assumes a richer page layout engine than Microsoft Word provides, so while DOCX can be completely mapped to ODT it is impossible to fully map in the other direction without declaring an MS Office interoperability subset of OpenDocument and ODF applications implementing a compatibility mode with reduced features. (That is more than somewhat ironic, given Microsoft's spin that it couldn't implement all of its features in OpenDocument. In fact, the exact opposite is true.) In fact, Steve Ballmer is on record as saying that the developers of the Novell-Microsoft-Clever Age plug-ins will not even attempt to achieve full fidelity file translations between the two formats. http://www.eweek.com/article2/0,1895,2050848,00.asp?kc=EWEWEMNL103006EP17A Those translators achieve at best far less conversion fidelity than existing file conversion filters between OpenDocument and Microsoft binary file formats such as the OpenOffice.org conversion filters, which achieve only about 80 per cent fidelity. The file format cognescenti know this. See e.g., the paper by Gary Edwards and Sam Hiser included in this edition of the European Journal for the Informatics Professional. http://www.upgrade-cepis.org/issues/2006/6/up7-6Hiser.pdf (PDF). (Note that I contributed to that paper.) And as also detailed in that paper, what works well enough for some of us does not necessarily work well enough for all. Anything less than full fidelity data conversions is absolutely unacceptable in the context of wholly automated business processes and is in fact illegal in various contexts, including government records. So your thesis doesn't fly. In fact, I'd go so far as to bet that you have been suckered by the Microsoft spin doctors. Another indication is your depiction of the file format wars as being waged primarily between IBM and Microsoft, a recent theme of Microsoft's public relations machine. While it is seductive to believe that the controversy is just another chapter in the war between major competitors, the pro-ODF camp is far broader than IBM. For example, nearly 20 governments recently opposed fast track processing of Microsoft's draft standard at ISO. Do you believe they were all carrying water for IBM? Government bodies in more than 50 nations have chosen to adopt ODF. http://opendocumentfellowship.org/government/precedent And dozens of developers now support the OpenDocument standard in their applications. http://opendocumentfellowship.org/applications While IBM has had a noteworthy role in proliferating the OpenDocument formats, there is a movement without a recognizable leader in the industry. When it comes to vendor influence on things relevant to ODF, Sun Microsystem's far outshines IBM. But in fact, a core group of open standards and free and open source developers and advocates -- inside and outside government -- have played a far larger role. This is a customer-driven phenomenon, not a vendor-driven effort as you portray. So I will respectfully suggest that you reexamine your position on these issues. Reasonable minds can differ, but not on the grounds you advocate.

We’re trying to view it as a straight business decision. What are the costs associated with one approach over another? Does it serve all of our business needs? If it doesn’t serve a business need, how do we satisfy that business need? We’re trying to view this just as a plain-vanilla, nonpartisan, nonideological issue.

SUMMARY: The OpenDocument Foundation proposes that the OASIS Office TC begin now to create an interoperability framework for inclusion in OpenDocument v. 1.2. This document, one of a series of planned proposals, proposes first steps towards a comprehensive interoperability framework and OpenDocument conformance requirements.  This proposal is designed to bring ODF v. 1.2 into compliance with current ISO Interoperability Requirements.

Sun Microsystems Inc., largely considered an avowed opponent of Open XML because of its own development and support for the competing, ODF-based StarOffice suite, found itself in the unexpected position of stating its support for ratifying Open XML -- albeit after some changes in the proposal are made.

To be fair, Microsoft seeks to solve real world problems with respect to helping customers glean more value from their information. But the approach depends on enterprises adopting an end-to-end Microsoft stack—vertically from desktop to server and horizontally across desktop and server products. The development glue is .NET Framework, while the informational glue is OOXML.

Microsoft seeks to create sales pull along the vertical stack between the desktop and server.

Microsoft's major XML-based format development priority was backward compatibility with its proprietary Office binary file formats.

This seems to me to be a turning point for the creation of global standards. Microsoft was invited to be part of the original ODF Technical Committee in OASIS, and chose to stand aside. That committee tried to do its best to make the standard work well with Office, but was naturally limited in that endeavor by Microsoft's unwillingness to cooperate. This, of course, made it easier for Microsoft to later claim a need for OOXML to be adopted as a standard, in order to "better serve its customers." The refusal by an incumbent to participate in an open standards process is certainly its right, but it is hardly conduct that should be rewarded by a global standards body charged with watching out for the best interests of all.

Xandros, the leading provider of intuitive Linux solutions and cross platform interoperability tools, today announced it will join Microsoft and other companies to build and ship open source translators between documents stored in Ecma Office Open XML and Open Document Formats. The translators, being developed through the Open XML/ODF Translator project, will be made available to Xandros users via the Xandros Networks update facility. Every Xandros product that includes OpenOffice.org will be equipped with the translators. This announcement underscores the shared view of Xandros and Microsoft that competing office productivity applications should make it easy for customers to exchange files with one another and allow them to use their operating system and office productivity applications of choice. "This is good news for customers. Xandros and Microsoft share the view that competing office productivity applications should make it easy for customers to exchange files with one another," said Tom Robertson, general manager for Interoperability and Standards at Microsoft. "Mixed system environments are becoming more common, and we believe in delivering interoperability by design for the benefit of our customers. Our ongoing collaborative relationships with commercial open source companies like Xandros help us achieve that goal." "We are delighted to join forces with Microsoft and others to provide interoperability between standardized XML document formats," said Andreas Typaldos, Xandros CEO. "The work of the world is done using various document formats as well as operating systems, so it is vital to provide our customers with the means interoperate with ease in this diverse environment."

By Marbux posted Jun 19, 2007 - 3:16 PM Asellus sez: "I will not say OOXML is easy to implement, but saying ODF is easier to implement just by looking at the ISO specification is a fallacy." I shouldn't respond to trolls, but I will this time. Asellus is simply wrong. Large hunks of Ecma 376 are simply undocumented. And what's more, absolutely no vendor has a featureful app that writes to that format. Not even Microsoft. There's a myth that Ecma 376 is the same as the Office Open XML used by Microsoft. It is not. I've spend a few hundred hours comparing the Ecma 376 specification (the version of OOXML being considered at ISO) to the information about the undocumented APIs used by MS Office 2007 that recently sprung loose in litigation. See http://www.groklaw.net/p...Rpt_Andrew_Schulman.pdf Each of those APIs *should* have corresponding metadata in the formats, but are not in the Ecma 376 specification.