PlexNex

Microsoft Breaks the Plugins

Tiffany Maleshefski at eWeek Labs is giving the Plugins the once-over-twice and she kindly put up the slides of her experience with Sun's faulty attempt.

Observe the trouble Sun Microsystems' engineers are having getting their ODF plugin to work in MS Office. See the presentations here...

Sun is having trouble because Microsoft is breaking interoperability deliberately through hi-jinks with the Dynamic-Link Libraries ("dll") in Windows.

From Sun's Malte Timmermann's blog...

Q: Why doesn't it support Office 2007?

A: Well, basically, it does, but there is an issue in Word's 2007 Filter API handling. You can save to ODF, but when you try to open ODF, Word ignores the installed filters and tries to open with it's own filters. Of course Word can't, so you get an error message "The Office Open XML file <name> cannot be opened because there are problems with the content". This even happens if you explicitly select the ODF filter! I hope Microsoft will fix this issue with the next service pack. If not, we will work around this bug by doing the same kind of integration like in PowerPoint and Excel.

As marbux says, "Welcome to dll Hell!"

Microsoft's Brian Jones innocently says 'Gee I can't imagine how that's happening?'

You're making me laugh, Microsoft.

You went to the DoJ for this behavior in Netscape. This is going to add to your fines in Europe. We know how you're doing it; we're going to tell on you.

If Brian Jones is obviously looking in the wrong place and can't grok what's happening it's because his head is buried in XML (within the files) and it's the Windows Department who are playing fast & loose with interoperability: the file-association behavior of Office 2007 was working for the OpenDocument Foundation's da Vinci Plugin with Office 2007 Beta and broke in the Final version (yes, we've known about this for about 6 months).

Y'all are some dirty mutherfuckers.

Give me your markets, or I'll take them from you.

Translator is FUBAR!

The Microsoft-Clever Age-Novell ("MCAN") ODF Translator v1.0 is out of the gates at Sourceforge and it's no Ferrari.

FULL DISCLOSURE: I am with the OpenDocument Foundation and we have the ODF Plugin for MS Office which is the real vendor-neutral solution to document interop...etc. blah blah.

There will be no anxious arm-waving or droll, facetious word-smithery here because the MCAN Translator is so bad that the market will just move on.

Here's why.

Holding the performance aside (which, itself, is a disqualifier...see the burried List of Unsupported Features the length of my arm), the Translator makes it so difficult for MS Office users to create ODF files, that no one will ever use it.

Microsoft, Clever Age and Novell are telling you that it is just the first version and it will improve, but I'm sorry to say Clever Age hit the technical wall in the first month and they'll never climb over it.

For background, see my "Pretending Interoperability" [or the one with the bad language removed "Pretending Interoperability (PG Version)"] article from late October 2006 to understand how we discussed then the poor technical approach sought by Clever Age in light of the non-standard XML implementation of the Micrsoft Office Open XML formats.

The abridged version of the story is that XSLT methods for transforming from one dialect of W3C-conforming XML to another dialect of W3C-conforming XML will always work. It is definitional. If it does not work, then one of the "W3C-conforming" dialects is a punk. Well, we and Microsoft know XSLT well enough to know in advance that the design of Microsoft Office Open XML would make it impossible for this, the Clever Age approach, to work for the Translator. Let me say this clearly: Microsoft knew in advance that XSLT would provide shitty tranform from Microsoft Office Open XML to ODF and they funded the Clever Age project to use this method.

It doesn't take a genius to see the set-up. This is what Steve Ballmer meant when he said interoperability would be imperfect when he announced the basis for the Microsoft-Novell patent detente in early November 2006.

One of the key goals of the collaboration effort is to build file format conversion technology that will provide greater interoperability between the OpenDocument and Open XML file formats. Novell and Microsoft are not trying to develop a file format that is optimized to work only with a particular version of Open Office, Ballmer said.

Nor will the collaboration team attempt to build file converters that can make files 100 percent compatible between the two file formats, he said. But it will achieve the level of interoperability that customers can work with, he said.

Early Reviews

Our own conclusions from early inspection this weekend was that the C# routines take up a lot of system resources and files come out poorly in the expected 5 Trouble Spots and even in more areas where we know there should be perfect fidelity.

Fellow traveler in the blogosphere, Tim Anderson, says converter "not good."

Great news for interoperability - or is it?

In addition to requiring the .Net framework to be installed (this will be done presumably by Jeeves the English Butler, retired CIO of MI6), the procedure for saving a file with the converter is a dual-save with a .tmp extension that would confuse the members of Mensa much less the office secretary.

