Group items tagged

Great quote from Eric Knorr.  He hits the nail on the head here, pointing out the problem Office 2.0  Web Apps and SaaS apps face:  If these Web wonders have interoperability and high fidelity document exchange with MSOffice, their collaborative features are value added wonders for existing business processes and workgroup-workflow scenarios.  If, on the other hand they lack this level of interop - integration with MSOffice documents and processes, the value add becomes a problematic split in a business process.  The only way to overcome that kind of a split is to take the entire process.  Which is difficult for lightweight mashup happy web wonders to do.

Which leaves each and every one of these Office 2.0 - Web 2.0 - Saas Apps vulnerable to Microsoft.  As long as Micrsoft owns the interop-integration keys to MSOffice, the web wonders live a precarious life.  At any time Microsoft can swoop in and take it all.

Today, the MSOffice OOXML file format displays perfectly in a browser.  It's 100% web ready, but only the MS Stack of applications gets to play.  Web wonders are not likely to recieve a Redmond invite now or ever.

Which brings us to the issue of the da Vinci plug-in for MSOffice.  da Vinci is a clone of the OOXML plug-in for MSOffice, and fully leverages the same internal conversion process that OOXML enjoys.  It can achieve the same high fidelity "round trip" conversion that OOXML is capable of.  Maybe even better. 

The problem for da Vinci isn't conversion fidlelity.  Nor is it capturing  business process important VBa scripts, macros, OLE, and security settings.  da Vinci can do that just fine.  The problem is that da Vinci cannot pipe MSOffice developer platform documents into ODF!!  For the love of five generic eXtensions, called the iX "interoperability enhancements", which the OASIS ODF TC blew off, ODF

Excellent legal argument by the legendary marbux concerning OOXML and ODF itneroperability. Covers ISO Interop Requirements and the demands of International Trade Agreements. Key to this thread is ODF v 1.2 and what must be done to bring ODF into legal compliance with International demands.

Outstanding analysis and research by the legendary marbux

IBM'sl Bob Sutor defines interop in terms of formats, protocols and interfaces: "To be clear, I'm talking about software interoperability. That technically boils down to the formats used to exchange information, the protocols by which the formatted information is exchanged, and the application programming interfaces (APIs) that software implements to allow the interchange to concretely take place. Collectively I'll call these interchange formats and methods".

An eMail went out today, October 24th, 2007, nominating IBM's Rob "Show me your garage!" Weir to be the new Co Chairman of OASIS ODF TC.  So it's looks like it's true; IBM is moving to take over ODF and OpenOffice.

Not that that's bad.  In the long run this is perhaps the best thing that ever happened to ODF and OpenOffice.  There is no way IBM's Lotus Notes business plan for ODF-OOo could be any worse than Sun's plan has turned out to be. 

~ge~

So, South Africa was watching closely the failed effort in Massachusetts to implement ODF?  And now they are determined to make it work? Good thing they left themselves a "pragmatic" out; "there are standards which we are obliged to adopt for pragmatic reasons which do not necessarily fully conform to being open in all respects."

Massachusetts spent a full year on an ODF implementation Pilot Study only to come to the inescapable conclusion that they couldn't implement ODF without a high fidelity "round trip" capable ODF plug-in for MSOffice.  In May of 2006, Pilot Study in hand, Massachusetts issued their now infamous RFi, "the Request for Information" concerning the feasibility of an ODF plug-in clone of the MS-OOXML Compatibility Pack plug-in for MSOffice applications. At the time there was much gnashing of teeth and grinding of knuckles in the ODf Community, but the facts were clear. The lead dog hauling the ODf legislative mandate sleigh could not make it without ODf interoperability with MSOffice. Meaning, the rip out and replace of MSOffice was no longer an option. For Massachusetts to successfully implement ODf, there had to be a high level of ODf compatibility with existing MS documents, and ODf application interoperability with existing MS applications. Although ODf was not designed to meet these requirements, the challenge could not have been any more clear. Changes in ODf would have to be made. So what happened?

Over a year later,

Yeah.  I said this!  And i still think ODF has what it takes to become a universal file format.  But only if the "interoperability enhancment" proposals are made part of the specification.  You can't talk your way to universal interop.   It has to go into the spec!

OBTW, for you idiots who think i support OOXML as a standard?  You're idiots.  I support the quest for a universal file format that is totally application, platform and vendor independent.  The requirements, demands and criticisms we make of OOXML should be applied to every file format up for universal file format consideration.  Including ODF.  Including XHTML+ (XHTML, CSS3, RDF).  Including the EU IDABC "ODEF".

