Gallery

Standard practice?

Posted on 9 Oct 2007 at 11:11

Inspector Jon Honeyball rumbles Microsoft's apparent machinations in the ooxml file format battle, and doesn't like what he sees.

Now, let me explain my real worry about all this. Let's say I want to write an application that modifies Excel OOXML files. Maybe it's a batch-processing system, or something that sits on my mail-queue environment checking files for appropriate content before they're sent out. There are endless reasons why I might want to look inside an OOXML format file and make adjustments to its contents. Now, let's assume, for example, my application checks on data for validity before the file is cleared to leave the building. On the desktop, a user enters 1234.1234 into an Excel cell and the file is saved in OOXML format. Further down the workflow, the file is ready to be processed by this app I've just written: I open up the zip file, navigate to the XML part and look for the cell contents, which is now 1234.1233999999. What do I do now? Should I change it back to 1234.1234? Should I leave it as is, despite the fact that it fails to validate against the known input? What happens if this is a legally regulated environment? Is it acceptable for me to handcraft my own ad hoc number-fudging engine to attempt to undo what Excel appears to have done? It's an insoluble dilemma.

The inescapable reality is that OOXML is just an XMLified version of BIFF, and a whole pile of BIFF baggage has exposed what was previously hidden. Before, I was quietly confident it would be possible to read and write Office XML files by hand, using whatever tool I wanted on whatever platform, but the reality isn't so simple. And there lies the dilemma: if the user entered 1234.1234 and meant 1234.1234, is it acceptable in an ISO standard format for that data to be stored as 1234.1233999999? I'd say the answer is clearly no, and that either Microsoft needs to fully document and make open its numerical fudge engine, or else OOXML should store the right numbers.

Now how will you react when I tell you that the Open Office 2.2 format stores this same 1234.1234 value as:

<table:table-cell

office:value-type="float"

office:value="1234.1234"><text:p>1234.12</text:p>

</table:table-cell>

Let's just walk through that: it's a cell, it's of type float, it has the value 1234.1234 and its text representation is 1234.12 (presumably 2 place display is set). Seems straightforward enough to me. Microsoft, however, deems that <v>1234.1233999999999</v> is an adequate approximation, which it would be so long as it's only ever interpreted via Excel's number-fudging engine every time you open it, and which may not be the case if it's ever opened by someone else's code, including mine. Which format would I rather work with?

Either way, my faith in this whole matter of the OOXML file formats has taken a considerable battering, and I find the issue - including the accusations (true or otherwise) of stuffing the ISO committee at a late stage - to be quite upsetting. ISO standards should be held in the highest regard by everyone, and they can only work if they're perceived to be impartial, cleaner than clean and free of any commercial bias. Bringing the whole ISO process into disrepute is an offence that Microsoft won't escape from lightly in the end.

Download a year of Jon Honeyball's Advanced Windows columns by heading to our Free Downloads site