It has been a boast for around around 6 months now. Microsoft’s OOXML fully defines spreadsheet formulas, and ODF doesn’t. The Microsoft boosters have been parroting the party line for quite some time.
Miguel de Icaza gleefully noted back in January:
OOXML devotes 324 pages of the standard to document the formulas and functions.
The original submission to the ECMA TC45 working group did not have any of this information. Jody Goldberg and Michael Meeks that represented Novell at the TC45 requested the information and it eventually made it into the standards. I consider this a win, and I consider those 324 extra pages a win for everyone (almost half the size of the ODF standard).
And Microsoft’s Jean Paoli quoted in May in InfoWorld:
As far as those 6,000 pages of specs is concerned, there are 350 pages in the OpenXML spec alone — half of the entire ODF spec — just to describe spreadsheet capabilities, which ODF doesn’t have, Paoli says. For example, ODF can’t describe or calculate a formula in a spreadsheet.
“It may sound amazing. They are working on it now. But the current standard doesn’t have it,” Paoli tells me.
There are many other examples, if you care to seek them out. But what you will not find is an examination of what OOXML actually specifies for spreadsheet formulas, or confirmation that it was done sufficiently. Maybe the assumption is that this would be a trivial task, documenting Excel’s behavior? What could possibly go wrong?
Let’s find out.
First, let’s take the trigonometric functions, SIN (Part 4, Section 188.8.131.527), COS (Part 4, Section 184.108.40.206) and TAN (Part 4, Section 220.127.116.113). Hard to mess these up right? Well, what if you fail to state whether their arguments are angle expressed as radians or degrees? Whoops. Same problem for the return value of the inverse functions, ASIN (Part 4, Section 18.104.22.168), ACOS (Part 4, Section 22.214.171.124), ATAN (Part 4, Section 126.96.36.199), and ATAN2 (Part 4, Section 188.8.131.52). It is hard to have interoperable versions of these functions if the units are not specified. What kind of review in Ecma would miss something so simple?
The AVEDEV function (Part 4, Section 184.108.40.206) should return the average deviation of a list of values. However, the formula given for this function is actually for calculating the number of combinations of n things taken k at a time. Nice formula, though. Jakob Bernoulli would be proud. But anyone using an OOXML spreadsheet application that follows this standard will be perplexed at the values returned by their AVEDEV function. Did these formulas get any expert review in Ecma?
It is hard to have confidence in the CONFIDENCE function (Part 4,Section 220.127.116.11). It is said to return the confidence interval around a sample mean given an alpha value, a standard deviation and a sample size. The problem is that this problem is under-defined. One must make an assumption, not stated here, as to the shape of the data distribution. Is it normally distributed data? Exponentially distributed? Weibull distribution? The standard does not define the meaning of this function sufficiently for one to implement it.
The CONVERT function (Part 4, Section 18.104.22.168) converts from one unit to another. Some conversions explicitly allowed include liquid measure conversions such as from liters to cups or tablespoons. But whose cup and whose tablespoon? Traditional liquid measures vary from country to country. In the US, a cup is 8oz, except for FDA labeling purposes when a cup is 240ml. But in Australia a cup is 250ml and in the UK it is 285ml. Similarly a tablespoon has various definitions. OOXML is silent on what assumptions an application should make. I guess I won’t be using OOXML to store my recipes, and certainly not to calculate medical doses!
Almost every one of the financial functions in OOXML depends on a “day count basis” flag, such as US (NASD) 30/360, Actual/Actual, Actual/360, Actual/365, European 30/360. These represent various conventions for how days and months are counted. The problem is that the OOXML standard does not define these conventions, nor does it point to an authority for their definition. There are subtle behaviors here, especially when dealing with leap years and Excel’s deviant treatment of dates in the year 1900. So lack of detailed definitions in this area make it impossible for anyone to rely on identical financial calculations from different OOXML implementations. This, in a field where being off by a penny can cause problems.
Almost 30 spreadsheet functions are broken in this way.
(What do you call a scientist whose calculations are off by 50%? A cosmologist. What do you call an accountant whose calculations are off by 1%? A crook.)
The NETWORKDAYS function (Part 4, Section 22.214.171.1244) seems simple enough. It returns the number of workdays (non weekend days) between two dates. Simple enough. Unless you live in the Middle East. The problem is that this function doesn’t provide a facility for distinguishing the different weekend conventions. I may have a weekend on Saturday & Sunday, but a colleague in Tel-Aviv might have off Friday and Saturday, while in Cairo it might be Thursday and Friday. This function lacks the adaptability to deal with this important cultural difference. Saying that the definition of the weekend is implementation- or locale-dependent won’t work either. I may be a French company in Paris dealing with contractors in Algeria. I need to have a French spreadsheet calculate schedules for workers at various locations and be able to exchange it with others offices using other OOXML applications and expect that they will get the same answer. Lacking cultural adaptability, OOXML fails approximately a billion people here.
Another example. Several of the statistical functions in OOXML are defined incorrectly. Take for example, the ZTEST function (Part 4, Section 126.96.36.1992). The key error is following the formula where it says, “where x is the sample mean.” The problem is that x-bar is the sample mean, not x. Someone who implements according to the text will give their users the wrong answer. A similar error is repeated in 8 other statistical functions. Certainly this is a typographical error, but this error changes the answer. Remember, this is an approved Ecma Standard and a proposed ISO Standard, not a 4th grade school essay. Denmark and Massachusetts have already said they will adopt OOXML for official business. Spelling counts. Providing the right formula and the right description counts. Copy and paste errors should have been taken care of back during the Ecma review.
I’ve submitted these spreadsheet formula issues, and many others, to INCITS V1, for consideration in determining the US position on the OOXML ISO ballot, but we never got to them during our two-day meeting in DC a couple of weeks ago, and may not get to them at all. There are simply too many other issues to read through and discuss. But I thought it was important to bring up these formula issues in particular, since Microsoft seems especially proud of their work in this area, delusions of adequacy which on reflection must now seem unwarranted. I’m especially concerned with the financial functions, since they are outside my area of expertise and may have additional errors that I missed.
So what is ODF doing about formulas? We’re continuing to work on them. Rather than rush, we’re doing careful, methodical work. We’re documenting the functions in great detail. Where we have the choice between the common naive formula for a function and one that is numerically stable, we’re documenting the stable function. For the NETWORKDAYS function, we created an optional extra parameter, so a user can pass in a flag that tells what their weekend conventions are. We have a professor of statistics reviewing our statistics functions for completeness and accuracy. We’re verifying our assumptions about financial functions by referring to core specifications from groups like the ISDA and the NASD. We’re creating a huge number of test cases and checking them with Excel and other applications.
Under Sarbanes-Oxley, a CEO or CFO puts himself at personal risk if he signs off on financial numbers derived from processes and tools that he knows to give erroneous results. So we utterly reject a rushed process that has lead to an Ecma Standard which incompletely and incorrectly defines spreadsheet functions. Some things are worth taking the time to do right.
As I’ve shown, in the rush to write a 6,000 page standard in less than a year, Ecma dropped the ball. OOXML’s spreadsheet formula is worse than missing. It has incorrect formulas that, if implemented according to this standard, would raise important health, safety and environmental concerns, aside from the obvious financial risks of a spreadsheet that calculates incorrect results. This standard is seriously messed up. Shame on all those who praised and continue to praise the OOXML formula specification without actually reading it.