de lcaza calls OOXML a "Superb Standard"

you-bet-it's-not-out-of-context writes "A blogger on KDE Developer's Journal has found an interesting post by Miguel de Icaza, the founder of GNOME and Mono, in a Google group dedicated to the discussion of his blog entries. Six days ago Miguel stated that 'OOXML is a superb standard and yet, it has been FUDed so badly by its competitors that serious people believe that there is something fundamentally wrong with it.' In the same post he says that to avoid patent problems over Silverlight, when using or developing Mono's implementation (known as Moonlight), i's best to 'get/download Moonlight from Novell which will include patent coverage.'"

Comments

Is Miguel speaking as a Microsoft officer?

[overshoot]

Downloading from Novell comes with a Microsoft patent license?

I'm sorry, Miguel, but this is getting weirder and weirder. You may be a sierra-hotel coder, but I'm not sure that translates into authority to make legal commitments on behalf of Microsoft.

Riiiiiiiiight....

[UncleTogie]

' In the same post he says that to avoid patent problems over Silverlight, when using or developing Mono's implementation (known as Moonlight), it's best to 'get/download Moonlight from Novell which will include patent coverage.'

I'll think about getting it from Novell....as soon as MS hands over the list of "patent violations". IMHO, this is just a try to make the "If it's Novell/MS, it's legal" line of shite more palatable.

If you're going to try to feed us a crap sandwich, do NOT tell us it's filet mignon.

Nope

[christurkel]

Little things like this in the spec make it less than superb:

Table like Word95

Only Microsoft has that information. No one else can implement this "superb" standard like MS can.

Re:Nope

[Anonymous Coward]

Which doesn't mean it can't be better than ODF, which is all he said.

I'm willing to believe that Office Open XML might in fact be a better format than ODF, because I've never actually taken the time to look at ODF.

I can't help but wonder if what he really meant is that if you remove all the backwards compatibility elements, OOX becomes a superior format than ODF. Personally I think Microsoft should remove all elements like that and resubmit their format. Then they might have a spec that really could be better than ODF.

Don't support ODF just because it's not the Microsoft format. Unless you've actually looked at both specs, there's no way you can say one is better than the editor.

And since you're just repeating classic anti-OOX FUD, I can be pretty sure you haven't.

Re:Nope

[DaleGlass]

That's clever. Did you miss the part of the standard where that sort of thing is required for backwards compatibility? Apparently only Microsoft
cares about that sort of thing, so that's why it's in the damn standard.

That's the completely wrong way to specify it. A "standard" that says things like "tables like Word 95" is worthless, just what's that supposed to mean anyway? If you want to standarize a method of brewing coffee you don't say things like "The way Bill Gates makes it", you specify the exact procedure to be followed. If the behavior can't be fully determined based on the standard, then it's crap.

Things like that shouldn't be in the standard in the first place. If you're opening a Word95 document and saving in another, then to preserve the formatting you don't say it's "like in Word95", you specify the list of attributes to achieve the same effect: padding, alignment, margins, etc.

Re:Nope

[IWannaBeAnAC]

The problem is that OOXML defines a bunch of tags for 'backwards compatibility', but doesn't define what they do. To say that 'ODF fanboys and FSF-sponsored trolls don't care about that sort of thing' is insulting. Lots of people, including FSF members, have spent thousands and thousands of hours trying to reverse-engineer Microsoft binary formats. A document specifying this behavior would be universally welcomed, by both the FSF and 'ODF fanboys', because it would then be possible to write high-fidelity converters between old MS formats and ODF (or from MS binary formats to a non-legacy subset of OOXML, for that matter).

Having a bunch of tags with no definition as to what they do is not an ingredient of a good standard. If you wanted to define a bunch of custom tags, it could just as easily be done as an extension to ODF, which, if it was well-defined, ISO and the open source community would surely have no problem with. Having a international standard where significant parts of it are 'depreciated', is itself rather bizarre. If the backwards-compatibility binary-format tags are depreciated, why include them in the international standard?

Re:Nope

[MMC Monster]

But if it can be ignored, will the document lay out the same in two different products? If layout is different, why have you gained?

Re:Nope

[Trelane]

Heh. How about "People who should use the Preview Button for $100, Alex?"

Patent Pledge

(This Post is Preview Button Approved!)

Re:Nope

[Anonymous Coward]

> That's clever. Did you miss the part of the standard where that sort of thing is required for backwards compatibility? Apparently only Microsoft cares about that sort of thing, so that's why it's in the damn standard.

*REQUIRED* for backwards compatibility? What's wrong with converting them to standard markup instead of hacking in undocumented things like that? And besides, you do realize that that means that every word processor from now on has to know and care how ancient word processors once worked, simply because the newly converted documents are really old documents in a shiny OOXML wrapper.

If they really care so much about backwards compatibility, shouldn't they bother to document how these things work? You know, so that everyone can use them? Oh, right, they don't want anyone else to use them...

> If the ODF fanboys and FSF-sponsored trolls don't care about that sort of thing, I reckon they can safely ignore them and not implement them. But I guess that's no fun because it eliminates one of the fav memes being thrown around to prove that the standard is somehow deficient.

Oooh! I had no idea the FSF was sponsoring me! Where do I get a paycheck? Oh, right, I don't. It's really clever to argue like that, too, when a "rogue" Microsoft employee was caught trying to bribe Microsoft partners to join their NBs and vote in the ISO. True, we can suppose that that one employee stepped over a line, but you do realize just how many Microsoft partners have jumped out of the woodwork to vote on this, right?

If "we" are the "trolls", why are the OOXML supporters the ones with financial and business incentives to do things that aren't sensible in terms of technology or standards? And I say "we" loosely because I'm just some lone geek nobody who knows that he will have to support the crap that is in MS Office at work and hates it because of that. I'm an absolute nobody that no one in either camp has heard of, but I gather and submit most of the ODF articles here, including Slashdot story on those back compatibility hacks that you're trying to debunk (which was my favorite, BTW).

> Complete with "OMFG the 1.0 implementation as a BUG!!! Therefore the standard SUCKS!!!"

Funny that: why is it only one side that brings up technical arguments and actual data on what actually works and what doesn't, while the other side calls people names? Oh well, I really hope you never learn that lesson. If PR actually had a clue, they might be more dangerous in spreading FUD to geeks. Though I suspect that you were just trolling me and aren't actually paid by anyone, I figured it was worth posting for the people who are actually interested in this information.