Double-save required. Ouch!

Moreover, the save takes 30 seconds, with the heavy C# routines chugging along in the background, and the omenous message appears, below.

Elements are dropped, indicating bad interoperability

Tim's conclusion...

So the message is: don’t even think about using this converter as a means of standardising on Open Document while still using Word. It will cause immense and unnecessary hassle.

Another document freedom-fighter, Walt Hucks, has a direct piece of advice...

I suggest waiting for the [OpenDocument Foundation's] da Vinci plugin to be completed and released later this year.  It will allow users to natively use OpenDocument Formats, even as the default file format, while preserving Microsoft-specific features in ODF files (and hopefully, specific features of other applications as well, including those which Microsoft Office does not understand or support). The ACME 376 demonstation is available now. (ACME 376 does not use ODF–it uses another XML-based format just to demonstrate what da Vinci can accomplish, because da Vinci uses ODF 1.2, which is slated for introduction later this year).

Conclusion

I hope you're testing the Translator against your own organization's documents to see for yourselves how bad it is. I would also point out without the slightest touch of irony how ironic it is that you have been waiting for a document interoperability solution from Microsoft (astounding!) because it is "open source" (appalling!).

Open source is great because you get it free and someone else does the work. Well, as my wife says (she's from the mountains of Pennsylvania), "I got news for ya..." -- Microsoft ain't doing your interoperability solution. They're going to delay and delay and delay and delay until they've bought the judge and the jury.

Meanwhile, ODF policies deteriorate in confusion and go the way of Massachusetts: your elected officials turn over and the ones with any common sense ditch the issue like twenty-dollar girlfriend in the lobby men's room of the Boston Ritz-Carlton.

The OpenDocument Foundation's ODF Plugin for MS Office ("da Vinci") will probably be released under an open source license under the proper conditions; but there are two reasons why we are proceeding with care...

• peer production methods are not needed (we know the few people with the knowledge & talent to execute)
• out in the open, Microsoft will kill it

Rest assured, the ODF Plugin for MS Office will be free to end users and the code will be visible and transparent (at very least) to the Friends of the OpenDocument Foundation who fund the work. (And it will be fully vetted by the best security and code people in Christendom.) At the very least, we can simulate some of the desirable characteristics of open source without commiting suicide. (Simple formula: join the Foundation, get the Plugin.) Trust either the vendor-neutral OpenDocument Foundation or trust Microsoft.

There is a strategic component here, too, you'll want to know about. Any server-side enterprise who would like to be first in the door of any & all government CIOs for a conversation on how his/her systems will connect with the Windows desktop -- at the file format level which, with XML, is the new Win32 API -- you are going to want to talk to the OpenDocument Foundation about licensing the ODF InfoSet API to put in your servers to gain you access to the CIO's chamber.

"Liberate tutemet ex inferis"

Open-Standard Catharsis

There's nothing like an ISO vote to focus minds on the life or death of the ODF movement.

It pleases me to report that friends in Europe, South America, and vendors in the US have stepped up to enquire anew about the OpenDocument Foundation's da Vinci-class ODF Plugin for MS Office.

We need to bring people up to speed on the background, where da Vinci came from, what specific problems it solves and the Foundation's vision for interoperability and compatibility between office applications and ODF documents.

If these questions interest you or your organization, kindly give us a ping.

Pretending Interoperability (PG version)

(The original version of this post ran on October 31, 2006, and contained offensive language which is omitted here.)

If you are Microsoft and you see ODF on the horizon, and the EU is giving you heat for not having an open standard XML file format, you're thinking two things (in PowerPoint)...

• kill; and
• Kill

The cooler heads in the organization would be thinking up a plan (their PowerPoints would read)...

1)    suffocate the ODF Plugin
2)    create a one-way interoperability mechanism to gather all those stray ODF files into Microsoft Office Open XML ("MOOX").

Microsoft has set out to do both, and it's a failing strategy. Here's why, if you have the patience for an extended post.

Take the Microsoft perspective. You own the file format(s). Some dominant percentage of the worlds documents are being produced in formats for which you own the recipe. Nobody else knows your ingredients or the sequence with which you mix them together -- something like Coca-Cola. PDF and the odd OpenOffice and ODF files make up the rest; and of course there's HTML and its derivatives like XHTML, if you consider a web page a document, which I do. (Incidentally, PDF's threat to Microsoft is being taken seriously and is being attacked through Vista and Office 2007 in the form of XPS. Stay tuned.)

