Open or closed? The ODF debate spills into LinuxWorld

Open or closed? The ODF debate spills into LinuxWorld

Well, at least author Jack Loftus got the title right. This discussion is all about an Open XML file format wrapper for Open XML technologies. MSECMAXML is an open XML wrapper of closed proprietary technologies. Calling MSECMAXML "Open XML" or Office Open XML" is dishonest and intentionally misleading. Here's why. First of all the W3C is the inventor and owner of Open XML technologies. They developed those technologies so that XML and RDF would succeed HTML and greatly extend the value and effectiveness of the Open Internet.

Second, the official name of the original 2002 Open Standards effort was "OASIS Open Office XML", not OASIS OpenOffice XML (which is the original name of the XML file format specification when it was submitted to OASIS in 2002). The OASIS Open Office TC (Technical Committee) changed the name from "Open Office XML" to "OpenDocument" at the request of the EU. Yes, that's right. The EU requested the name change in response to continual complaints from Microsoft. The EU had determined that their long term SOA future depended on Open Standards and Open XML technologies. They also recognized the incredible value of having one XML file format that could cover most if not all of their information needs, directly or through extremes of interoperability and clean transformation capabilities. Microsoft refused to support and implement a file format named after the only possible threat to their MS Office cash cow, the cross platform and open source OpenOffice.org productivity environment.

So far this makes sense. No one would blame Microsoft for that complaint. If only that were the end of the story. Hardly. We know now that Microsoft was beyond disingenuous in their demands for a name change. Within four days of the EU request, the OASIS Open Office TC changed the name to "OpenDocument XML", which was unceremoniously hyphenated to "ODF" by über analyst Stephen O'Grady of Redmonk. The name "OpenDocument" comes out of the Valoris Report. This was the fictional XML file format they used in their projections and use case discussions to demonstrate how critically important an Open XML file format would be. It's also important to note that the Valoris Study identified complete separation of the file format from application and systems specific software dependencies as a most important characteristic. They provided the EU with a definition of Open Standard and Open XML that includes this "separation". And so it is that the first universal file format was described: one able to address the needs of desktop productivity, publishing, content management, archiving, SOA interoperability, and Open Internet use. One that would be good for the next 200 years. So what does Microsoft do? They change their XML referencing from WordML to MSXML. Which changed again to "Office Open XML" when they submitted the specification to their hand picked ECMA workgroup.

Hummm. Let me see. It looks to me like they wanted the name "Open Office XML" to disappear so they could glom onto "Office Open XML". I refuse to bite. For me the only accurate description of this application bound and platform dependent XML wrapper is "MSECMAXML". One company in control. One iron fisted standards process posturing as "open" with a charter specifically stating the intent is to make “MS Office Open XML” a standard. One implementation, and that isn't available yet.

But hey, it is XML. Mr. Loftus does have a great line when he asks, "Do users know the difference between the open standards-based OpenDocument format (ODF) and proprietary ones like Microsoft Office Open XML?" I wonder if he was laughing when he wrote that? Some other points in the article ruffled me a bit. Here's one by John Walker of Versora, "Office Open XML was designed to be sensible, Walker said, while ODF was designed to be open. Microsoft's offering is also a more robust platform compared to ODF's less complex model. "Microsoft has thought a lot about document recovery [with Office Open XML]," he said. Wait a second, MSECMAXML was designed to meet Microsoft's needs. Yes, if you're Microsoft it is very sensible. I f however you are a Microsoft consumer quite happy with your current MS Office investment, this becomes a sales pitch to upgrade your existing productivity environment to WinXP-Vista and MS Office 12. The bonus is that you get to take all your MS Office bound information with you.

