Group items tagged

Patrick Durusau, the OASIS ODF editor has written an open letter praising the OOXML standardization effort at Ecma and ISO. Patrick is a long time member of ISO JTCS1, currently serving as the ODF editor for both ISO and OASIS ODF efforts. That his endorsement of OOXML comes on the eve of the critically important February BRM is beyond incredible. Jesper offers this quote which i think adequately summarizes Patrick's endorsement: The OpenXML project has made a large amount of progress in terms of the openness of its evelopment. Objections that do not recognize that are focusing on what they want to see and not what is actually happening with OpenXML"

POI 3.5 beta 3, and Office Open XML Support (2008-07-18) now supported by Microsoft through the Document Interoperability Initiative Project (DII) The Apache POI Project is currently working to support the new Office Open XML file formats, such as XLSX and PPTX, which were introduced in Office 2007. The POI project consists of APIs for manipulating various file formats based upon Microsoft's OLE 2 Compound Document format, and Office OpenXML format, using pure Java. In short, you can read and write MS Excel files using Java. In addition, you can read and write MS Word and MS PowerPoint files using Java. POI is your Java Excel solution (for Excel 97-2007). However, we have a complete API for porting other OLE 2 Compound Document formats and welcome others to participate. OLE 2 Compound Document Format based files include most Microsoft Office files such as XLS and DOC as well as MFC serialization API based file formats. Office OpenXML Format based files include the new (2007+) xml based file formats, including Microsoft office files such as XLSX, DOCX and PPTX.

Short slide deck of Barbara Held's February 28th, 2007 EU IDABC presentation. She introduces ODEF, the "Open Document Exchange Format" which is designed to replace both ODF and OpenOfficeXML. ComputerWorld recently ran a story about the end of ODF, as they covered the failure of six "legislative" initiatives designed to mandate ODF as the official file format. While the political treachery surrounding these initiatives is a story in and of itself, the larger story, the one that has world wide reverberations, wasn't mentioned. The larger ODF story is that ODF vendors are losing the political battles because they are unable to provide government CIO's with real world solutions. Here are three quotes from the California discussion that really say it all: "Interoperability isn't just a feature. It's the basic requirement for getting your XML file format and applications considered"..... "The challenge is that of migrating our existing documents and business processes to XML. The question is which XML? OpenDocument or OpenXML?" ....... "Under those conditions, is it even possible to implement OpenDocument?" ....... Bill Welty, CIO California Air Resource Board wondering if there was a way to support California legislative proposal AB-1668. This is hardly the first time the compatibility-interoperability issue has challenged ODf. Massachusetts spent a full year on a pilot study testing the top tier of ODF solutions: OpenOffice, StarOffice, Novell Office and IBM's WorkPlace (prototype). The results were a disaster for ODF. So much so that the 300 page pilot study report and accompanying comments wiki have never seen the light of day. In response to the disastrous pilot study, Massachusetts issued their now infamous RFi; a "request for information" about whether it's possible or not to write an ODF plugin for MSOffice applications. The OpenDocument Foundation responded to the RFi with our da Vinci plugin. The quick descriptio

Technology Considerations The Microsoft OpenXml Viewer is a cross browser cross OS plugin. The core of the application has to be OS independent. Therefore, the application is developed using C++. Future possibilities The generated html from the docx file can be rendered using silverlight and similar rich platforms. The same can be used in a server scenario to render docx files as html.

Interesting project based on an XSLT "one-way" conversion from OOXML to HTML. The conversion process will break any kind of business or application specific logic embedded in the document. There is a conversion of VML to SVG that i think will be important to watch.

What's seriously lacking is a conversion or locking of scripts, macros, OLE, data - media bindings, and security settings .... the logic parts so important to any business process or productivity environment setting embedded in the original MSOffice document.

Excellent coverage of a very important interview!

