With the SCO mess and Groklaw I remember reading that it is actionable libel to claim bad IP in the form of FUD. There may be better references but here is one:

http://blog.ebusinesslawgroup.com/labels/Libel.html

But the Lanham Act provides a remedy for something called "trade libel". It says, in pertinent part, the following:

"Any person who...in connection with any goods or services...uses in commerce any...false or misleading description of fact, which...in commercial advertising or promotion, misrepresents the nature, characteristics, or qualities...of his or her or another person's goods, services or commercial activities...shall be liable in a civil action by any person who believes that he or she is likely to be damaged by such act."

Did you read that carefully?

Read it again.

What it essentially means that if someone in your company says something misleading or false about another company, you could be in BIG trouble.

If it really was Steve Jobs, I think Xiph and maybe others would have a claim. I'd support a lawsuit. The depositions could get very interesting.

At least it would stop the rumbling and FUD and make them put-up or shut-up.

I don't think the word means what you think it means.

According to Webster: "marked to the highest degree by grandeur, excellence, brilliance, or competence"

Yet you simply say it manages to sort-of document a cumbersome updated legacy format for office documents.

I haven't looked at Mono, but must ask if you design your software like the OOXML - so that if I make a trivial change in the obvious place in one source file, it will break the whole thing unless I also update dozens of other places which I wouldn't guess would be referenced. Touch x.c causes the entire system to be recompiled under make? If you consider such "superb" design, I'd hate to see what you would consider bad design. Oh yea, completely functional yet minimal, clean, and modular code.

I would think the word "superb" wouldn't be applied to a rust-bucket that happened to run well enough (if you don't mind the smell of burnt oil) to get you a few miles to work each day. I would want both the powertrain, body, and interior to be clean and well engineered too.

You can do a superb job of specifying an atrocious design. In ISO-9000 processes, I usually refer to a perfectly repeatable cement life-jacket. Of course you'd sink like a rock, but as long as they are made within tolerance... Perhaps this is what you were referring to.

But you haven't said the underlying design is horrible, and it does sound like it is the binary formats recoded into XML. That might make it easy to write a converter, but says nothing about whether the coding is a good or bad design.

Even so, the OOXML document is not very well done. Minimally, the legacy support should be in various annexes, to separate it from the core design. There could be a lot of other structural improvements.

But this comes down to a fundamental question - DID YOU USE THE OOXML document - reading it fully just like you would do to ODF - to implement the section of Gnumeric, or did you simply highlight the excel-like sections which you already had code for and it just worked?

The proper way to test the questions is to give a group who has never seen either ODF or OOXML both specs and have them split up and start coding - without an oracle like OOo or Excel - and see how fast and how well they do. Let Novell sponsor such a contest, maybe over one of the holidays or something if you really want to decide the issue.