Well, you see, the reason I hate all those old bugs is because Microsoft shows no interest in fixing them. ODF is going through revisions to actually *fix* all of its problems. OOXML? They have tons of people spouting "it's not THAT bit a deal! calm down!" and NOBODY actually fixing the damn thing. Hint: if you actually *fix* the problems identified in the NBs' votes, the "no with comments" votes would become yes votes and you wouldn't need to cram the committees full of Microsoft Certified Gold Partners.

Oh, and while I already explained why "just don't implement" them isn't an option (those legacy tags NEVER go away!) I might as well point out that Microsoft does a really crappy job on backwards compatibility in Office 2007. You know, their flagship product?

Might want to know about THAT before you go shooting your mouth off... Or not. Frankly, if you don't, it just makes things a lot easier for me.

Re:Nope

[Anonymous Coward]

Miguel,

I have contributed code to OpenOffice.org and Abiword (not much, but a little). Mostly however my focus has been on word processor conversion software (not spreadsheets though, granted)

The formulas you reverse engineered from previous versions of XLS were unfortunately riddled with bugs (this isn't your fault -- these bugs came from Microsoft who were sometimes copying IBM!). See the problems in the CEILING function for example, and how with proper design OpenFormula has been able to emulate legacy bugs while providing a clean slate for the future.

I note that in your post you don't disagree with the cryptic naming conventions of OOXML (who could?), but you apparently think that ODF doesn't specify existing standards(?). Could you give some examples please of what you think?

ODF builds upon XML, Unicode, XSLT, XHTML, XForms, SVG. Because these are existing standards you can choose from many vendors, and you can find a lot of developers skilled in this tech (well, perhaps not XForms)

OOXML builds upon XML, Unicode ... then it's all VML, DrawingML, and so on. The backwards compatibility isn't actually defined in OOXML (eg, autoSpaceLikeWord95 for east asian languages isn't defined)

I'm not a zealot and personally I think OOXML has a lot of good features that should be merged into ODF.

And please Miguel, I didn't insult you, so lets not use the "armchair general" insults. We can stick to the technical arguments :)

Re:Nope

[The Bungi]

You're missing the point. Backwards compatibility is only important for Microsoft, not for Sun or RedHat or the FSF or anyone else that is pushing ODF. Once you realize that, you also realize that you can simply throw away all the compat crap and create your own OOXML reader or writer or whatever you need to do.

Microsoft however cannot afford to throw away almost two decades of compatibility, least of all compatibility with versions of Office that still have hundreds of millions of users. Nor are they required to tell you or anyone else how Word 95 rendered a table.

BTW, it's hilarious that someone who uses terms like "the open source community" is happy to suggest that Microsoft can modify ODF to support its own legacy customers. I can almost hear the cries of "embrace extend extinguish" coming out of that.

Re:Nope

[IWannaBeAnAC]

No, I'm not missing the point. Microsoft can do whatever tricks they want to keep their vendor lock-in. That is the way the captialist system works, and under those rules it is allowed. Their rights to do that end at the point where they submit an international standard. At that point, it must be open and completely independently reproducible. If they can't accept those terms, then don't submit it as an ISO standard.

I was trying hard to word my reply in such a way as to NOT invoke cries of "embrace extend extinguish". Again, the bottom line is standards of documentation and openness befitting an international standard. If Microsoft chose to document their proprietary binary formats in the form of an extension to ODF, and (especially!) if they submitted the resulting document as a well-formed standard to ISO, then I am sure that 99% of the open source community would welcome it. Better still, though, would be a converter from the binary into a non-legacy format. That almost certainly isn't possible without loss of fidelity, but most people could live with that. Note that if you are going to use any non-Microsoft software that uses OOXML, then you are not going to get a lossless conversion anyway, because no one other than Microsoft will ever be able to implement the depreciated and not-defined backwards-compatibility tags!

Re:Nope

[I'm Don Giovanni]

"But if it can be ignored, will the document lay out the same in two different products? If layout is different, why have you gained?"

Are you serious?
Browsers lay out HTML differently from one another.
Hell, K-Office and OO.o lay out ODF differently from one another.
Hell, frikkin plain text editors lay out ASCII text differently from one another (some use \r\n (or \n\r), others use \n, and others use \r for line-endings).

Same goes for any data-processing format you can think of.

These aren't print-layout formats like PDF. Content is the primary issue, "lay out" is a secondary concern.

Re:Nope

[Yaztromo]

Yaz, you wrote an essay and ignored the part where I said that ECMA was going to document that for the next batch of issues to resolve in the spec.

I didn't ignore it at all. I'm glad this is something that the EMCA is eventually going to resolve. My comment is solely as to why it's important that it is documented, and why your statement that "it's optional" is hardly a solution. It may be optional, but it's important to implement to give users the expected level of interoperability, and this is why many people have expressed concerns about the standard as Microsoft has originally submitted it.

So they know about the issue, they will write the docs for it, and integrate it into the doc.

So basically "Your bug is being going to be fixed". Next issue.

I think you and I can agree that the standardization organizations are doing a good job of ensuring that the standard is itself up-to-standard. But I can't subscribe to your opinion that nobody has any right to complain about the standard as it was submitted by Microsoft, just because it will (hopefully) eventually be fixed. I can appreciate that these faults will be fixed, but that doesn't mean that I (or anyone else) have no right to comment on its current state.

In addition to the above I predict it does not matter, because its a legacy setting and they are themselves trying to not drag documents that contain that.

So they say, and for now, but I've been a Microsoft watcher for more than long enough to say that I'll believe it when I see it. And "trying not to" doesn't mean "won't" -- I'd be significantly happier if Microsoft were to say "we won't use these legacy tags ever", and then kept their word (forever -- in which case they would be unnecessary to have in the standard, as I imagine nobody else is going to need to use them if MS itself isn't going to use them).

Yaz.

Re:Nope

[IWannaBeAnAC]

I've bookmarked that link to read later but, firstly ODF already includes a mechanism to provide application-specific attributes, which any application (including MS Office) is free to make use of, and secondly Sun doesn't control the ODF standard anyway. If Microsoft proposed an extension to ODF there is nothing Sun can do to prevent them from submitting it to ISO.

Re:Nope

[Anonymous Coward]

You do know that you sound like a 12-year-old, don't you?

A couple of points, just because I feel like arguing:

• You are right, Microsoft has no obligation to do anything - but this is an ISO/ECMA standard proposal we are arguing about, and ISO has no obligation to support Microsoft's customers.
• "commercial ecosystem around software" - that's better known as "vendor lock-in". It's in a vendor's interest to get that lock-in. It's in a customer's interest to avoid it.
• OOXML exists because some large government customers, while looking out for their interests, decided that vendor lock-in was bad. Microsoft tried to ram OOXML through to give their formats the appearance of not being locked in - but it's only window dressing, it is still proprietary.

And yes, 6000 pages is a legitimate debating point. That's just plain ridiculous.

Re:Nope

[Anonymous Coward]

Well the ECMA guys (which, from your other comments, included Novell representatives, apparently) did a f*cked up job to allow that thing through as their "standard". The ISO fast-track is meant for irreproachable standards, not for works in progress. What about the VML that's "deprecated", hence undocumented and not covered by the patent pledge (to quote: "necessary to implement only the required portions of the Covered Specification that are described in detail and not merely referenced in such Specification"), but will of course be output by Word et al?

Not to mention that the so-called patent pledge is joke anyway: any company that implements the standard pretty much forfeits its ability to sue Microsoft, even on unrelated products. So unlike Sun's ODF license... And, as I noted back then, it's a promise to you, not a redistributable license. There's nothing in there that says Microsoft won't sue your customers. There's no guarantee that they won't pull it either.

Standard, to anybody but you, means you can pick it up, as well as the standards it references, and implement the thing and expect that it interoperates with the other implementations out there. OOXML is no such thing. It might be superb (the 1900 is a leap year thing, 1-2-3 bug or not, and the profusion of text styles formats suggests otherwise tho). I'm sure it's much easier than ODF to add to an application that's already based on the the binary Microsoft file formats, such as Gnumeric. But it's not a standard. End of story.

And will you please stop ending your comments with ad hominems like a spoiled brat!

I'm not asking you what's the status on those C/C++ extensions allowing the seamless integration with .NET in general and C# in particular that you said were fundamental to start Mono 6 years ago, am I? ...

D'oh!

Re:Nope

[mobydobius]

Little things like this in the spec make it less than superb:

Table like Word95 instead of tags like this, why not just ensure that OOXML is flexible enough in its format descriptions that "autoSpaceLikeWord95" and "lineWrapLikeWord6" behaviors are able to be described natively. this seems more vendor neutral, and even a sort of test that OOXML is a rich enough language.

Re:Nope

[VGPowerlord]

And why do you care if they are there? Do you figure the evil Microsoft will have some tricksies up their sleeves because of these tags? What part of the phrase "ignore them if you don't care about backwards compatibility" do you fail to grok?

If a major Office competitor implemented OOXML but ignored the backwards compatibility parts, Microsoft would be sure to use those when saving OOXML files in MSOffice just to make sure they don't look right in the competitor's office suite. Which part of that did you fail to grok?

Re:Nope

[Anonymous Coward]

>>Table like Word95
>>Only Microsoft has that information. No one else can implement this "superb" standard like MS can.
>I think we have all heard about this one, and the ECMA guys already know that they have to provide more information about this.

Only because the vote BARELY failed, even though Microsoft bribed partners to vote yes, and officials from corrupt third world countries who NEVER before has shown any interest in the standard process suddenly shows up to vote yes.

I hope you will be contributing the code to OOo and AbiWord to support this tag as you seem to care about it so much (it is an optional tag that can be ignored).

No thank you, I prefer to devote my programmer hours to REAL standards and open source projects, not your divide and conquer bullshit.

Re:Nope

[bentcd]

A "standard" that says things like "tables like Word 95" is worthless, just what's that supposed to mean anyway? I have been wondering why the standard is so mind-boggingly long. Why can't it just say "Do OOXML the way Microsoft does it" and be done with it? Seems such a waste to write 6,000 pages (or whatever) when you can say the same thing in seven words.

Re:Nope

[Eivind]

You're wrong. Including old ways of doing things for backwards compatibility can be fine. Though in that case you should:

a) Specify what exactly the tag means, not just "like word95", but put down in words what exactly that was.

b) Mark that particular tag as deprecated, meaning new implementations should *read* it correctly, but never *write* that particular tag, unless it was already there in an opened document.

