Short Answer: When it becomes manipulation. And before some of the Microsofties coiled in their upscale building of the rue de l’Université in Paris start to wonder if they should not be doing something about me, let me just point you to this link: The now famous Plamondon Files, one of whose is adequately named “Evangelism is War”. Too late for the Schadenfreude, my dubious friends.
I am afraid Microsoft has embarked in a journey where manipulation and astroturfing will be the longitude and latitude they will use to set their path. But let’s dive into the specifics.
The OOXML controversy has now reached a new stage. This stage could be labelled as the stage of confusion. The Ecma has answered to 3522 comments (and 3522 unique comments that should be dealt with appropriately, not by grouping hundreds of them because they seem to be the same) in a way that could be considered as positive at first glance. However, any deeper analysis of just a handful of these answers show that most of them have simply not been adequately answered. Aside the mention “Agreed” by the Ecma, we have several, not to say hundreds and hundreds of answers that worsen the existing flaws, contradict each other, or propose solutions that avoid any kind of common path with the existing ISO standard, ODF. That’s just the issue with the comments that have been answered to; others have been ignored. The French convergence proposal has been flatly rejected by the Ecma on formal grounds. Namely -strap yourself- the convergence proposal cannot be properly addressed in the course of a Fast-Track process. What the Ecma forgets to mention here is that it’s precisely the reason why OOXML should not be approved as an ISO standard, since discussions and proposals on convergence or mentions of conflicts with existing standards do not seem to matter.
At the Afnor meeting we had last Friday, the refusal of the Ecma was discussed; Microsoft and its proxies were trying all sorts of arguments to convince us that the Ecma had not exactly rejected the proposal. They were trying to make the point that the Ecma had already answered the convergence -the harmonization as they call it- in an answer made to the committee of New Zealand. The problem is twofold here, but Microsoft obviously intended to blur the lines and confuse the committee:
-The proposal by the Afnor implied a roadmap and a sanitization work to be made on OOXML. With all due respect to the standards board of New Zealand, its own proposal never contained such a project.
– Most importantly, the Afnor proposal did clearly imply that OOXML would never become an ISO standard (see here). OOXML could become an “ISO-TS” (Technical Specification) but there again the Ecma decided on vague formal gounds that the JTC-1 simply could not do it. I know for sure that there are other similar options and titles for the contentious OOXML if it were to follow that path. But the Ecma answer to New Zealand was implying in turn that harmonization could be possible if OOXML became an ISO standard.
I could also mention the odd attempts to push VML back into the OOXML spec… But there are more cunning aspects that have the obvious effect to confuse people in this story. And when I mean people, I mean ISO delegates, journalists, pundits, laymen, strawmen… and ultimately, customers. Because customers do pay attention to what’s going on with the OOXML issue and what will happen in Geneva.
On a legal point of view, the growing uncertainty on patents and intellectual property related to OOXML has gone unnoticed mostly because of the efforts made by the Ecma and Microsoft to alleviate those concerns, mostly through throwing incomplete, half valid protective claims on OOXML. I clearly remember that my company filed a comment pertaining to the legal gaps of the Open Specification Premise and the RAND agreement covering OOXML. Too many points inside the OOXML specifications are left uncovered by them, thus making it hazardous for anybody to implement OOXML. Another, very important point, is Microsoft’s refusal to make the OSP apply to GPL. That pretty much says it all on Microsoft’s will to open up the competition. The ODF Alliance has published a very good paper on this issue, but if you want more background on this, I suggest you read the excellent article by Roy Schestowitz.
In short, the confusion around intellectual property is so overwhelming that one is left unconvinced at the ability of the ISO to do its homework properly when it comes to patents and more generally IPR. Others have explained that all this was due to Microsoft’s will to “drown the fish” as the French saying goes, but I guess wondering about that at this stage would be beside the point.
Where confusion is obviously the result of a strategy devised by disingenuous people is the case of the Office Binary translation project. After the bombastic announcement by Microsoft that it was to release the “documentation on its office binary file formats”, one could have thought that it would be able to receive the full binary specification and perhaps (an immoderate hope), perhaps the actual source code of those binary blurbs. You can always hope, “ain’t gonna happen”… All what is available is the same old documentation, most of it having been available until 1999 where it was taken off line from MSDN. This documentation is thoroughly incomplete, acutely inadequate and riddled by legal traps at least as bad as the ones carried by the OSP that covers these files. You will notice the subtle art of confusion that speaks of documentation but carefully avoids the words “full specification”.
Now the Office Binary to OOXML translator is one of those projects that actually makes OOXML irrelevant as a standard. If this project ever comes to fruition, which is at the moment not the case, anybody -or so one might hope- could use this software to convert its binary, proprietary files from Microsoft Office to the controversial OOXML. But then why did we have OOXML in the first place? What about the advertised ability of OOXML to “faithfully represent” the behaviour of past applications? I guess this project should have somehow been included in the OOXML spec in the first place, because it does defeat the purpose of OOXML in the first place.
That’s one more contradiction for Microsoft to handle. But as I wrote the other day, “nevermind the money”…