I think that is what Mr. Walker means when he says, "Microsoft has thought a lot about document recovery". In an interesting article titled, "Corporate Alzheimer's: Coping With Forgotten File Formats", John Walters quotes from Microsoft's Brian Jones, lead program manager for the Office suite. "It's true that the feature set Open XML enables is a reflection of the Office feature set," he says. "We had to go with a format that was, from the ground up, designed to support all of our legacy systems." Yes, MSECMAXML was designed specifically for MS Office 12, and designed so that the legacy of MS Office file formats can be transitioned forward. Don't think for a moment that your trusty MS Office 98 or MS Office 2000 application suites will be able to read/write MSECMAXML. You can bet your bottom dollar that a massive hardware-software upgrade to XP-Vista is in your future if you decide on MSECMAXML. Oh, did i mention that you can have all the collaborative computing features of an OpenDocument ready environment today - without upgrading anything? Just download the cost free no procurement hassle here OpenOffice.org - Mozilla.org combo, and make that leap into the future. The vendor support discussion in this article was very misleading. Yes, ODF does have a broad range of support with over 30 vendors now in the market with ODF ready products and services. There is explosive activity in the emerging Web 2.0 sphere, with AJAX, XUL, DocVert, and XForms ODF type services and solutions proliferating. But this part is misleading, "Walker also pointed to differences in vendor support. With Microsoft, the support is deeper, as studies show Office still in control of 95% of the office applications market." Why? The 95% of the applications market cited could be running ODF today with a simple, cost free download. But they certainly are not running MSECMAXML! It's not even available for the most advanced XP MS Office systems out there, (of which there are comparatively few installs), let alone the massive installed base of Win98, Win2K, and WinXP 2003. The monopoly base is simply not an advantage to Microsoft here. It's an advantage to ODF and the easy to download and install today OpenOffice.org - Mozilla.org productivity environment. It's an advantage to gWritely, ajaxWriter, DOJO, Apache, and MediaWiki.

For Microsoft this is one of the most serious problems they have ever faced; how to compel and force march over 450 million Windows users to XP-Vista MS Office 12 and the promise of MSECMAXML. The good new is that you get to take all your MS Legacy Office bound information with you. Happy marching! The future is one of ever more capable, interactive, and effective Open Internet based collaborative computing. In this future XML::RDF is everything. As a means of entering into this future, one can choose either an ODF ready environment and get there today with your existing computational investments, or, wait for XP-Vista MSECMAXML, throw away your existing systems, and replace everything to become once again part of another Microsoft controlled profit stream. Is there a decision here? Let's move on to the complaints about ODF. Okay, so there isn't an ODF ready application suite as complex and bloated as MS Office 12 promises to be. But then, even though the feature set of OpenOffice.org is more focused on critically important productivity tasks and services, the re training and learning curve for the pricey MS Office 12 ought to give every upgrade pilgrim pause. One thing i would point out is that MS Office has nothing like IBM's ODF ready WorkPlace. Nada, zip, squat, buttkiss, dusted. They've got nothing that can compare to the workflow and business process - information management that the highly collaborative WorkPlace offers. And then there is gWritely, the highly collaborative WikiWare and on line document management system. Writely is able to handle .doc and ODF documents. No mention of MSECMAXML.