Microsoft did neither.

Does this guy have any credibility left?

[AuMatar]

First Mono. Now he wants us to download stuff from a specific vendor to get patent protection. And finally he thinks a standard that has hundreds of pages of backward compatibility modes for 10 year old apps is a good standard? Is there anyone not ignoring him completely yet?

Re:Does this guy have any credibility left?

[Anonymous Coward]

you mean first gnome; what a load of crap this guy comes out with.

Re:Does this guy have any credibility left?

[Joey Vegetables]

I'm sorry, and I do not mean to detract from his significant accomplishments, but I have to agree that this episode speaks poorly to Mr. de Icaza's credibility. The deficiencies of OOXML are severe, well-known, and unfixable. Not only is it not a "superb standard," but it is not something that could correctly be described as a "standard" at all, because no one, including Microsoft, could implement it correctly, and no one including Microsoft even claims to be able to do so. ODF, for whatever problems it might have, is implemented by and/or for all major office suites, including (via a third-party plugin) Microsoft's own, and it is a published ISO and IEC standard.

I don't know whether Mr. de Icaza simply cannot see this, has chosen not to see this, or has not really bothered to seriously examine it before making such an authoritative pronouncement. But any of these problems speaks poorly to his credibility, and bodes poorly for his continued status as a spokesperson for the free software community. My advice to him would be to continue to write great code, but try to refrain from public comment about things he for whatever reason clearly does not understand.

Re:First things first.

[nuzak]

It's his own blog.

It's not too surprising

[Analog]

Miguel has been fascinated with Microsoft since long before he started writing Gnome, and that fascination shows no signs of having waned. Unfortunately, while it allows him to see the good things MS has done in a clearer way than many of those in the free software world, it also tends to give him a bit of a blind spot where some of their deficiencies are concerned.

The retarded cousin no one wants to acknowledge

[Anonymous Coward]

Miguel is like the mentally challenged relative that everybody smiles at lovingly when he speaks as he is sitting in a pool of his own urine.
At what point are we going to treat him as an adult and tell him he is either out of his freaking mind or so far up the Microsoft orifice that he cant see the light of day anymore?

Mono always left me a nauseous feeling and I tried not to attack Miguel because of his work with GNOME but I think we've past the point where he was harmless and maybe misguided.

Yes Miguel, we all get our technical news from Groklaw because you obviously think that everyone who doesnt agree with you is an FSFer. Check the comments from AROUND the planet this past few weeks from people who've studied the specs and you might be shocked to find out a few things.

