Microsoft's OOXML Formulas Could Be Dangerous

hill101 writes "According to Rob Weir's blog, Microsoft's 325-page OOXML specification for spreadsheet formulas is deeply flawed. From basic trigonometric functions that forget to specify units, to statistical functions, to critical financial functions — the specification does not contain correct formulas that could possibly be implemented in an interoperable way. Quoting Mr. Weir: 'It has incorrect formulas that, if implemented according to the standard, may cause loss of life, property, and capital... Shame on all those who praised and continue to praise the OOXML formula specification without actually reading it.'"

Comments

Re:Guess what?

[azrider]

Touche on the high school part, forgot about that. :) The main customers are of course still enterprises. I still think the default argument should be radians.

Who cares whether the default argument is degrees or radians. Two things are missing from the quoted "specification" document:

1: What is the default argument

2: Is the specification consistent across all functions which use this type of value as an argument

A specification which conforms to neither proper or common usage is worse than no specification at all

This is what Rob Weir was saying.

MS claims this is a FULLY DEFINED STANDARD

[tinkerghost]

When other people claim a standard is fully defined, it means that all the standard use cases are defined* - units, expected parameters, optional parameters, etc. In the real world, nobody uses radians. Radians are used by engineers & scientists. Pilots, backyard builders, school children, and the occasional office worker use degrees.

To be honest, nobody cares if OOXML defines SIN(x) to take radians, degrees, gradians, or hyperbian-arc-vectors. What we care about is that someplace in the fully defined standard, OOXML needs to say:

DEFINE: SIN(x[,unit])

• SIN: geometric function dictating the height of a right triange with a hypotonous of 1 and an angle of x.
• x: parameter describing the angle to be operated on by the sin function
• unit - optional: one of a predescribed list of standard descriptors for angle:
  1. D: Degree - unit of angle defined as 1/360th of a full circle
  2. R: Radian - defined as the angle at which the length of an arc is the same as the radius of the arc. 1/2Pi of a full circle ~ 57.3 degrees
  3. G: Gradian - unit of angle defined as 1/400th of a full cicle.
  Missing unit parameters are defaulted to Radians. Unknown unit parameters will result in a type error.

That's how a proper standard useable for international work in multiple fields is defined. You do not just dump your US help file into the standard & call it done. I have had to deal with a lot of standards, both Military and Industrial, the OOXML standard is well below the grade of the average Mil or Ind standard.

That's before you get to the point of inclusions in the standard like "Must Replicate Office 98 Behaviour for this feature". Now, if there was a reference to another standard that defined Office 98 behaviour, then it's not a problem. However, I don't see a reference included in the OOXML standard. Worse, for dates, OOXML defines the proper behaviour as their broken implimentation of the Gregorian Calendar - a direct conflict to the existing ISO standards.

I don't care who sponsored this standard, it's not a properly writen standard. It has huge holes & it's contradictory to several existing standards. Either one should get it rejected. If MS cleans it up so it meets the actual requirements of a "STANDARD" then they should get approved. If they leave it as the crap heap it is, it should be rejected.

*- if passing sqr(-6) as a unit works in the implimentation, that's not the standards problem. However, if the standard fails to mention the default unit type & the existance of the unit parameter, then there's an issue.