The one area where i differ from most universal interoperability seekers is that i fully believe the big vendors have left open a loop hole we can exploit.  The plugin architecture is fully able to convert a big vendors application to produce our beloved but elusive universal file format. 

This is important because the big vendors control "interoperability" by contolling the big vendor standards consortia, and, the major applications.  It's a double edged sword.

The ubiquitous plugin architecture enables universal interop seekers to exploit the applications any way we want.  What's missing is a truly open "universal" standards process that is outside the reach of big vendors. 

Personally i like the recent GPL3 process as a model on which to base emerging universal standards work.  Somehow the big vendors must be neutralized.  Otherwise, we;ll never see the universal inteop the world so desires.

idiots,
~ge~

The "Backwards Compatibility" issue is all the rage at ISO, with the September vote on MS OOXML just a month away.

Microsoft and Sun (We've Been Had!) are arguing that ISO should approve MS OOXML (Microsoft OfficeOpenXML) because OOXML offers a backwards compatibility with the legacy of existing billions of binary documents.

This oft sighted history of Microsoft's reprehensible business practices is worth citing once again before the nations of the world go down that treacherous path towards ratifying Microsoft's proprietary systems and products as international standards.

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

Incredible comment by Marbux!  With one swipe he takes out both Ecma 376 and ODF. 

Microsoft has written a letter claiming that they will support ODF in MSOffice, but only if ISO approves Ecma 376 as a second office suite XML file format standard.  ODF was approved by ISO nearly a year ago.

Criticizing Ecma 376 is easy.  It was designed to meet the needs of  a proprietary application, MSOffice, and, to meet the needs of the emerging MS Vista Stack of applications that spans desktop to server to device to web platforms.  It's filled with MS platform dependencies that make it impossibly non interoperable with anything not fully compliant with Microsoft owned API's.

Criticizing ODF however is another matter entirely.  Marbux points to the extremely poor ODF interoperability record.  If MOOXML (not Ecma 376 - since that is a read only file format) is tied to vendor-application specific MSOffice, then ODF is similarly tied to the many vendor versions of OpenOffice/StarOffice.

The "many vendor" aspect of OpenOffice is somewhat of a scam.  The interoperability that ODF shares across Novell Office, StarOffice, IBM WorkPlace, Red Office, and NeoOffice is entirely based on the fact that these iterations of OpenOffice are based on a single code base controlled 100% by Sun.  Which is exactly the case with MSOffice.  With this important exception - MOOXML (not Ecma 376) is interoperable across the entire Vista Stack!

The Vista Stack is comprised of Exchange/SharePoint, MS Live, MS Dynamics, MS SQL Server, MS Internet Server, MS Grove, MS Collaboration Server, and MS Active Directory.   Behind these applications sits a an important foundation of shared assets: MOOXML, Smart Documents, XAML and .NET 3.0.  All of which can be worked into third party, Stack dependent applications through the Visual Studio .NET IDE.

Here are some thoughts i wou

The first post in the ZDNet series discussing the many deals Microsoft is cutting with prominent LiNUX vendors.  My point is that interoperability plays a prominent role in each of these deals, and, the deals also involve partners supporting Microsoft directed interop between OpenOfficeXML and OpenDocument.  Coincidence? 

I think not!

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

Microsoft Watch Joe Wilcox is on the job.  This particular hgihlighted quote speaks volumes.  The USA anti trust settlement famously allowed Microsoft to commercialize interoperability through expensive licenses -  $8 Million per year for just the basic package.

It looks like the EU would force those interoperability API's out into the open.  I wonder how this position will impact the November 12 th hearing on lifting the USA anti trust oversight?  We have the EU saying the monopolist is illegally maintaining their monopoly through various interop barricades.  And, the USA about to declare that the interop barricades no longer exists, therefore, the monopolist should be free to wreck havoc. 

The stage looks set for a vey dramatic final act.

Great article from the Universal Interoperability Council arguing the case for CDF as a universally interoperable format capable of fully representing desktop productivity environment documents. The UIC arguments are of course opposed by IBM and the lawyer for OASIS, Andy Updegrove.

Marbux at his best! Here he responds to Rob Weir's ODF v 1.2 arguments with a legal dissertation on International Standards, ISO, the WTO, and the key issue of interoperability and what it must mean. Excellent!

Uh?  The ODF failure in Massachusetts doesn't count as evidence that ODF was not designed to be compatible with existing MS documents or interoperable with existing MSOffice applications?

And it's not just the da Vinci plug-in that failed to implement ODF in Massachusetts!  Nine months later Sun delivered their ODF plug-in for MSOffice to Massachusetts.  The next day, Massachusetts threw in the towel, officially recognizing MS-OOXML (and the MS-OOXML Compatibility Pack plug-in) as a standard format for the future.

Worse, the Massachusetts recognition of MS-OOXML came just weeks before the September 2nd ISO vote on MS-OOXML.  Why not wait a few more weeks?  After all, Massachusetts had conducted a year long pilot study to implement ODF using ODF desktop office sutie alternatives to MSOffice.  Not only did the rip out and replace approach fail, but they were also unable to integrate OpenOffice ODF desktops into existing MSOffice bound workgroups.

The year long pilot study was followed by another year long effort trying to implement ODF using the plug-in approach.  That too failed with Sun's ODF plug-in the final candidate to prove the difficulty of implementing ODF in situations where MSOffice workgroups dominate.

California and the EU-IDABC were closely watching the events in Massachusetts, as was most every CIO in government and private enterprise.  Reasoning that if Massachusetts was unable to implement ODF, California CIO's totally refused IBM and Sun's effort to get a pilot study underway.

Across the pond, in the aftermath of Massachusetts CIO Louis Guiterrez resignation on October 4th, 2006, the EU-IDABC set about developing their own file format, ODEF.  The Open Document Exchange Format splashed into the public discussion on February 28th, 2007 at the "Open Document Exchange Workshop" held in Berlin, Germany.

Meanwhile, the Sun ODF plug-in is fl

Marbux sets the record straight. These are the facts: Putting Andy Updegrove to Bed (without his supper) ..... http://www.universal-interop-council.org/node/4

Response from the OpenDocument Foundation setting the record straight. See "copmments" with this bookmark

So I think users need to understand, very clearly, that an ODF document/app of *either* conformance class has an EXTREMELY WEAK CLAIM TO INTEROPERABILITY. The "pure ODF conformance" sticker would be at best valueless and at worst positively misleading. So what I'd like to see is some real effort from the TC going into resolving this problem ... Alex Brown What Alex fails to mention is that the "foreign elements and alien attributes" components in the ODF Section 1.5 "Compliance and Conformance" clause was originally put there in early 2003 to provide a compatibility layer for MSOffice binary documents. Without this clause, it would be impossible to convert the billions of legacy MSOffice binary documents to ODF without breaking the fidelity. Now th OASIS ODF TC wants to limit the use of the compatiblity clause. An action that would seriously cripple Microsoft's efforts to implement ODF in MSOffice 14. No surprises here. It was only a matter of time until IBM and Sun ganged up on the newest TC member, Microsoft.

So I think users need to understand, very clearly, that an ODF document/app of *either* conformance class has an EXTREMELY WEAK CLAIM TO INTEROPERABILITY. The "pure ODF conformance" sticker would be at best valueless and at worst positively misleading. So what I'd like to see is some real effort from the TC going into resolving this problem ... Alex Brown What Alex fails to mention is that the "foreign elements and alien attributes" components in the ODF Section 1.5 "Compliance and Conformance" clause was originally put there in early 2003 to provide a compatibility layer for MSOffice binary documents. Without this clause, it would be impossible to convert the billions of legacy MSOffice binary documents to ODF without breaking the fidelity. Now th OASIS ODF TC wants to limit the use of the compatiblity clause. An action that would seriously cripple Microsoft's efforts to implement ODF in MSOffice 14. No surprises here. It was only a matter of time until IBM and Sun ganged up on the newest TC member, Microsoft.

"In light of changes in Microsoft's behaviour, the increased opportunity for third parties to exercise their rights directly before national courts and experience gained since the adoption of the 2004 Decision," this morning's statement reads, "the Commission no longer requires a full time monitoring trustee to assess Microsoft's compliance. In future, the Commission intends to rely on the ad hoc assistance of technical consultants. "Microsoft has an ongoing obligation to supply complete and accurate interoperability information as specified in the Commission's 2004 Microsoft Decision," the EC goes on. "However, given that the original set of interoperability information has already been documented by Microsoft, increased opportunities through private enforcement provisions in Microsoft's license agreements for third parties to exercise their rights directly before national courts, and experience gained since the adoption of the 2004 Decision, the nature of the technical assistance that the Commission requires is now of a more ad hoc character."