Had this been signed by Bill Hilf, I wouldnt have said a word, its part of his job description but Miguel was supposed to be one of 'us'.
Watch as his language starts incorporating more and more of the key phrases that Microsoft execs repeat like a mantra.

A buddy on IRC just mentioned that Miguel must have been very unpopular as a kid and is now trying to fit in with the older, cool kids. And whenever that situation used to happen in school, the dweebs who try to 'fit' in usually come across as ackward, clumsy and borderline retarded.
Just like Mig.

And forget folks, Novell is the best distro out there because they have patent protection.
F U Miguel.

Sincerely,

Lyle Howard Seave

Re:Another non-story posted by kdawson

[Gideon Fubar]

as much as that seems to be the consensus atm, what do we do when the post comes from Miguel's own blog?

Technical proficiency more common than wisdom.

[argent]

I've seen this over and over, not only in the tech field. Somebody who is "highly respected" by a great number of people, because of technical proficiency, wisdom, or what have you, expresses an opinion that a lot of people disagree with.

One can disagree with someone without losing sight of their strengths, and respect someone's strengths without losing sight of their weaknesses. In this case: just because someone is technically proficient, that doesn't mean he's wise.
I don't consider depending on standards that Microsoft (or any company) controls "wise", whether that's OOXML, CIL, or Silverlight. Miguel's score on the subject is public knowledge.

What damage has he done?

[jcr]

Use his stuff or don't. It's not like all the coding talent in the world is being exhausted on his projects. I have no interest in .NET or Mono, and what's it to you if other people do?

-jcr

RTFL - Submitter is a Jackass

[DreadSpoon]

Read the fucking link, instead of ripping on the guy for selectively chosen comments without their supporting context and explanation.

(a) He says OOXML is great not because the specification itself is a work of engineering genius, but because out in the Real World is easier to implement than ODF. That might not be for a good reason (OOXML is similar to existing World formats in structure, and so existing code is easily modified to use it, where ODF requires an entirely new approach and so is far harder to add to existing software), but it's certainly a different story than Miguel just blindly loving the OOXML spec.

(b) The patent protection claim is exactly what it sounds like, except for the fact that there are NO known parents which Moonlight or Mono infringe. It's a simple of matter of, "if something comes up, we won't sue your customers." Those same companies (Microsoft and the MPEGLA group) are still totally free to sue the developers and companies behind FFMPEG, Linux, GNOME, KDE, Apache, X.org, OpenOffice.org, etc. Nothing about the protection Novell offers will increase the risk of those lawsuits - all it does is decrease the risk for people who download from them. It's a nice gesture that some suit-wearing types give a fuck about, and the rest of us are free to ignore just like we ignore the patent minefield for every other project, all of which are guaranteed to be infringing _something_.

(c) The article submitter is a sensationalist jackass.

Re:RTFL - Submitter is a Jackass

[argent]

OOXML is similar to existing World formats in structure, and so existing code is easily modified to use it, where ODF requires an entirely new approach and so is far harder to add to existing software

I would rather wait another year or two for tools that implement a good spec than get MORE tools that implement Word's fundamentally broken document model. I would rather work in raw HTML 1.0 using ED than try and write anything sophisticated in a program like Word (or Pages, for that matter, which uses the same structure). Unfortunately since I work with people who use these formats, I must adapt.

That statement proves it:

[Burz]

Icaza is a thoroughgoing Microsoft shill.

OOXML is objectively horrible/unworkable as a "standard" and if Icaza's attitude is reflective of (or impacts) Novell's then IMO what little FOSS credibility and good standing Novell had will have vanished.

It seems Mono has become a non-starter and he needs another way to grab attention.

Re:That statement proves it:

[kjart]

Icaza is a thoroughgoing Microsoft shill.

Yeah, starting with an ad hominem makes me want to take your arguments seriously.

Re:That statement proves it:

[h4rm0ny]

Isn't it obvious by this point that Microsoft wants to take over Linux and is trying to do this via Novell (SuSE) and threatened patent litigation? Similarly, Mono is an attempt to draw Linux (and even Macs) into trying to compete with the Windows O/S in a game stacked in Microsoft's favour. OOXML is [b]demonstrably[/b] a hideous mess. A person in this position cannot be sincerely mistaken in thinking that it's a good format. They have to be lying.

Re:That statement proves it:

[JohnFluxx]

It seems that your whole argument is that ODF should have implemented Excel bugs in the standard just in case a user wants to use ceiling in openoffice, then save as Excel, open in Excel and modify the formula so it's not ceiling any more, then import that back into openoffice and save as an Excel file.

And this makes you so angry that you hope ODF will fail?

The function is called ceiling. The mathematical definition is here: http://mathworld.wolfram.com/CeilingFunction.html
ODF is correct, OOXML is wrong. Nuff said.

Re:That statement proves it:

[PitaBred]

Ummm... what date exactly is "39013"? I mean, I'm not going to just type that out of the blue. I'd want to do something more like
If(TODAY() = '11/02/2008', "Due Today!", "Not Due Yet")
Which, I believe, you can do with most anything. A random number with no relation to how people perceive dates is not useful in a spreadsheet. Just because Excel does it doesn't make it right, and doesn't make it something we should continue to do. You don't still have a kick-start on your car, do you?

Re:That statement proves it:

[PitaBred]

And then you get unmaintainable pieces of shit like Windows, that essentially randomly has bugs, and the only way to fix it is to reinstall it. I'll update a few spreadsheets if it means I can count on my computer behaving, well, like a computer. Responding properly and exactly as expected to inputs.

Re:Always been a MS Shill

[jmorris42]

> He's been praising Microsoft for years, every chance he gets.

Not only that, he has yet to encounter a Microsoft technology he didn't like so much he wanted to clone it into the Free Software world and make us all dependent on it.

For years the joke was GNOME was cloned Microsoft internals with a goofy (vaguely MAc inspired treat the user as an idiot motif but without the consistency or polish of the Mac UI to make up for it) UI while KDE was cloned Microsoft UI with goofy Trolltech internals. Then Miguel hell head over heels in love with .NET and was all setto rewrite GNOME using that patenttrap. Thankfully saner heads have prevailed.... so far.

The sooner we all write off Miguel and Novell the better off we will all be. Taking any code from that camp is just inviting a lawsuit. Sooner or later, BOOM!

Really?

[tkrotchko]

"It should be added that de Icaza is a Novell VP"