Your view is that MOOX will simply come in and add to the formats you already have outstanding of the .doc, .xls, .ppt, .docx varieties, etc., etc. MOOX you are advertising to be perfectly backward compatible with all of these. You and only you know how they work (because the recipe is secret) and therefore you and only you can provide the perfect way to "pull up" everybody's billions and billions of files in a relatively short time to all being MOOX (because Vista and Office 2007 are going to be so successful). 

Now, ODF looks exciting to some people out there, to state governments anyway. And it looks like if you are Microsoft you are going to have to deal with this other format to some extent. And because you are Microsoft and you are accustomed to winning, you view this stray format, ODF, as a temporary thing. And since you are going to own the main format(s) people use, you're thinking that your only requirement to combat ODF is to provide a mechanism to "pull up" all the stray ODF files into your latest, MOOX.

Then, lowe & behold, the OpenDocument Foundation in reply to the Massachusetts ITD's cry for help in a Request For Information (May 2006) announces that it has an ODF Plugin for MS Office installations (for Office 97, 2000, XP and 2003). The Foundation's ODF Plugin uses well-known published interfaces that Microsoft and its partners have used for years and provides native ODF capabilty to Office users.

Flies on the wall of the conference rooms in Redmond would have overheard the following...

SB:    Oh [expletive deleted]! I'm going to eat the heads off those [expletive deleted]!

BG:    We knew this was coming.

RO:    Hmmm.

CM:    This will put ODF right into Office and seamlessly integrate that other file format we hate!

RO:   It will delay Vista. People wil have an XML format and delay upgrading to Vista. The Foundation's plugin will extend existing desktop investments.

SB:    Holy [expletive deleted]! [expletive deleted] them!

RO:    Let's do our own Plugin and remove the air supply from the Foundation's Plugin.

CM:    Right, Ray! And let's make it open source so there are absolutely no revenues for anyone else.

BG:   [expletive deleted]!

CM:    Let's hire a French company to do it; the EU will love that.

RO:    Now you're talking, Craig.

SB:    [expletive deleted] [expletive deleted].

BG:    They just don't respect intellectual property, the [expletive deleted]!

CM:    We must see if the Foundation's plugin is for real.

RO:    Get Paoli, Yates & McGibbon over there to Brussels...

So it must have transpired.

In July, representatives of the OpenDocument Foundation presented a demonstration to a special committee in Brussels hosted by IDABC. There, in that meeting, Microsoft officials saw the Foundation's proof-of-concept of the ODF Plugin and asked the Foundation representatives to leave the room for a moment of privacy. (This is still unbelievable, and even more unbelievable is that our representatives actually agreed to get up and leave.) Then & there, those Microsoft officials announced their version of an ODF Translator, that it would be free and open source. This is the origin of the Clever Age project on SourceForge, which they call now the "ODF Add-in for Microsoft Word."

Next, if you are Microsoft, perhaps you decide it's a good idea to play the press. It would help here if you use that word, 'Interoperability,' so you issue a press release on July 5th entitled,

"Microsoft Expands Document Interoperability"

Company to sponsor open source project for Open XML-ODF file translation to deliver more choice for government customers and their constituents.

If you are Microsoft, you issue this press release anyway, even though you know no one will believe even a word of it. File "interoperability" has been the byword for going on 10 years now and Microsoft's proliferation of complexity and incompatible variety has been the action. Like that word 'innovation,' 'interoperability' is getting worn out from misuse.

So if you are Microsoft, you feel you have frozen the market for plugins or converters or translators or add-ins, or whatever. There in France, the Clever Age project is progressing along at a good clip, not without technical hurdles, but moving along nicely enough, you imagine (the project forum indicates however that the project has no one watching it: posts have petered out since July). In a few day's time that project is all set to release a milestone piece of code, an ODF Import-Only slice of the ODF Add-in which will permit users of Word XP, 2003 and the Word 2007 beta to read ODF files. (ODF Export was said to be in the Clever Age Roadmap, but the Roadmap link is dead on the sourceForge site.)

There are now no other plugins in sight. Mission accomplished. Air supply appears to be removed from all competent competitors (Sun's C# server-side "plugin" doesn't meet Massachusetts requirements; and anyone using the OpenOffice filters is finding the same problems for file incompatibility and the same old file roundtripping nightmares). Everyone wants the Foundation's ODF Plugin and no one wants to pay for it. Mission accomplished.

