Previous articles :
- Follow up on Microsoft latest bullshit announcement
- Microsoft latest bullshit : native support of ODF in Office 2007
- Custom XML? What Custom XML?
- Backwards compatible? One more lie by omission
- Bad surprise in Microsoft Office binary documents : interoperability remains impossible
- Typical B.S. in technical articles about OOXML
- The truth about Microsoft Office compatibility
- OOXML is defective by design
It's been 3 months since ISO made that April 1st gag when they declared OOXML a valid candidate for an "open standard", even though it's riddled with patents.
Microsoft made the situation even more ridiculous by making available, after April 1st, documents that are absolutely necessary in order to fully implement their file formats. Well, if those documents were not part of the ISO proposal in the first place, then what is the ISO proposal good for? Isn't an "open standard" meant to be implemented by more than one vendor?
Completely, utterly, shamelessly, ridiculous. Typical Microsoft.
Let's get on with the ridicule. Remember the days before April 1st? A day could not pass without a number of so-called independent companies claiming support for OOXML in one way or another, and telling how good it was. Well, since April 1st, it's like not a single freaking person cares about it. Silence. How so? Wasn't it a fraud to begin with?
Let's take the binary migration project that Microsoft launched back in February. Here is a refresher :
The "Office Binary (doc, xls, ppt) Translator to Open XML" project is now live on sourceforge: http://b2xtranslator.sourceforge.net/
As you may remember, this was a request from a number of national bodies, and while Ecma TC45 believed it was outside of the scope of DIS 29500, they did talk with Microsoft and come to this agreement:
Nonetheless, Ecma International discussed this subject with Microsoft Corporation, the author of the Binary Formats. To make it even easier for third party conversion of Binary Format-to-DIS 29500, Microsoft agreed to:
* Initiate a Binary Format-to-ISO/IEC JTC 1 DIS 29500 Translator Project on the open source software development web site SourceForge (http://sourceforge.net/ ) in collaboration with independent software vendors. The Translator Project will create software tools, plus guidance, showing how a document written using the Binary Formats can be translated to DIS 29500. The Translator will be available under the open source Berkeley Software Distribution (BSD) license, and anyone can use the mapping, submit bugs and feedback, or contribute to the Project. The Translator Project will start on February 15, 2008.
* Make it even easier to get access to the Binary Formats documentation by posting it and making it available for a direct download on the Microsoft web site no later than February 15, 2008. The Binary Formats have been under a covenant not to sue and Microsoft will also make them available under its Open Specification Promise (see www.microsoft.com/interop/osp) by the time they are posted.
We will modify DIS 29500 to include an informative reference to the SourceForge project.
While the project is still in its infancy, you can see what the planned project roadmap is, as well as an early draft of a mapping table between the Word binary format (.doc) and the Open XML format (.docx).
How is this project going on? Let's see for yourself on this web page. The project is still a 1st revision source code dump, and it's 4-month old. It's hard not to laugh.
Who thought Microsoft was serious when they started this project? Everyone worth his salt knows that a project like this involves an almost complete rewrite of both engines, and it could take a decade to do so. It's ridiculous to think that a company or independent people would spend their lives essentially rewriting Microsoft Office code base (the non UI part). After all, isn't it what was essentially done already with OpenOffice? Why isn't Microsoft instead pledging support for the OpenOffice suite by helping implement the undocumented stuff? Alternatively, why don't they instead open source their compatibility pack, a component that migrates Office documents back and forth?
It gets better.
Earlier this month, Microsoft released another 5000+ pages of documentation. This additional documentation is a direct acknowledgement that what I have been saying on this blog was spot on, which is that the documentation that was made available earlier was just a fraction of what was needed to implement a full run-time of Office documents. At least Microsoft gives way to a so-called anti-Microsoft person. How ironic that is. Well until you understand that the Microsoft bloggers were actually backing me and my products (diffopc+, xlsgen, ...) until I started becoming vocal and a critic on the subject. In other words, they were backing me when I was saying positive things about it. Those are not technical people, those are stinking marketing people ready to bribe.
If we take a look at the new documentation, it gets a little interesting. First of all, let's say that if you are not one of the 5 persons on the planet who has been involved in hardcore BIFF/Word/PPT/MSO, you are just wasting your time here. This puzzle (smells like a typical PM document) can only be understood by people in the trenches.
Then, Microsoft does the typical thing, they make it almost impossible to use the document by sorting everything alphabetically instead of logically, by theme. This attitude is kind of, realising valuable information while making life miserable to anyone who'll try to read it. Again, you cannot fully comprehend a behavior like this without a good dose of cynism.
Next, this documentation is still lacking plenty of information. For instance, in [MS-XLS].pdf, page 364, we learn :
dwBuild (4 bytes): An unsigned integer that specifies the recalculation engine identifier of the recalculation engine that performed the last recalculation. If the value is less than the recalculation engine identifier associated with the application, the application will recalculate the results of all formulas on this workbook immediately after loading the file.
It is clear that it's up to everyone I guess to figure out the build numbers used by shipped Excel products over the years. Failing to find those numbers implies a recalculation of the spreadsheet next time it's open, needless to say, something you want to avoid at all costs.
Above all, what I find most shameful is that earlier this year was the time Microsoft not only was buying people's voice left and right to obtain the $$ISO$$ rubber timestamp, they were also putting the last touch to Office 2009 (codenamed Office 14). And they have never talked about it. Whatever they have already baked in won't be part of the ISO proposal, making it as useful as an old sock. And doing so, iterating though their fire and motion war strategy which is to come up with new stuff and have competitors spend their time catching up instead of concentrating on their own applications.
The ISO episode hasn't changed things a bit in this regard.
[Update, july 9] : I wrote this blog post on july 7. When I wrote it, the b2xtranslator project I mention was showing a 4-month old developer branch, with just a single submission in it. Guess what happened in just the matter of two days! Monopoly employees have probably urgently asked their contractors to push something new in the developer branch, to avoid the ridicule. Just two days after I mentioned this blatant deception that Monopoly had created in the first place (a project that will never complete anyway given the amount of work that is needed, and the fact that it makes little sense to do it when the Office compatibility pack already does it), the thing gets "fixed". Very interesting...It smells as if Monopoly is extremely sensitive on this subject while the OOXML appeals are being processed.