And yet his blog sounds like it's written by someone very young. Consider this from his answer to a post on his site:

    "You do not have to pay anyone any money. Duh.

      Nobody said so. Either English is not your first language, or your reading
      and comprehension skills are busted.

      Miguel."

Is that what passes for civility and adult behavior at Novell from a VP? I must say I'm a bit surprised.

Novell is distributing concealed patent landmines

[pallmall1]

A poster on Miguel de Icaza's blog asks:

Will I have to suffer > the shadow of Microsoft patents over Silverlight when using or > developing Moonlight?

Miguel de Icaza answers:

Not as long as you get/download Moonlight from Novell which will include patent coverage.

Then, in a later post, when asked about Novell not shipping code that infringes on Microsoft patents, Miguel responds with the chilling statement:

First of all, am not aware of such Novell promise to "never ship code that infringes MS patents".

Miguel de Icaza then goes on to explain that Novell doesn't care if they ship any infringing code since Novell has a patent agreement with Microsoft, and Novell isn't going to bother working around or removing infringing code (if it ever is identified) for the same reason.

Thanks, Miguel. You make it very clear: all code downloaded from Novell must now be regarded as (Microsoft) patent encumbered.

I _want_ moonlight to succeed.

[ultramkancool]

Well, for once, I want a microsoft technology to succeed (read: hopefully, in the long run, replace flash). I'd rather have an open source implementation of a microsoft invention then some proprietary binary (like linux flash). If Macromedia decided to open source the flash player, then, sure, I'd favour them :)

Re:OOXML.

[suv4x4]

Yes, he said this: "ODF's model of 'chartness' didn't fit well with Gnumeric. In contrast XLSX may be ugly, but it''s concepts were very familiar from XLS. We already had much of the code required to handle it."

He didn't say it's a great standard. He said it's a great spec upon XLS serialization in XML, and hence it's easier for him to port XLS importer to XLSX importer. Is anyone even arguing about this here? If there is I never saw him/her.

May I entertain the possibility you have difficulty understanding the fundamental difference between good spec, and a good standard?

This, and comments like "OH MY GOD THEY USE A BITFIELD THAT IS JUST SO-NOT-XML (am using caps to encapsulate the outrage in an actual discussion when an acquaintance of mine lost it)" doesn't help your position stand up.

When you publish your opinion, people read this opinion and you get feedback on it. If you were an average Joe, probably no one would care. You're not however, this is why people like you should put more thought into what they put out in the public than you did, and then now whine that someone "obsesses" over it.

wrong use case

[m2943]

Microsoft's Office XML Standard is clearly bad in a number of respects: unnecessary deviation from established standards, encapsulation of binary formats, and backwards compatibility with obsolete MS Office formats. It does, however, indeed have the advantage that it's easier to import for code that's already been written to import the old binary formats. On the other hand, it's just as clearly harder to process using XML tools.

Now, the question is: are the primary use cases for which we should design an XML office format office suite input/output routine, or are the primary use cases XML processing.

Well, let's see: there are half a dozen office suites around: MS, Gnome, KDE, Apple, and a couple of commercial ones. Each of those needs to implement a reader/writer once. On the other hand, there are thousands of uses and implementors for information extraction and transformation of office documents.

Seems pretty clear to me that we should optimize XML office formats for XML processing, not for the convenience of the implementors of office suites. And that, in a nutshell, is why Microsoft's office format is worse than ODF.

Re:Always been a MS Shill

[kcbrown]

The sooner we all write off Miguel and Novell the better off we will all be. Taking any code from that camp is just inviting a lawsuit. Sooner or later, BOOM!

In other words...

No boom today. Boom tomorrow. Always boom tomorrow...

Re:Always been a MS Shill

[smittyoneeach]

I dunno. I figure Miguel is a smart fellow who is managing to do well for himself and support free software simultaneously.
When the time and market is right, Redmond will push a .Net-ified version of MS Office, with obscured assemblies the run fine on Mono.
Project vomit while you may, if it keeps gives Redmond life beyond Vesta, then Miguel may be doing us all a little favor.

Re:Try #2

[miguel]

OH MY GOD THEY USE A BITFIELD THAT IS JUST SO-NOT-XML

Oh my God, they used a bitfield to encapsulate Microsoft-proprietary extensions like VBA rather than standardizing them as well. (Proper capitalization used to represent more somber tone of retort.)

Got a reference for that? This is the first time I hear that the bit field was for encapsulating VBA and I do not see that referenced.

Miguel

Re:OOXML.

[stilborne]

> but we have to support them both *anyways*, so its not like its a big deal.

Holy mackerel.

First: I really don't care to get into a pissing match about the deficiencies of OOXML as a possible standard (they are legion and often fundamental; and whether or not you understand that and/or choose to minimize the severity of these things changes nothing). I will say that I'm very happy to finally see at least *some* open documentation for the new Microsoft Office format; that has to make things easier for the people implementing filters. As such I am completely unsurprised that those people are happier than they were a couple years ago. In fact, I'd be surprised if they weren't. That part is probably something you and I agree on =)

However the quote above is utterly shocking. Let me explain what I mean:

You are right that we have to support both OOXML and ODF out of practicality. But you know what? That sucks. It would be best for everyone if there was only one format to support. Nobody would lose in that scenario, except perhaps the owners of companies with business models that depend on format variance to sell their product.

In the case of document format storage, a standard is truly important because formats (poor or not) that eventually lose implementations over time carve out blank spaces in our history once we can't read them properly. These same formats are also the source of certain information inequalities in society (e.g. those who can't obtain an implementation for financial, social or political reasons). This may not matter so much for Acme Inc's quarterly reports but it sure does for government, health and other socially vital information. Remember when some hurricane Katrina victims couldn't use the FEMA website because they had slightly older computers? This isn't a made up boogyman, this is stuff that bites us as a society fairly regularly. Now imagine a hundred years from now when we can still read the constitutions of our countries, research papers, poetry and other examples of human kind's great literary works that are hundreds or even thousands of years old ... but can't read the documents we're creating at the start of the 21st century. How will we learn from our history if we can't study it fully?

Getting proprietary formats out of the way as soon as possible so that we do not extend this mess any further than necessary is absolutely the responsible thing to do in light of our (hopeful) future.