Finally, someone in Massachusetts is talking and it's the master, Louis Gutierrez.  Wiki Ricki has some nice comments about the ComputerWorld interview with Louis.  As have become his custom though, Rick once again carries the flag (or should i say water) for Microsoft.  Rick's expertise in XML used to be the draw for his column.  Now you have to parse through his comments, separating the nuggets of truth from the torren of bias.  Paid bias.  It's too bad.  Rick was one of the best. 

The war is over?  When did Microsoft surrender?  And when did they sign the official terms of surrender?

The terms of surrender are simple. Microsoft must agree to fully support and implement ODF as a native file format in all versions of MSOffice qualified for the current OOXML compatibility kit. Furthermore, MSOffice must offer end users the choice of selecting ODF as the default MSOffice file format.

Those are the terms of surrender, and i for one don't see how the Microsoft or Novell Translator plugin's qualify?  These things are garbage!

What if an MSOffice user was to work on a document, save it to OOXML only to open it later to find a near totally useless and corrupted document with a conversion fidelity equal to that achieved by the hapless MCN Translator Plugins?

Right.  What's good for the goose is good for the gander.  Until these idiotic MCN Translators can achieve a conversion fidelity between ODF and OOXML acceptable to MSOffice users - comparable to native documents use and expectations, they should be regarded for what they are: an experimentation proving conclusively that OOXML is not even close to being interoperable with ODF.

~ge~

On Dec 3, Microsoft officially announced the availability of its Open XML Document Viewer, Open XML/ODF Translators Version 2.5 and the Apache POI Java SDKfor OpenXML.

A mus tread.  Carol Sliwa of ComputerWorld intervies Clark Kelso, California CIO.  ODF is the main issue, with clark casting all his answers in the context of business decisions.  Carol o fcourse is asking the best questions of any journalist alive.

Keep in mind that ComputerWorld and the Boston globe filed for the Freedom of Information Act to be invoked in Massachusetts.  They got access to all the eMail, documnetation, and conferencing notes concerning ODF  and Microsoft.  Carol's interview with Louis Gutierrez last week was filled with the same hard questions Clark Kelso fielded so deftly.

The "committee" Clark Kelso has set up to look at these issues is headed by Bill Welty, the CIO of the California Air Resources Board.  Bill is a long time opensource - Linux guy, but will be the firs tto admit that Microsoft is the only vendor providing a means of getting everything inot XML.  And that's the heart of any SOA strategy, "First, get everything into XML".

With a 500 million MSOffice desktop bound business process headstart, Microsoft has the extreme advantage in this much needed migration to XML. 

They now have their own proprietary application and platform bound version of XML; MOOXML (Microsoft OfficeOpenXML) heading for international standardization at ISO. 

They now have their XML Hub in place; the Exchange4/SharePoint Hub.  This is also an essential part of any SOA strategy.  You've got to have an XML Hub where the XML information streams and service connection to legacy black box systems can be piped into, managed and resolved.  The XML must also provide an end user interface to these information flows.  One that converges and integrates information, documents, data, and workflows into an easy to manage and participate in interface.  The E/S Hub excells at this because it covers the fundamentals of eMail, messaging, portal, calendar, scheduling, c

Andy Updegrove weighs in on the wave of ODF legislative failures first decribed by Eric Lai and Gregg Keizer compiled the grim data in a story they posted at ComputerWorld last week titled  Microsoft trounces pro-ODF forces in state battles over open document formats.


Andy believes that it is the failure of state legislators to do their job that accounts for these failures.  He provides three reasons for this being a a failure of legislative duty.  The most interesting of which is claim that legislators should be protecting CIO's from the ravages of aggressve vendors. 


The sad truth is that state CIO's are not going to put their careers on the line for a file format after what happened in Massachusetts.


Andy puts it this way, "
  