So now, if you're Microsoft, all you need is to have Clever Age cleverly come up with an ODF Add-in which successfully imports ODF files into the designated Word applications. Even though it is mentioned in the roadmap that MOOX-to-ODF export is planned, you will need to show this to me working in the flesh before I believe it will be a) done under Microsoft sponsorship; or b) done successfully under Microsoft's sponsorship.

If you're Microsoft, the one-way converter is perfect. Just what the doctor ordered to show big governments that you care about interop. MOOX will be the new, new thing. Everyone will be working in MOOX and if, by chance, you get a stray ODF document coming at you from your friend, a maximum-security guard working in Her Majesty's Prison Services, then just run it through the converter and Voila! Microsoft continues to own the document formats.

The Trouble With You Is...

The problems with this are myriad, so it's hard to know where to start. In such a case, it's probably prudent to start with the fundamental problems and avoid the rest altogether.

Firstly, the Clever Age ODF Add-in is not an interoperability solution, it is just a converter. What the world needs is documents to work seemlessly together, in all instances. ODF, the only universal portable document format, is the only solution to this large set of problems.

Secondly, the Clever Age ODF Add-in is not going to work. Assume for one thing that Microsoft/Clever Age were going to stick to their word and solve for both Import and Export (it's a big assumption, I know, but bear with me). The method Clever Age are using -- the old XSL Transformation -- is a rotten choice. Why? Because XSLT is good for XML to XML converstions and Microsoft's new Office Open XML format is merely an XML encoding of RTF, the proprietary Rich Text Format owned by Microsoft. In other words, MOOX contains hidden code instructions that only Microsoft understands (i.e., RTF) that are wrapped in XML. An XSL Transformation will output the hidden bits too but no one is any more able than they were before to understand these parts -- except Microsoft.

Let me explain. It is easy for Microsoft to go and convert a file in the direction from ODF (a format everyone knows) to Microsoft's own format MOOX. It is infinitely more difficult (if you are not Microsoft; Clever Age is not Microsoft) to convert perfectly from MOOX to ODF. It's because certain hidden code instructions which are embedded in the XML-encoded RTF of MOOX are only known to Microsoft.

RTF is considered by many to be human-readable and open format. The RTF specification is publicly available -- we are now on version 1.8 (2004) -- from the inventor, Microsoft. Even though many different applications (including OpenOffice/StarOffice) use RTF as a format for document interchange, many people do not recognize that Microsoft keeps "a second set of books" on the RTF specification. There are data combinations in RTF which may look innocuous or meaningless to the eye but from which Microsoft can parse meaning. There is more information available in RTF to a Microsoft application than is available to other applications. RTF is therefore not open because it is not completely specified. And its role in the architecture of MOOX should give pause to users and members of the software standards community; RTF's secrets are the reason Clever Age's MOOX-to-ODF export will never work adequately through XSLT -- even if they deliver one.

(Incidentally, this fact that MOOX is XML-encoded RTF means that it should not be considered open. It means MOOX is a proprietary format. In this light, a possible ISO vote next year on the ratification of MOOX as an international standard is a fiasco so dire that ISO will never recover if the nature of RTF is ever widely recognized.) 

Thirdly, if its poor file interop performance is not deterrent enough, there are other barriers to its actual use. The Clever Age ODF Add-in will never be deployed by users due to its sheer clunkiness. It lacks the native File->Save & File->Save As processes specified by all the governments so far. Moreover, its installation requires the cumbersome .Net Framework AND the Office Compatibility Pack (for the older versions of Word). This is a whole [large amount of material] to swallow, indicating that Microsoft/Clever Age have no intention of this thing ever actually being used. It's merely intended to prompt a checkmark on the EU's proverbial list of hurdles.

Do I need to go on? I will, only to add that Clever Age are finally recognizing one or two of the hurdles to file interoperability that we have known about for years. The recent post by Jean Goffinet of Clever Age, "Reaching the Limits," describes the Table-in-a-Table Problem which has plagued users of OpenOffice and Word practically since Day One and has been a perennial source of unhappiness in document collaboration across different systems. M. Goffinet is correct that this is not a question of Evil or poor skill but rather about different ways of doing things. It simply becomes hard to reconcile when you have different operations encoded into a file and then that file encounters different features in different environments, each application environment not knowing what to do with the other's way of encoding.

You might think that with all the differences of features in all the versions of Word, for example, that there is an infinite number of these recalcitrant problems of difference-of-approach. But there are only five. That's right, only five. It is this paucity of difficult file interoperability problems that makes me red in the face when I consider that the Hamburg engineers sat on their hands at OpenOffice/StarOffice for years and put OpenOffice/StarOffice into "Maintenance Mode" when they had so few issues to finally solve to achieve beyond-adequate file interchange performance.

With respect to the ODF Plugin and its native insertion of ODF into MS Office, Hamburg had been saying, "It can't be done!" with such vehemence for so long that they surely convinced themselves it was true. In fact, Sun Microsystems and Hamburg (two very different organizations) together were having trouble distinguishing between technical feasibility and business-case feasibility. Accordingly, it's not hard to see why Sun's own attempts at a plugin now to satisfy the Massachusetts & EU requirements are just as malformed as Clever Age's.

Clever Age may be sincere in their efforts to satisfy their client, Microsoft. But Microsoft -- and Clever Age -- are being disingenuous to offer the ODF Add-in as a solution to ODF file interoperability. Together in all they are just pretending, playing House. (If you are not entirely convinced of this, then consider that it would take Microsoft's Brian Jones and a few Indian or Chinese hands about two weeks to complete perfect ODF capabilities for all extant versions of MS Office. The question -- 'Why don't they?' -- is either naive or more misdirection.)

If Table-in-a-Table is one, then what are the Other Four Trouble Spots of file interoperability between ODF and the Microsoft formats, you may wonder? Stay tuned on fr0mat.net, the official blog of the OpenDocument Foundation.

What Does the Plugin Accomplish for Organizations?

There is a lot of speculation about an MS Office plugin that enables the legacy office suites to work in the OpenDocument Format (ODF). What I don't see is informed discussion from the point of view of Microsoft enterprise customers (including governments) about what the Plugin would achieve for them.

There are two important things the Plugin accomplishes for large & small organizations that are already entrenched in MS Office software on the desktop:

A -Ends Version Madness.

B -Introduces a durably open file format for documents without a disruptive change of software.

(A) is self-evident to this readership. Among the sappers of office-worker productivity is MS Office Version Madness, which describes the document incompatibilities arising from Microsoft's customary changes to its document file format recipes in Word 6.0, Office 95, 97, 2000 and XP which make documents inaccessible with various permutations of office suite versions and make everybody enormously frustrated and which also harm productivity in just about every office setting. (I needn't go into it because the experience is universal among this white-collar PC-using audience; however, I might add that the end of Version Madness is also a very attractive prospect to individual PC users at home, school or SoHo.)