By allowing OOXML to pass from "specification" to "international standard" would be doing exactly that: extending the problem as it will give years if not decades more life to the format. If OOXML was rationally implementable and properly documented, it wouldn't be as big of an issue. It would be, as you put it, simply suboptimal. The fact of the matter is that OOXML is not rationally implementable and not properly documented. That's why it lost the recent vote; it wasn't because of lobbying (and trying to imply that when Microsoft got its hand caught in the cookie jar is pretty ballsy, by the way). Are some interests acting out of concerns for their business models or pet projects when they rally for ODF and against OOXML? I'm sure they are; but that alone isn't reason to dismiss the fact that OOXML is problematic and that we don't need two standards (any more than it is to dismiss OOXML just because it comes from Microsoft).

So please, admire OOXML for what it is: a step forward in documenting what historically has been one of the more pernicious sets of file formats we've had to deal with; but don't mistake that for being a reason to make it an international standard which will only prolong the issues that are part and parcel of the Microsoft Office formats, even in this current version of the specification.

I know that having a bunch of people shit on you in public sucks major donkey nuts and certainly would put most rational people into a rather ungracious mood, but please think above that noise and consider with your intell

Re:Good morning, people.

[TheWanderingHermit]

Was that before or after he started secretly working at SCO?

Plays well with others

[Tony]

OOXML has been so politicized that it is dangerous to even bring the topic up.

And why do you suppose this is? And who started politicising it?

Microsoft pulled out of the OASIS ODF working group during the creation of ODF. Instead of working for a standard, they decided to go their own way. As the giant in the industry, they have the clout to do so. When it seemed they didn't have a sure vote for fast-track of their own single-vendor standard, they are the ones who gamed the system, strongly urging their close partners in member countries to join and vote in the ISO process.

Microsoft has arrogantly assumed the industry will follow them. It is this arrogance, and a good memory, that has produced this resistance to their market push. Microsoft has twisted standards to funnel customers their way (Kerberos, IMAP/MAPI, etc). They have shown they have no interest in playing well with others, which is the entire point of a standard.

As far as Jody hacking in support to import cells from a spreadsheet: good for him. But how is the display and print and graph fidelity? Will it look the same as it does when printed from Microsoft Office? Will cell styles look the same on-screen? Or does Gnumeric only do about as well as it does with .xls files-- only moderately okay?

Support for reading in cell data is one thing. For that, the OOXML-published spec is a godsend. But that isn't the real test-case here. ODF is designed for disparate word processors to operate on the same files with equal fidelity. It's designed with internationalization in mind, including dates and times (something at which I hear OOXML isn't so great, though maybe I'm just swilling the FUD-aid.)

If OOXML is such an excellent spec, then Novell should be able to create a filter that will be able to import and export moderately-complex OOXML files that look almost identical (in print and on screen) in MS-Office and some other non-Microsoft product. (Sorry about that sentence.) If it's as good as you claim, we should see this product before ISO voting begins in February. And if it is to make a good standard, I should be able to download the filter from anywhere, hack it, and redistribute it without fear of patent litigation.

Do you imagine this is doable? Are you willing to back up your claims with some promises (not as a Novell employee, but as Miguel the hacker)?

Actually, I don't think even Microsoft can claim I will be able to download it, hack it, and redistribute it without permission from Microsoft. And that right there is reason enough for me to fight it.

Re:Always been a MS Shill

[ajs]

> He's been praising Microsoft for years, every chance he gets.

Not only that, he has yet to encounter a Microsoft technology he didn't like so much he wanted to clone it into the Free Software world and make us all dependent on it. ... Taking any code from that camp is just inviting a lawsuit. Sooner or later, BOOM! All that aside, OOXML may not be a horrible standard. It's probably been in the works for quite some time before we ever heard about it, and Microsoft does employ some of the brightest minds in software. The problem is that Microsoft's grubby hands at the wheel of a standard for file format will mean that their "reference implementation" (Office) will embody a set of defacto addenda to the standard, and no one will be able to produce a truly compatible implementation.

That leaves us not far from where we are today.

Again, once more with feeling

[theolein]

Miguel, you seem to feel that you can play words one way one minute, then another way the next. My own personal opinion is that you are losing a lot of credibility with your own personal opinions. There is a very good non technical reason to dislike OOXML, just as there's a very good reason to dislike Mono, and your post that it would be best to download silverlight from Novell's servers to avoid patent hassles simply transfers the undesirability target from Microsoft to Novell, because enforcing users to use Novell software is no better than forcing them to use Microsoft software to avoid legal patent threats from Microsoft itself.

I don't know how many hundreds of people posted here warning you about the dangers of using Mono on Linux, the very FUD patent threat statements that Microsoft actually then later made in order to coax people like you and your bosses into becoming even more enslaved to Microsoft's whims than those who use Windows itself.

You don't seem to see Microsoft is more than likely to use OOXML and Silverlight as clubs to threaten people with later on. That's the real reason why OOXML is dangerous.

Re:Always been a MS Shill

[aichpvee]

Well he's definitely doing well for himself. I don't think I'd call throwing free software under the bus "support" though.

Re:OOXML.

[jmv]

I can explain the date situation to you if you want. It is a bit complicated and most people have no idea of why this is decision is important.

I personally do not care enough on that one, just thinking that it's bit stupid that ISO would be saying "here's how you handle dates" and later say "but in a text document, you actually do it differently".

As for SVG, I do understand the frustration around it, but for the longest time those "in the known" were pretty unhappy with the direction that SVG took.

SVG may have its flaws, but at least it was agreed on by different people/orgs. Again, I don't see the point in redefining a new standard (on which nobody except MS has any input) within a new text document standard.

I should add that Math people dislike MathML anyways, and they would much rather use TeX.

I have no opinion on MathML anyway (and do use LaTeX for 99% of what I write, OO.o for the rest), but again if ISO bothers creating a standard for something, it should at least make use of it.

I agree that we have a last resort with ODF "Look it up in OpenOffice", but if "look it up" is good enough, does that not defeat the purpose of documenting ODF in the first place? The idea of a standard was so others could interop without having to sort through 8 to 9 million lines of code. And your average guy that was to generate some ODF or OOXML will not really have the skills to read through all that C++. My guess is that most people would write a file in either OOo or MSO save the file and open it up in an editor to see what the thing looks like and generate with a bunch of print statements what they want. To this crowd "get the source" is probably not very useful.

I agree that even ODF should define everything in the document instead of having it in the code. That being said, the information still exists in a form that is publicly accessible. Any person with enough time and skills can implement those app-specific features. That is not the case with OOXML. MS can (and does) hide the format and the only hope to know how it works is reverse-engineering. This is much harder (and prone to legal trouble depending on how you do it) than looking at the OO.o source code. And *even* if you manage to reverse engineer the format to a point where it works flawlessly with 100% of the files you've seen (unlikely), you're still left with two problems:

1) You'll never know for sure your converter works on strange files you may not have seen (thus opening up to FUD of the kind "do you really *trust* this app with your legal documents")
2) For backward compatibility reasons, it is common to first include features only in the "decoder" for a format and then only support them later on the "encoder" side. That means that there are certain features that could be already in there, but that you will never actually see in a file (i.e. can't reverse engineer) until a new version of MS Office decides to actually generate files that use it.

Overall, it's really the "read the MS Office source code and you'll get it right" that makes OOXML completely unacceptable for me. And it would still be unacceptable no matter how beautiful the other parts are. A standard that nobody except one company has any chance of supporting perfectly is just not a standard. It's a proprietary format that pretends to be open.

You have chosen to introduce a new topic: should it become a standard? And should it be a rubber-stamp standard? Well, I do not know the answers to that. In fact, am of the opinion that most standards in the "big boys" space are tools to club your opponent ("ISO standard: check!").

It's unfortunately becoming a bit of that but it doesn't have to be. I believe most of the IETF and W3C standards are fine with that respect. Same for ISO actually. And personally, I won't mind if the "big boys" club their opponents by using open standards. I do mind if they introduce pseudo-standards that leave enough unknown to make sure they're the only ones being able to actually implement the thing.

The BSI also disagree

[cyclomedia]

http://www.xmlopen.org/ooxml-wiki/index.php/Office_Open_XML_Overview

Well written and critiqued from the Granddaddy of all Standards Organisations. They have no axe to grind whatsoever, now someone tell me THAT's FUD.

7000 pages says its fundamentally wrong

[DrXym]

Compare - ODF 700 pages, OOXML 7000 pages. ODF unencumbered by legacy issues, OOXML heavily encumbered by legacy issues.

I think it will be next to impossible for ANYONE except Microsoft to implement OOXML. Which is just the way they like it.

Re:Always been a MS Shill

[Wiseman1024]

That's because he has a long term ass rimming contract with Microsoft. For years, everything he did sucked hard and hurt the community. Mono, Silverlight and everything he does give Microsoft legitimacy to say they're open and portable, for almost free (whatever it took to buy him). Now he's also a patents and OOXML bully.

I wonder why the community keeps listening to the sold out crap he has to say. If we treted him like what he is -- a troll and a sell out -- and ignored him like we ignore the retarded Windows Vista using Microsoft trusting neighbour, he wouldn't have the power he has and he couldn't hurt the libre software community as he's doing.

Re:deficiency

[Spy Hunter]

The post you linked to is written by someone who clearly doesn't understand that sometimes data crosslinks to data

Your insinuation is clearly false. He traces the exact crosslinks you assert he doesn't understand. You miss his point, which is that the crosslinks he is complaining about are unnecessary cruft, unbefitting a proposed standard, as proved by comparison to ODF. Furthermore, he has many other complaints besides the crosslinking stuff. The OOXML "standard" is littered with such cruft, due to its heritage as a practically 1:1 dump of all the hacks and bad ideas Microsoft has ever crammed into their previously opaque binary format, with hardly any effort put into normalizing the format to solve any of the obvious problems, plus a whole *new* set of problems from the rush-job XML translation.

The point is that the complete read-write implementation of OOXML, interoperable with Office, is clearly impossible in practice without access to the legacy Office codebase, and even a partial implementation is far harder than it has any right to be, proven by the example of ODF which is demonstrably easier. In fact, a partial implementation may not even be realistically possible because of all the interdependencies which ODF has fewer of. What is a standard if it is not interoperable; not implementable? What's the point of making it a standard if it's not going to be fully implemented by anyone but Microsoft?

Re:Try #2

[RzUpAnmsCwrds]

Why should we be interested in furthering the goals of a convicted monopolist?

Oh, I am so sick and fucking tired of hearing this. Should we not buy Intel products because they are a convicted monopolist in Japan? Should we never buy anything Samsung because they were convicted of price fixing (along with other major DRAM manufacturers)?

In 2030 we're still going to be hearing this bullshit line of reasoning. Somehow you believe that we should hold Microsoft to a different standard, and this is the justification you use.

The very phrase "convicted monopolist" implies that there's something illegal about having a monopoly.

But, hey, this is Slashdot. Ever since Miguel stopped drinking the Flavor-Aid, he's been pissed on by the community. Miguel has done more to enable FOSS on the desktop than pretty much anyone here. You may not like Mono, but that doesn't mean that it's not a completely legitimate and valuable project.

Personally, I don't generally agree with Miguel's assertion that OOXML is a "superb" standard.

OOXML has a lot of problems, not the least of which is the fact that it was generally designed as a drop-in replacement for Microsoft's old formats. That's understandable, but it also means that the standard is much less clean than something that was designed from the ground-up without any legacy baggage.

But, let's be real. ODF isn't a great standard, either. It's biggest problem is that it is incomplete, but it also suffers from the same problem as OOXML (except that it's designed around OOo rather than Office).

ODF is getting better through things like the OpenFormula specification. But OOXML is getting better too.

There's so much crap around OOXML. Whatever you think about it, it's still a million times better than the undocumented binary formats that it replaced.

Miguel is right about the FUD storm. You people probably hate ReactOS too, just because it dared to admit that maybe Microsoft got something right.

Re:OOXML.

[mgblst]

You suggest that OOXML works great for you, because you already have parts of Microsoft Office emulated in your software. How easy do you think it is to write a OOXML reader or editor from scratch? This seems to be the majority of complaints about Microsofts standard. Surely a standard should describe this process completely.

Re:OOXML.

[ja]

The 1900 leap year bug presented in Lotus123 etc could easily be fixed upon saving the spreadsheet to XML and - if you really feel this is productive - reintroduced when saving back to one of the legacy formats. The argument against this scheme would be that a theoretical spreadsheet which corrects the bug internally would be broken. Thats fine with me, I really do not like the idea of broken spreadsheets being circulated indefinately. Somebody used the wrong tool at the time and will now have to pay up for that. Or stick with the binary format that still works and will keep on doing that.

That Lotus never thought of spreadsheets dealing with dates beyond the nearest economic horizons, need not to be any of our concerns. To the contrary, an ISO standard should instead stick to well known established sane standards. Leap year bugs, Y2K issues and what have you, simply does not meet that specification.

Appeal to secret knowlege

[overshoot]

Well, you ignored the part where I mentioned that this was being taken care of.

