Uncomfortable Reality

The reaction -- or clarification rather -- in Tim Bray's blog last night was interesting. He was not thrilled by what he called "cherry-picking" of words (e.g. "unadulterated bullsh*t"), so he prepended a copyrights-oriented disclaimer to his latest post which is fairly well-balanced.

“Harsh reality put bluntly can make the viewer (or listener, or reader) wish to look away; it doesn't make any less real.”In his previous popular post he seems to have complained about me specifically and Sam Hiser made some similar accusations. Since when is it inappropriate to quote a person with link to the context? And since when is the highlighting of proven misconduct an iffy business that hurts one's credibility?

Harsh reality put bluntly can make the viewer (or listener, or reader) wish to look away; it doesn't make any less real. Some people continue to stare embarrassed at corruption, but one should truly be bold enough to face it because only this way it can be addressed. And no, we don't live in a perfect world, but the least one can do is help improve it by identifying causes for harm and demanding change. The BRM was just as bad [1, 2, 3, 4, 5] as was anticipated [1, 2, 3, 4, 5].

In any event, shortly after the good announcement about Linux (not Ballnux, e.g. Novell) PCs arriving at Europe with ODF 'built in', IBMers proceed to discussing the technical deficiencies of OOXML, as opposed to the OOXML BRM and much of the OOXML-related misconduct.

OOXML Still Broken

Rob Weir posted a couple of good items that are worth keeping in mind. The first one makes another indirect approach toward the issue of legacy formats. As mentioned yesterday, binary Office format specifications render OOXML pretty much unnecessary, rationalising more than ever the need for Microsoft to embrace ODF and migrate its legacy in that unified direction. The company claims to have just done the same with IE8 and Web standards (promises, promises), so why not document formats?

Faithful representation of Microsoft Office 97-2008. I've learned it is rarely polite to ask a man what he means by "faithful", but let me make an exception here. We have now the binary Office format specifications, not part of the standard, but posted by Microsoft. And we have OOXML specification. In what way does the OOXML "represent faithfully" the "existing corpus" of legacy documents?

Does OOXML tell you how to translate a binary document into OOXML? No. Does it tell you how to map the features of legacy documents in OOXML? No. Does it give an implementor any guidance whatsoever on how to "represent faithfully" legacy documents? No. So it is both odd and unsatisfactory that primary goal of the OOXML standard is so tenuously supported by its text.

Now, certainly, someone using the binary formats specifications, and using the OOXML specification, could string them together and attempt a translation, but the results will not be consistent or satisfactory. It is the Carolino Effect. Knowing the two endpoints is not the same as knowing how to correctly map between them. A faithful mapping requires knowledge not only of the two vocabularies, but also the interactions.

The second item from Weir alludes to the BRM, but only in the sense that it mentions a concern raised there (and unsurprisingly disregarded due to lack of time). It's about macros, which Microsoft never liked talking about all that much. Microsoft hopes that nobody will spot and scrutinise for the weaknesses which only Microsoft has in mind, hoping to divert attention away from the parts most sensitive to unrebuttable criticism.

Finally, note that this lack of information on how to locate macros within a document makes it impossible for anyone to programmatically combine or divide OOXML documents which may contain macros. For example, imagine a 2-page spreadsheet, with a macro on sheet one only. How can it be split into two one-page documents, if there is no defined way to locate the script associated with page one? This is the type of automated composition and document manipulation that OOXML should be enabling. Similarly, how can one combine two single documents containing macros into one document, if there are no defined rules for locating and naming macros? Many basic types of applications,such as merging slide shows, etc., will break in the presence of macros.

The above topic was of interest to several NB's in Geneva, but could not be discussed for lack of time at the BRM.

The Fast Track to the Wastebasket

Microsoft may have taken a wild gamble by choosing an inappropriate route to ISO-isation. As a result of this, under great pressure, Microsoft needed to resort to breaking the law (more on this in a moment). Here is Groklaw's interpretation of Malaysia's press release, which we mentioned yesterday.

Malaysia Standards Says Most of Their Technical Concerns Unresolved at BRM; Fast Track Inappropriate

They were there. And they contradict the stories being put out by those in charge and by Microsoft. They did *not* have the opportunity to have their concerns addressed totally. Malaysia voted to disapprove the undiscussed bulk dispositions, although they had earlier voted to approve some dispositions that were discussed.

When All Else Fails, Break the Law

The OOXML scandal in India -- one which we covered here before [1, 2, 3] -- is finally receiving some press coverage. While the 'mainstream press' turns somewhat of a blind eye, Linux.com does a story.

Microsoft is encouraging its business partners to promote its Office Open XML specification (OOXML) to the Indian Bureau of Standards (BIS) and Ministry of IT. This move has incensed supporters of the rival OpenDocument Format (ODF) who fear that the "soft" Indian state may not be able to stand up to Microsoft pressure tactics.

It is encouraging to see that all these known and proven incidents get documented. Hopefully, the EU is watching this carefully and taking it into account (or Microsoft's accounting). ⬆

"If you flee the rules, you will be caught. And it will cost you dearly."

--Neelie Kroes (about Microsoft), February 27^th, 2008