The Plugin ends Version Madness because it provides a single, unified file format in which all modern versions of MS Office can work -- file conversions going both ways -- as well as handles repeated round tripping smoothly. 

(B) deserves a bit of explanation. For state governments, like The Commonwealth of Massachusetts which was the very first organization to put out a call to hear if any such Plugin might exist, the move to the open standard OpenDocument Format is intelligent and wise. The strong case for ODF in the document-centric business processes of regional, state & municipal government will eventually be universally obvious.

The case for it, in fact, is overwhelming; ask the EU, ask the Danish, ask the UK, ask the German Ministries, ask around. News to the contrary from Microsoft officials (Jason Matusow, for example) and from Matusow Bootlicks (Matt Asay, for example) is either malintentioned disinformation or ignorant and self-involved cow-towing. 

The trouble, though, for these organizations is how to implement ODF without changing software. They need ODF, but a rip & replace of MS Office runs afoul of the interests of disabilities organizations which rightly assert the fear, cost and difficulties of substituting desktop software that breaks exisitng Assistive Technology integration with MS Windows & Office. (It's not ODF's -- the format's -- lack of integration with Assistive Technologies as much as the lack of present Assistive Technology integration with OpenOffice or StarOffice -- the application. (A format itself has minimal inter-course with AT devices and applications compared to the significant involvement of AT devices and applications with the productivity applications themselves.) Confusing the format with the application has been central in Microsoft's fatuous strategic path in The Commonwealth; hiding behind complexity, a perennial & skillful gambit of Bill Gates and his company's leaders.)

The Plugin resolves the Assistive Technology problem for ODF-minded organizations. This is true simply because the Plugin leaves MS Office, with all its functionality (to which all users are accustomed) and all its Assistive Technology integration (on which disabled people depend to get work done), on the desktop.

The Plugin achieves ODF implementation with no threat to people with disabilities. The disability card is thus removed as an argument for organizations to stay away from ODF. How many more excuses can we remove for you, now?