And second, in a situation like this, it is a cop out for legislatures to claim that they should defer to their IT departments to make decisions on open formats.  You don't have to have that good a memory to recall why these bills were introduced in the first place: not because state IT departments aren't a good place to make such decisions, but because successive State CIOs in Massachusetts had been so roughly handled in trying to make these very decisions that no state CIO in his or her right mind was likely to volunteer to be the next sacrificial victim.
As both Peter Quinn and Louis Gutierrez both found out, trying to make responsible standards-related decisions whe

Eric Lai keesp pokign at that Massachusetts hornets nest. One of these days he's going to crack it open, and it will be back to square one for the ODF Community.  Still missing from his research is the infoamous 300 page pilot study and accompanying web site where comments and professional observations document a year long study concernign the difficulties of implementing ODF solutions and making the migration.  <br><br>

The study was focused on OpenOffice, StarOffice, Novell Office, and a IBM WorkPlace prototype.<br><br>

The results of the year long pilot have never seen the public light of day.  But ComputerWorld is one of the media orgs that successfully filed a court action to invoke the freedom of information act in Massachusetts.  How come they can't find the Pilot Study?<br><br>

At the end of the pilot study period, Massachusetts issued their infamous RFi; the request for information regarding the possiblity of a ODF plugin for MSOffice!  Meaning, the Pilot Study did not go well for the heroes of ODF - OpenOffice, StarOffice, Novell Office and WorkPlace.  Instead, Massachusetts sought an ODF plugin that would no doubt extend the life of MSOffice for years to come.  No rip out and replace here folks!<br><br>

~ge~

excellent discussion of why the ISO standardization of OOXML is so importnat to Microsoft.

Tim Bray suggests using namespaces to brdige the comatibility gap between ODF and OOXML.

This log is connected to a recent post from Florian Reuter, XML Namespaces are designed to support exactly this kind of thing ...

If ever there was a discussion thread of consequence at the OASIS ODF TC, this is it. This is where the ODF interoperability nightmare burst into the daylight of a showdown vote. The interop issues were clear. OpenDocument TC members voted between interoperability and/or application specific innovation. Application specific innovation trumped interoperability. Again. And wha ta sad day it was. The thing is, the recent ECIS antit trust action against Microsoft comes at the request of IBM and Sun. They allege that Microsoft is violating standards requirements for interoeprability, and has launched a series of corrupt activities to push through a non interoperable standard. They are right. Microsoft is guilty. The problem is that Microsof tcan easily point to Sun and IBM activities at OASIS ODF, and make the same allegation! Using this thread as evidence! Furthermore, this thread is evidence that if Microsoft had tried to implement ODF, their efforts to establish interop would have been met with the same response from IBM and Sun that the OpenDocument Foundation recieved. Or so they could argue. Houston, we have a problem. IBM and Sun could have fixed the ODF interop problems at any time during the past five years. Yet, the world is waiting. Meanwhile, this willfull negligence and lack of desire to address pressing market needs for full interop has served to hold the door open for OOXML. And now these negligent acts llook to be the basis of a Microsoft counter claim. Oh well ..

This very funny satire builds on some harsh realities. The ODF chickens have come home to roost, and it isn't pretty. Very funny, yes. But not pretty for those who continue to believe that somehow ODF is a standard worthy of their support. The flip side of the coin is that using the same critieria of interoperability, OOXML is worthless. The sad truth is that both ODF and OOXML are applicaiton specific formats that will continue to defy and defeat all efforts at interoperability. Inparticular, it's the presentation layers of ODF and OOXML that remain bound to the layout engines and feature sets of their originating applications. Just as the presentation layers defy interoperability, they will also defeat harmonization. The only way to harmonize two application specific formats is to harmonize the originating applications. And Microsoft, Sun and IBM are not about to do that. The links in this satire are stunning!!! They shout loudly as to how Microsoft is going to respond to the ECIS anti trust allegations. So when you stop laughing, make certain you track down the links and read through the various OASIS ODF archive threads. IBM and Sun had their chance to fix ODF interoperability. Now it may be too late.