1. You mentioned that "things" were being taken care of; you did not (in any of your posts here, and I read them all) specify that the scoping was one of them
2. You're pulling the classical "I have secret knowledge that proves that I'm right" rhetorical trick. Point me to the revised spec and we can talk.
3. You've practically proven, all by yourself, that DIS-29500 isn't at the level of committee draft, much less final ISO submission. One of the basic responsibilities of a technical committee (see, for instance, JEDEC JM-21L) is clearly defining the requirements for conformance and clearing legal rights for those requirements. According to you, that hasn't been done and here we are at the ISO final vote stage. ECMA-376 needs to go back to committee until it's actually ready for prime time.

Now you argue about optional, so let me clarify, I meant OOXML "optional" which has a very precise term in the spec. Since we are talking about OOXML I expected you to be familiar with it, I guess you were not familiar with it, but only with the handful of bullet points circulating the intertubes.

As a standards maven, I've read the controlling portions (I'm not planning to implement it, so any controlling language hidden in footnotes missed me. As they should.) I'll point out that "optional" has a predefined meaning in standards literature, much as "scope," "shall," "may," and other words that are no more subject to local redefinition than any other legal term. Apparently, the drafters of ECMA-376 had never done any standards work before (the "Scope" section alone makes that very clear) and ECMA made no effort to correct even the most basic flaws.

The problems with technical details I'll leave to others.

Again, your "most of that has already been fixed by ECMA" is an indictment, not an excuse.

Arm twisting

[overshoot]

As for the other stuff, I agree it is not nice of them, but am not sure how you could twist their arm to go beyond that.

We never had any problem in other standards bodies (and I've served on several.)

You open every meeting with a statement of the organization's patent policy. You make participation contingent on agreement with the policy, which includes an affirmative obligation to identify any known blocking IP. When a submission comes from a company, you require a binding letter from the company covering all IP they have covering that submission. You do this for every single point in the draft specification. Anything that doesn't get IP clearance doesn't make it into the draft.

Microsoft could have simply issued a blanket IP clearance for ECMA-376 as passed. Any additions after that point might not be covered, but anything sticking to ECMA-376 as submitted would have been. That's a very common industry practice; in a normal standards body that would have been required. They didn't. Now, I'm a believer in the law of intended consequences, which is similar to "intention" in common law: when a rational party goes out of their way to do something that has predictable consequences, it's reasonable to conclude that they intended those consequences.

Microsoft (and Microsoft Legal) isn't run by idiots. Logic follows.

Re:Always been a MS Shill

[uradu]

> All that aside, OOXML may not be a horrible standard.

Perhaps, as it currently stands. The problem with buying into any MS "standards" is that they morph over time to suit their requirements, while either not including the new bits into the open standard, or publishing them much later to give themselves a head start on using the new features. That way all other users of the "standard" will forever play feature catch-up.

In concrete terms, while it may appear that they currently exhaustively expose all object model entities in the file format spec, nothing prevents them from adding extensions along the line of base64-encoded-and-encrypted-data-storing-juicy-new-Word-functionality-that-nobody-else-can-read. A fat lot of good that does you.

Re:OOXML.

[F-3582]

Am aware of those, they are minor issues. I feel they are worthless, but whatever.

These issues are the center almost any criticism of OOXML has been revolving around, yet! You cannot call them "minor issues" at all!

As many people here and on many other sites have already pointed out, these "backwards compatibility" measures are impossible to implement for anyone except MSFT and those who were able to see the actual code under some chain-linked NDA.

Let's say, OOXML gets implemented as a standard and every word-processing application implements it, what keeps MSFT from just applying a little patch to MS Office to make heavy use of these backwards compat tags? Since the majority of users are still using MS Office this would have dramatic consequences for those who don't

If, say, in fifty years Linux has taken over the world, MSFT is in smithereens because someone decided to revise the antitrust case and MS Office is out of use for several years, nobody will be able to read those OOXML documents anymore, unless MSFT releases the complete specifications.

Therefore OOXML shouldn't be accepted as an ISO standard, because it can only be implemented completely by one party. You shouldn't even call it standard, if it can't be ensured that future generations will be able to read those documents without having to find an x86 Windows PC with MS Office installed!



On a side-note: If MSFT had really really been interested in providing backwards compatibility, they would have just written an application/Office plugin that converted old documents into OOXML without having to use some obfuscated tags. Instead they just squeezed these formatting instructions into their new standard to ensure a steady flow of money from people forced to use MS Office in order to view their documents.

Re:no way it's really him

[pablochacin]

>Well, maybe that is because you know him?

No, I didn't say he were my friend. I said I knew him in person (some improvements needed in your reading skills, I think). And from knowing him and what he pretends from the mono project I couldn't say he is a microsoft fanboy

>Well, he is trying to lure people into using more all-Microsoft technologies, just waiting for the patent trap to close.

Actually, he intends to liberate all those thousands of microsoft based applications and take them to linux. I found this particularly important because many linux fanboys forgot that there are many, many (I mean, MANY) home made business applications (most of them made using microsoft tools) that are a big obstacle when considering the migration to linux desktops. I know this well because I was part of some big studies for massive migrations to linux desktops

>This OOXML-preaching is the best evidence there is.

Did you read it? I've found over the last five years that most linux and open source fanboys tend to over-react to the headlines BEFORE even reading anything. And, actually, one interesting think about any conspiracy theory is that ANY counter argument is actually turned upside down to fit (and actually confirm) the theory.

In any case, life continues. Criticisms will continue but hopefully, Mono project will continue and will bring an important tool to the OPEN SOURCE world and, most important, will bring MILLIONS of business application programmers to linux. Time will tell.

Re:Always been a MS Shill

[UnknowingFool]

All that aside, OOXML may not be a horrible standard.

In theory, OOXML is not a bad standard. In implementation, MS has chosen to tie OOXML to Microsoft products as close as possible. Two major criticism brought out by those who have reviewed it are that (in a standard) OOXML must replicate MS idiosyncracies to work (Spreadsheets must replicate an MS Excel date bug for dates function to work properly), and MS has chosen to write subcomponents from scratch using MS technologies instead of already accepted standards (relying on MS Math standards instead of Math XML).

Re:Gnumeric dev says OOXML easier than ODF

[makomk]

I suspect that the Gnumeric chart model was based on the Excel one, and this is why it fits well with the OOXML one. Of course, this is just from my memories of using it, the fact that it was written by Miguel de Icaza, and that the Wikipedia article says it "broadly and openly emulates" Excel.