Given the platform specific dependencies that riddle the MSECMAXML specification, the conversion process (if it's legal) is going to be a nightmare for AJAX, XUL, and XForms collaboration services. There is the complaint in the article that ODF ready applications do not adequately address the "accessibility" needs of physically handicapped or impaired people. Following the Armonk ODF Summit, the OASIS ODF TC immediately chartered an "Accessibility" subcommittee to address this. This work is proceeding at an accelerated pace, and hopes are high to produce results by this summer - well in advance of the MASS ITD 2007 deadline.

It's interesting that the accessibility extensions being proposed for the desktop productivity environment will also work across the Open Internet as highly accessible "interactive" Web documents. These extensions are going to benefit everyone. For the accessibility challenged, the mesh of audio, visual, and peripheral sensitive extensions are going to open up a galaxy of information and collaborative participation processes they have long been denied access to. For those not directly "challenged", the benefits will be that of a massive leap in multi tasking capabilities. Those who are used to doing ten things at once are going to have the chance to up their game to twenty or thirty. The final statement in this article also caught me short, "Also on the critique docket is the fact that ODF designers limited extensions on purpose to discourage companies from making proprietary ones -- much in the same way Microsoft did with ActiveX and Java." First, I don't get the ActiveX - Java statement. With Java, Microsoft tried to secretly introduce proprietary extensions that would only work on a MS Windows JVM. The extensions were designed to break the standard JVM - all of which was a clear violation of the license agreement with Sun. Microsoft was found to have done this with the express intent of destroying Java for anyone not working off the Windows monopoly platform. I don't get how this kind of deceitfully reprehensible and contractually illegal conversion of opportunity relates to anything done by the OASIS ODF TC? I'm lost on this one. The issue of a base line implementation with proprietary extensions above the base line has long been a concern of the ODF TC. What we tried to do is embrace and implement Open XML technologies and methods within the base line so that proprietary extensions could be pushed up above the base, addressing those needs where there was no other alternative but to fork. The quality and depth of the base line defines the fidelity of interoperability and transformation. The minute you fork from the base line, the measure of interoperability and transformative quality declines. So the ODF designers try to provide markets with a volume base line that meets all of their common and expected interoperability use cases.

It's not all that hard building a volume base line. Just stick to Open Standards; open interfaces and methods, open messaging and communications protocols, and most importantly, Open XML technologies coming out of the W3C. There is no question that market categories and vertical industry implementations will need to introduce "extensions". These extensions can be proprietary or open. We hope they are open, but there are many legitimate situations where a closed or boxed set of extensions to ODF make sense - proprietary or not. Since ODF is an "Open Standard" in every sense of the term, there is no way "the designers" can "limit extensions on purpose to discourage companies from making proprietary ones..." Corel or Microsoft, or the National Association of Realtors, or anyone else can take the ODF specification and implement their own extensions and dependencies. Microsoft could go through the spec and replace HTML with MSHTML, or SVG with Sparkle. Or, they could leave the ODF dependencies in place and introduce the proprietary extensions above the baseline.

They could have done this and provided developers and information systems architects with a road map of dependency substitutions. That would have greatly eased the problems of interoperability and clean clear transformations. But they didn't. Guess what Microsoft did choose to do? Right, they chose to fork from Open XML as soon as you crack open the wrapper. What's inside a MSECMAXML file is a cascading entanglement of MS proprietary platform dependencies. It's often been said that the goal from MS has always seemed to be to replace the Open Internet with MSN. The XAML/Avalon Vista design has no support for CSS, XHTML, XForms, SMiL, DOM or SVG. This observation is further born out by the 1900 pages of the MSECMAXML specification and restrictive reference license. One way of looking at the proprietary extensions claim is to view the ODF objections of someone like OASIS LegalXML. They disagreed with the way ODF handles "styles", and instead of introducing their own proprietary extensions to get the features they wanted, they set out to invent a completely new LegalXML language. That's okay, except they now have to go out and spin up a new application sector too. XML languages are difficult to invent, monstrous to maintain, a bear to build community around, and then, when you're finally ready to introduce your efforts to the marketplace, a nightmare of arguing against the high risk investment shroud that hangs like an albatross around any new language - business process revolution. The good news is that the OASIS ODF Metadata Sub Committee will solve all the LegalXML problems in spades. The ODF LegalXML::RDF solution will make it into the next release of the ODF spec, and with it will come volumes of application and service providers ready to take on the Legal industry challenges. Will there be Legal extension's to ODF? Of course. But there will also be a volume base line and universal metadata model that will enable legal librarians and practitioners to define conceptual relationships and manage volumes of documents in ways they never dreamed possible. Let me close with this. The submission declaration and charter for MSECMAXML were extensively covered by standards expert Andy Updegrove who summarized his findings with this chilling indictment: "In summary, what I read here is the following: the working group would be told to take the offered schema and convert them, without change (or charge), into a standard, apply the EDMA imprimatur, and then submit them to ISO, so that users of Microsoft Office may seamlessly use their documents in conjunction with other conforming software, and so that Microsoft may obtain a unique market benefit. The working group would also be told not in any way diverge from this goal in order to improve the standard, or to address the needs of the users of any other products in existence, or to accommodate the functionality of any other product, or to serve the interests of any other vendor, or of any customer that has needs that cannot be served by Microsoft Office.

I would submit that such a request is not consistent with the role of a standards body, but rather the diversion of an organization created to serve the needs of an industry to the unique demands of a single vendor. Were ECMA to be based in the United States, I would not be surprised if accepting such a charter would result (if discovered by the IRS) to the loss of the standards developer's tax-exempt status. . . .

A final note: as expected, there is no mention in the charter of any special IPR requirements that would be imposed on any member of ECMA. This would indicate that while Microsoft may renew it's royalty-free commitment, any other member(s) of ECMA with a relevant patent would have the right to charge a royalty to implement the resulting standard, or to require terms that would be inconsistent with open source licensing."

Thanks Andy. Your comments should be must reading for everyone.

~ge~