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

Good morning, people.

[Anonymous Coward]

The developers had a conference on the Brain Slug Planet. Miguel liked it so much he decided to stay of his own free will.

Re:Good morning, people.

[nexus_VI]

Miguel's blog is brought to you by THE HYPNOTOAD.

Sounds like he's sold out

[Anonymous Coward]

I wonder how much Microsoft paid Miguel to say this.

Re:Sounds like he's sold out

[SerpentMage]

If you are going to slander, then be accurate. Microsoft offered him a job, but Miguel turned it down! I know, I know the people who tried to get him.

I used to be very skeptical of Miguel, but I am tempted to believe he has it right...

First things first.

[khasim]

Can it be verified that it really was him posting that?

Re:First things first.

[nuzak]

It's his own blog.

Re:First things first.

[DrSkwid]

Why? It's hardly out of character. I'd want more proof of attribution if he was scathing.

ROXXXX-annne

[Anonymous Coward]

You don't have to put on that Silverlight...

Re:ROXXXX-annne

[alx5000]

My name is Iñigo de Icaza. You bashed my mono. Prepare to die.

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.

Re:Is Miguel speaking as a Microsoft officer?

[raddan]

It should be added that de Icaza is a Novell VP. So in light of the Microsoft/Novell patent agreement, I think we should all take his opinions with a dose of skepticism. That's not to disparage in any way his work in Free software, of which there are many and great, and I thank him for this. But that does not exonerate him from future badness and/or idiocy.

Re:Is Miguel speaking as a Microsoft officer?

[hdon]

Matusow continued, "To do this, Novell and Microsoft are providing covenants to each other's customers, therefore releasing each company from the other's patent portfolio. This may sounds odd vs. a traditional patent cross-license agreement but it is one of the things that makes this deal so unique."

http://www.linux-watch.com/news/NS2927608517.html

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.

Re:Riiiiiiiiight....

[Shados]

Well, when it comes to .NET, there is a crap ton of copyrighted and patented stuff, and Mono breaks a lot of em, and they know it. They just know Microsoft won't do anything, since they are semi-partners and all.

C# the language is an ECMA standard (I beleive?), but from VB.NET to just about anything in .NET beyond console applications, everything is patented, copyrighted, etc (well, anything that could be), and MONO uses tons of it. No need to list em (in opposition to Windows vs Linux kernel, where its far from being as obvious).

Now, if those patents and other intellectual property crap would stand up in court, thats another story altogether, but unlike the Windows vs Linux patent thing, these are much harder to deny.

(note that the above doesn't change that telling people to get it from Novell is indeed FUD because no one will ever get sued for using Moonlight from someone else's than Novell. I'm just stating how this situation is different from the mostly baseless "Linux is stepping on X amount of our patents" deal)

Re:Riiiiiiiiight....

[smilindog2000]

Actually, having read the 6,000 page standards document, I have to admit it's well designed has has excellent.... ha ha ha ha ha ha!!!! Ok, I couldn't say that with a straight face.

Re:Riiiiiiiiight....

[kaffiene]

ECMA standards are meaningless. They'll "standardise" whatever they're paid to, and the "standards" are allowed to be patent-encumbered. It's madness calling anything they touch a "standard".

He's right...

[SkunkPussy]

...the standard is superb - superbly arrogant!

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

[un1xl0ser]

The fact that Microsoft has their legacy blobs all over the OOXML that they write is exactly why I don't like it. They don't seem to want to implement it in an open fashion. They just want to fein like they are being open so that all of the goverment agencies and corporations that are concerned about vendor lock-in are given a warm fuzzy feeling.

So yeah, the standard is shit. Nobody can implement it the way that the creator can, by the creator's very design. It is defective by design, as the nutty FSF people like to say.

Re:Nope

[Anonymous Coward]

I've developed in both formats, and ODF uses consistent naming conventions and builds upon existing standards whereas OOXML is exceedingly inconsistent (google: "sz" node) and it comes with a lot of new standards.

The implications of this are that OOXML is considerably more expensive to implement because there aren't a lot of components to choose from (eg, compare the number of SVG serializers to DrawingML serializers). Building upon existing standards is a very important part of a good standard, I think (and so do the ISO)

Don't take my word for it though, both files are ZIPs of XML* so google for some files and see which one makes sense to you :)

[*] although it's recently been discovered that OOXML refers to OLE objects which are undocumented in OOXML and in Office '07 these are stored as binaries :( ODF and OOo have their own problems of course, but nothing complex like this.

Re:Nope

[RobertLTux]

okay so try this one create a document in MSO2007 and save it to OOXML
then open a copy of Open Office 2.2* and create the same document

then give me stats on
1 file sizes both bundle size and unzipped tree size
2 actual readability of the payload file

and as a bonus in the OOXML file try to find "legacy tags" only the program importing a legacy file should give a [redacted] about how a legacy file is hacked

Re:Nope

[miguel]

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.

I think we have all heard about this one, and the ECMA guys already know that they have to provide more information about this. 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).

Miguel

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

[ShieldWolf]

What if AbiWord or OOo implements the standard except for these tags and then they receive a file with such a tag populated?

Do you ignore it or do you blow up?

If you ignore it does that mean the file will look different?

Can MS say they are more compatible to customers because they are the only ones that implement the whole standard?

Is there anything stopping them from populating such flags when saving in Office 2017 and thus rendering a bunch of other apps useless, or weird looking (which for business users is the same thing)?

Re:Nope

[Yaztromo]

(it is an optional tag that can be ignored).

Not if Microsoft keeps using it you can't.

Sure, you can ignore it if it comes up in a document, but if a user with little care or knowledge about such issues loads a document up that uses such a tag in (for example) OOo and their table doesn't look like it did in Word, they're probably going to think that OOo is at fault, and may make a decision to not use the alternative software in the future (or may go around telling everyone they know that said software sucks).

If Microsoft, the developer of the main product which generates these data files continues to use these tags, they become impossible to ignore without introducing rendering issues which will be sufficient to annoy potential users of alternative software.

Yes, purportedly these tags are only supposed to be used by Microsoft when converting documents in older Word formats -- but how many hundreds of millions of such documents exist out there? Quite a few, which seems to guarantee that these "ignorable" tags are going to occur quite frequently, and will impose sufficient differences on document rendering if they are ignored. So unless these optional tags are fully documented, why should anyone outside of Microsoft want to adopt this standard?

Standards aren't often perfect the first time around, but someone at Microsoft should have realized this, and should have prevented themselves from trying to fast-track this standard. The biggest problem is that there is the appearance that Microsoft was trying to pull a fast-one on the international standardization community with an incomplete, and highly imperfect standard that they wanted to rush to fruition for purely competitive (and not technical) reasons. With time and revision, OOXML may indeed be a fine standard, but as it stood at the point where they tried to ram it through the ISO, it had (and has) serious flaws.

In one of your other posts to this thread, you mention:

Am personally proud that Jody and Michael made Microsoft add ~650 pages or so to the spec that documented the formulas (one of the things we struggled a lot with in the Gnumeric days).

Here you admit that you've already seen first hand how incomplete standards can affect Open Source (and really any third-party) development. You had a problem with the lack of documentation, and pressured MS for more details to get your software working correctly. So why is it that you have an issue when others want to pressure MS into either rectifying other areas lacking proper documentation, or removing them from the standard altogether, in areas that matter to them?

Yaz.

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

[miguel]

(it is an optional tag that can be ignored).

Not if Microsoft keeps using it you can't.

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.

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.

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.

Miguel

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

[hasbeard]

Hi, This is not Miguel whom you talking to. This is a troll account. The real Miguel's account has a low ID number (7116).

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

[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.

There is good in him!

[Andrei D]

-But, why must you confront him?
-Because, there is good in him. I've felt it. He won't turn us over to the Emperor. I can save him. I can turn him back to the good side. I have to try.

any futher code

[Adult film producer]

that miguel releases under a true oss licence should be treated with extreme caution and prejudice. Who knows where this guys eyes have been. All of his code is tainted as far as I'm concerned, unfortunately any Novell contributer should be treated in the same light as well. This SOB is on the microsoft payroll and it will come back to haunt the oss community in a few years.

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.

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.

Miguel!

[jawtheshark]

You have now officially jumped the shark!

You're technically competent, so what part of "AlignLikeMicrosoftWord98ForMac" is a good standard, eh? How much did you cost? I'd really like to know, I need a stripper for the bacherlor party of a gay mate of me...

Is there an opposite to FUD?

[gilesjuk]

Maybe the opposite is Uninformed Praise and Optimism (UPO).

It seems he hasn't read about how you can "look but not touch" when it comes to the internal data. An expert in the Office format recently proved you could modify the xml in the new Office formats but Office would complain and not load it.

The fact that it's XML seems to only benefit the world in one way, it compresses nicer.

Re:Is there an opposite to FUD?

[makomk]

"Doctor it hurt when I do that..." is a perfectly valid argument - if "that" is defined as "attempt to modify a cell in a spreadsheet without going through the entire thing searching for other cells that reuse the formula in it, parsing the formula and inserting modified versions with cell references offset by the correct amount into them, then locating and deleting the file containing the calculation chain and all references to it".

Also, your rebuttal isn't great. True, the "exploding spreadsheet" was exaggerated, and the second one is slightly silly in some ways. You've completely misrepresented 3), the optimisation artifacts, though. As far as I can tell, his argument is that Excel's shared formulas make it unnecessarily hard to update cells reliably, and he has a point. The references to the old binary format are to demonstrate why in some ways it's actually easier to update.

(Specifically, changing a cell affected by this issue now requires a full scan through the document - without this, you can't even tell if the cell is affected by the issue - and the ability to parse formulae and modify the cell references in them by an offset. With the old binary format, all the cells were references to a shared formula, so it was easy to tell if a cell was affected and easy to update it - or at least, no harder than with a normal cell.)

For (4), the problem with VML is that it's patented, probably not covered by any patent pledge Microsoft has given (since it's optional), and apparently not sufficiently specified. While the specification doesn't claim it's no longer in use, since it's depreciated and intended for backwards compatibility, why is Office 2007 still using it in new documents?

With (6), the problem is twofold - firstly, Microsoft did things like localise all the function names in Office, but the localised function names aren't specified, so anyone working with SpreadsheetML documents in a non-English locale will run into problems figuring out what formula to use if they attempt to switch from Office. The second is that Microsoft uses localised strings to specify certain formatting.

You're totally missing the point of 7. The point isn't that there are several things that affect cell formatting. The point is the lack of consistency between them in terms of how the formatting is specified. In particular, note how they use different ways of specifying font, color, etc... (It's not the only issue of this sort - according to the Grokdoc page, it uses a wide variety of size measurements and the same element can have different units depending on where it is (or in one case, on the border type), often for no good reason.)

Etc, etc...

Re:Miguel's just doing what's best for himself...

[lotsofsand]

I even heard a rumor that Miguel has a brown Zune!

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?

Always been a MS Shill

[plasticsquirrel]

I wonder how much Microsoft paid Miguel to say this.

You're obviously new here. He's been praising Microsoft for years, every chance he gets. Pretty sad, really.

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!

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:Always been a MS Shill

[mabhatter654]

not really, he could be spending that time moving things ahead. The technical decisions are almost worthwhile, but their entirely trying to copy microsoft. They're not Apple and Miguel isn't jobs. At best Bill Gates has maybe heard of him. Miguel is just a business wananabe, while it would be nice to get even 1% of Microsoft's yearly take, it won't happen. In the case of standards like .Net or Office he'll never get there, hell Apple has a lawsuit-provoked open license to M$ patent list and they still only get 95% compatibility. Open Source at this point is "with us or against us". Even Apple with use of BSD doesn't get it and open up to formats like Vorbis, Theora or ODF.. when they are under the same open license they use for their main OS!

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.

Re:Always been a MS Shill

[g4b]

What's Gnome?

I thought with Qt going into GPL Gnome reached version 3 and isnt able to login anymore, because the user dont has to anymore? I thought Gtk vs. Qt is over... and we all know what won?

From all the stuff Miguel made, Mono is the only one I really appreciate however. We have to face it: we need ppl implementing MS stuff, or we can't implement all those funny tags in OOXML

Re:Always been a MS Shill

[aichpvee]

Quick, someone go tell miguel! Microsoft just released Microsoft Jumping Off a Bridge 1.0! He'd better go copy it before they get too big of a head start.

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: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:Always been a MS Shill

[Anonymous Coward]

What?

Re:Always been a MS Shill

[dfsmith]

...will embody a set of defacto addenda to the standard, and no one will Did anyone else read that as "de-fecto addenda to the standard"?

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: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).

Read his latest comment . . .

[Anonymous Coward]

. . . here before starting a flamefest.

I'll paste it here to make sure those averse to clicking on links can read it too (anonymously even so you don't say I'm karma whoring):

Hello,

On 9/10/07, martin.schlan...@gmail.com wrote:

> On 6 Sep., 07:37, "Miguel de Icaza" wrote:
> > 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. This is at a time when
> > OOXML as a spec is in much better shape than any other spec on that
> > space.

> Michael Meeks didn't seem to think so at FOSDEM 2007.

That is odd. Michael and I have discussed this topic extensively. He certainly would like clarification in various areas and more details in some. But Michael's criticism (or for that matter, the Novell OpenOffice team working with that spec) seems to be incredibly different than the laundry list of issues that pass as technical reviews in sites like Groklaw.

The difference is that the Novell-based criticism is based on actually trying to implement the spec. Not reading the spec for the sake of finding holes that can be used in a political battle.

Finally, Michael sounded incredibly positive after the ECMA meeting last month when all of their technical questions were either answered or added to the batch of things to review. I know you are going to say "The spec is not owned by ECMA", well, currently the working group that will review the ISO comments is at ECMA.

For another view at OOXML look at what Jody Goldberg (no longer a Novell employee) has to say about OOXML and ODF from the perspective of implementing both:

http://blogs.gnome.org/jody/2007/09/10/odf-vs-oox-asking-the-wrong-questions/

I find it hilarious that the majority (not all) of the criticism for OOXML comes from people that do not have to write any code that interacts with OOXML. Those that know do not seem to mind (except those whose personal business is at risk because Microsoft moved away from a binary format to an
XML format, which I also find hilarious).

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

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

> You're saying two things here that really shock me. Please tell me I
> misunderstood.

1) You're saying that people _will_ have patent problems - i.e.

> Moonlight "infringes" MS patents and doesn't work around them. Even
> though Novell promised never to ship code that infringes MS patents -
> but always avoid them one way or another.

First of all, am not aware of such Novell promise to "never ship code that infringes MS patents". You can not make such statement because for one, the patent system is broken. Novell statements are wildly different, they are of the form "we do not believe that we infringe" and am sure they say something along the lines of "we dont plan on infringing, and we plan on removing infringing code". But I am not aware of all the promises Novell has made, and I can not comment on other parts of the organization. If you want an official answer, my personal blog on politics and poor attempts at humor is not the place to get an official answer. Contact Novell public relations for that.

But you might be referring to the policy that we use for Mono, and I will be happy to discuss those with you. The policies are on our FAQ, so you might want to read that before you post in panic again.

Moonlight does not have the same policy that Mono does in terms of us working around to remove infringing c

Re:Read his latest comment . . .

[Anonymous Coward]

Hi Miguel,
yes, lets all talk AC, it makes our conversation so much more unclear...

I find it hilarious that all the positive remarks on OOXML come from people who are employed by, or have business relations with Microsoft. I think this more than justifies most people's suspicion of Novel, and now you personally. Things are usually not black/white. Microsoft are not the Borg, Iran is not the source of all evil, and even terrorists love their children.

However, that does not mean it is not worth fighting against it. Novel, and you, choose to support technologies of a company with a long history of playing dirty. I am sorry but I think that is just a bad idea. Especially when alternatives exist. There is no reason (yet) to go implement this format. It will give excuses for people to use it, and there is a chance that MS at some point turns on alternative implementations. So why do it? If OOXML gets widely used at some point in the future, then people can think about implementing it. I rather fight for preventing that from happening.

I guess Novel at least things to get some money out of it. Well, that's nice, but that automatically will let them (and you) lose respect in the OSS community. So do not be so surprised at the post here. Some people will consider you morally corrupt, and you lose standing as a developer in their eyes. Others will think, perhaps rightfully, you blindly walked into a trap, and are being fooled by MS.

You misunderstand what is "asking the right questions". It is not about technology. Until everybody and his mom is on OSS, it is also about ideology. And many people believe it is just a bad choice to go with something "tainted" like OOXML. You can not win such argument on technical merits alone. Especially if there are many problems with the proposed standard, and if there is an approved alternative...

Also, as others have commented. You are not doing yourself a favor making comments as:
"but you are going to need some legal training and get a lot more depth before we can have a productive discussion."

It looks arrogant, and insulting.

Re:Read his latest comment . . .

[codemachine]

His bringing up the example of XLSX being easier for Gnumeric to implement than ODF spreadsheets is bizarre. The author of that post said that XLSX was easier because it shared much of the same code and concepts of the already reverse engineered XLS format. But if he didn't already support the legacy format, wouldn't it be expected that XLSX would be just as difficult to write an import filter for as ODF?

Perhaps this is not true for spreadsheets though. It seems that open source support for most of XLS is excellent. It could very well be a different story for DOCX vs ODF text documents. Word processing is generally where the most attention gets paid.

Re:Miguel's just doing what's best for himself...

[Duhavid]

Everyone has brown zune, unless they are having intestinal difficulties.

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

It's a wonderful spec

[overshoot]

Well, I suppose there's room for opinion on that. For instance, Jim Mason seems to think it's a long way from prime time, just as a specification.

Now, to put this in perspective: Jim Mason (of Oak Ridge National Laboratory) isn't on one side or the other, but has been doing document-format specifications for a looooong time -- he was, I believe, the founding chair of SC34 and had a hand in the creation of SGML. The dude knows documents, he knows standards, and when he writes

the submitters obviously did not read -- and edit -- this submission into a consistent whole. If it were coming through the normal ISO process, I'd say it was in the state of a Working Draft and not yet ready for registration as a Committee Draft and assignment of a number

I'm inclined to take his word for it than Miguel's.

This is just getting downright indecent.

[bersl2]

Some reasons why OOXML is unacceptable:

OOXML is wholly un-XML-ish.

It doesn't re-use existing ISO and W3C standards, whose behaviors have already been publicly vetted.

Its licensing is still quite unacceptable, especially in its lack of clarity.

Look, Miguel, I know you love MS and all, and I guess I can at least partially tolerate that, but keep the fellatio behind closed doors, OK? :P

deficiency

[Joce640k]

"it could be argued that's a deficiency in the Office implementation of the format, not the format itself."

Doesn't matter. MS will be viewed as the "standard" and if a file won't load then the file will be blamed, not Microsoft.

The whole point of XML is to be human readable and editable with a simple text editor. It seems that if you try to edit Excel worksheets by hand then Excel will refuse to load them.

The link:

http://ooxmlisdefectivebydesign.blogspot.com/2007/08/microsoft-office-xml-formats-defective.html

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?

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:

[holloway]

"objectively horrible" eh? ;)

Well, how about the propagation of historical bugs?

Within OOXML they have ways of dealing with some historical bugs (eg, autoSpaceLikeWord95). When a future revision of OOXML defines what autoSpaceLikeWord95 means then OOXML implementors will be able to distinguish bugs from how it should be.

However this technique is used selectively within OOXML, for example take the 1900 leap year bug, or the 35+ bugs in spreadsheet formulas.

ODF 1.2 with OpenFormula has an approach of adding additional flags to be compatible with historical bugs while preventing bug propagation in future documents. See this blog post for more

Microsoft have stated that the 1900 bug in Microsoft Excel was done to emulate a bug in Lotus 123. Correct blame is good, but we should still squash this bug now.

There's no technical reason for propagating this bug, and we should not allow this in an ISO standard.

Re:That statement proves it:

[holloway]

Ah, yes I was a bit unclear. My point was that there's no technical reason for propagating this bug into new documents. It's good to preserve expected but buggy behaviour in old documents (as OpenFormula does, and OOXML will presumably do when those flags are defined).

It would be great if ODF could benefit from this too and -- as you say -- keeping quirks in a separate XML namespace would help this.

This is starting to sound like the French and New Zealand opinion of harmonizing the two formats (which even Microsoft developers have told me is quite possible, see my meeting notes from Standards New Zealand.

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:

[gnasher719]

Icaza being a Microsoft shill seams to be the only logical explanation.

Nobody who would create an international standard with the intent that it is actually used by the public would have created a standard covering 6,000 pages. That is just ridiculous.

A "superb" standard would build on existing standards, like using standard XML (which is something you would really expect from something called OpenXML). It wouldn't introduce bugs in its date handling because some application (Excel) not using that standard has the bugs. If you read the comments from the British committee examining that "standard", it is completely riddled with errors big and small.

Now I wouldn't want to decide whether the problems come from some Microsoft evilness, or from this being a complete rush job (if you compare this to how long development of the C standard or C++ standard takes, where every single line is examined again or again), but this "standard" should never, ever have been put on the ISO fast track. Maybe in a few years time, if Microsoft has had time to fix all the problems.

For those who don't know: Usually introducing an ISO standard is a multi-stage process. The standard is suggested, then comments are collected, problems are fixed, again and again, until eventually the whole thing has the quality and the consensus that is required for an international standard and then it goes to the vote. This proposal has gone on the fast track, which should have been reserved for standards that have passed all the early stages. Like if there had been an industry wide consensus where everyone followed the same document, and then someone has the idea to turn this wide consensus into an official standard. It shouldn't be used for something thrown together quickly.

No, I don't think that Icaza could call this a "superb" standard unless he was paid to do it. Not that I blame him; I would do the same thing if you gave me enough money. This post here is my unpaid-for opinion, I'll write another one if anyone comes up with say a five digit number.

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.

OOXML.

[miguel]

Folks,

I made that comment on my blog because that reflects my personal opinion. You really need to obsess over something else.

And before someone brings up the Microsoft connection, you should know that Novell official policy is to actively endorse ODF and that Novell's position on OOXML is neutral. My employer does not engage in any advocacy for or against OOXML (but folks in engineering work on OOXML support for OO.org).

My opinions are my own, they do not represents the views of my employer.

Now, speaking purely personally.

I consider OOXML to be a pretty good standard all things considered, as I said back in January or February I did not agree with a lot of the criticism that was aimed at OOXML. The quality of the critique was not very high, and it so far has consisted of throwing as much mud as possible and waiting to see what sticks, and what sticks repeat it a thousand times.

If these critiques were aimed at Linux or open source, we would be justly up in arms about the criticism being sloppy and having very little to stand on. I went into some detail back in January:

http://tirania.org/blog/archive/2007/Jan-30.html

Some of my opinions are based on the work that I did in Gnumeric many years ago.

Before there was any agreements between Microsoft and Novell, I was part of ECMA and when Microsoft initiated the OOXML specification process, it was me that got Novell's OpenOffice.org hackers to attend the meetings. At the time my goal was to extract as much information as possible from Microsoft because of the history we had with Gnumeric.

Michael Meeks and Jody Goldberg were some of the guys that went and attended the ECMA meetings. From all the issues that were presented to ECMA, Novell was the second issue raiser (behind Microsoft's own QA of the spec), and it was all largely thanks to Jody's diligent review of the spec. From all the issues raised to date, on the latest status report only one issue had not been addressed (118 or 180, I can not recall anymore). Am personally proud that Jody and Michael made Microsoft add ~650 pages or so to the spec that documented the formulas (one of the things we struggled a lot with in the Gnumeric days). And all of this happened before the Novell/Microsoft agreement. Our interest at the time was: lets get the most information we can get out of this spec to be able to interop.

So from that standpoint, I think that the folks at ECMA have done a pretty good job of addressing the issues raised by those that were implementing it.

The specification can be criticized on various levels, from critical issues, to mild issues, and in a way the distributed effort to stop OOXML helped debug the spec and raise the issues that need to be clarified.

There is certainly a number of critical issues that must be addressed, and it seems from every comment that Brian makes on his blog, that ECMA and Microsoft are committed to resolving those issues. I would not have noticed them, so in that regard the anti-OOXML camp has done a great job in terms of finding problems in the spec.

But the majority of the criticism falls in other categories:

mild, but conflated by a pedantic outrage over it ranging from 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)

misinformed (Stephane Rodriguez shotting himself in the foot and asking "why does it bleed?", his document is making the rounds, and I have debunked it here: http://developers.slashdot.org/comments.pl?sid=279895&cid=20363627 and someone else on CodeProject or in Slashdot had to explain to him with sticks and balls his mistakes).

misrepresentation, like people claim that you must obtain a license from Microsoft to implement OOXML, that is simply not

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.

Re:OOXML.

[AKAImBatman]

Jody left Novell some time ago, and today coincidentally he blogged about his opinion on OOXML and ODF, his blog post is very interesting, as he is an independent developer working now only on gnumeric and not in OOo nor being paid by Microsoft (as I know that many of you consider my opinion completely invalid and tainted):

http://blogs.gnome.org/jody/2007/09/10/odf-vs-oox-asking-the-wrong-questions/

Yes, very interesting. Jody says: "I did not comment on the quality of the formats. That will come up later."

What did Jody actually say? That OOXML was easier to support because Gnumeric already supported the XLS format. Which does nothing to address the relative merits of having a format like OOXML standardized under the terms with which Microsoft wishes to standardize it.

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.)

I just do not have the energy or the time to compete with a guy whose full time job is to make sure OOXML is blocked.

That's right. It's Microsoft's job to pay off officials, exert political pressure, and abuse due process to ensure that OOXML is forced into consumer hands before ODF catches hold.

People claimed that 6,000 pages for 4 office applications was to big, but it comes down to 1,500 pages per application. And someone mentioned that removing the examples and changing the font size to use the same font size that the ODF spec uses the spreadsheet (or word processor, I cant remember) spec goes down to 700 pages.

A disingenuous argument at best. The ODF format supports those same four applications, plus a bit more. 1,500 per application is huge in comparison. Even if we assume that it's 700 per application, it's STILL huge when compared to 867 for ALL applications.

That being said, I don't mind long specifications if they are long for a good reason. Being long because ancient cruft is being supported for no real reason is not a "good" reason at all.

ODF is predicated on the ideals of KISS, interoperability, and long-term data storage and retrieval. OOXML is predicated on the concept of converting Microsoft formats to an XML description. While the latter may be a nice goal for Microsoft, it does not conform the the former ideals required for an international standardization effort.

I'm sorry Miguel. I've disagreed with you in the past, but I can't even begin to fathom your position in this matter.

Re:OOXML.

[miguel]

I'm sorry, but you can't dismiss all criticism of OOXML as pedants/FUD/misinformed and your post above attacks the messenger a lot more than the message. How about you comment on well formulated objections such as this one on grokdoc? Some are very specific (narrow) technical aspects , while others are much more fundamental, like:

I did not dismiss all criticism, I believe that there is some valid criticism to OOXML, but the majority is not. In particular the criticism from Groklaw is partisan, a guy on Brian Jones' blog tried to correct various statements made on the Groklaw document and he claims that his account was removed. I have no way to verify that, but my experience with that doc is that it most of the criticism there is mostly non-relevant.

- Contradicts numerous international standards

Am not sure that it "contradicts" it just does not support every other possible standard. It has its own thing for Math instead of MathML, big deal.

- Relies on undisclosed information (e.g. application-defined behaviors)

So does ODF (if you are referring to the capability of embedding OLE objects for example, or Windows Metafiles, they are supported in both products, and neither one has full specifications for them).

Not to mention the obvious "why do we need a second standard in the first place?", since ODF is already an ISO standard (too many standards is like no standard at all).

Well, that is a strategic discussion, not really something related to the quality of the standard.

ODF is a standard because it was rushed through and its missing fundamental pieces like a formula specification (yes, I know, they are working on one, no need to give me the link again). But as it stands today ODF is missing those bits.

Had the same level of scrutiny and criticism been applied to ODF than is being applied to OOXML there would be no ISO standard today (google for ODF criticism on the formula issue, you will find the who-is-who of XML criticizing the decision to ship formula less at the time).

I will agree with you that having two is suboptimal, but we have to support them both *anyways*, so its not like its a big deal.

Miguel.

Re:OOXML.

[suv4x4]

So there you have it, a mouthful of personal opinions. I bet you wanted to spend your time doing something else, like making out with your girlfriend (haha, just kidding, if you actually reading my opinion on OOXML you have no girlfriend to make out with).

Ladies and gentlemen, the Novell Vice President...

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:OOXML.

[jmv]

In particular the criticism from Groklaw is partisan, a guy on Brian Jones' blog tried to correct various statements made on the Groklaw document and he claims that his account was removed.

Partisan or now, most of what I saw there was looked like real problems.

Am not sure that it "contradicts" it just does not support every other possible standard. It has its own thing for Math instead of MathML, big deal.

Well (from the document again), they use incorrect dates (the 1900 stuff) just to be compatible with "legacy software" and completely ignore SVG, MathML and other stuff. I mean, what's the point of having standards for that if every new thing ignores it.

So does ODF (if you are referring to the capability of embedding OLE objects for example, or Windows Metafiles, they are supported in both products, and neither one has full specifications for them).

I'm not sure about what ODF does, but in the worst case, if something's application-specific in ODF, you look it up in the OO.o source code and you can at least have a chance to understand how it's done. For things that are application-specific in OOXML, you're pretty much have to wait until Microsoft open's up the Office source code (I'm sure that'll happen any day now).

I will agree with you that having two is suboptimal, but we have to support them both *anyways*, so its not like its a big deal.

Can you remind me what is the point of standards bodies again? Rubber-stamping any de facto standard because "we have to support it anyways"? I don't think so.

Re:OOXML.

[miguel]

Hello,

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.

The issue has to do with the way spreadsheets have historically represented dates. They do not represent dates in a special format, but instead as a floating point which can be interpreted by a special format. So "N.M" becomes day N hour M (where M is some fraction of the day, I cant remember now exactly the mapping).

The problem is that people do date computations and math computations based on the floating point values in the cells (the way you find the difference between two dates is very simple: substract the floating point numbers).
So cells would contain values like "10312" and an external format that says "render the value as a date with this format". Formats are combined with a region-based mechanism which I wont go into.

Now if you have ever debugged spreadsheets or worked with finance people that use spreadsheets extensively you will know that these people did not read "Design Patterns" and Knuth before writing their stuff. They are not exactly PhDs in computer science.

The date mistake comes from Lotus 1-2-3 (and possibly earlier, but at least the problem was present here) and has been with us ever since. Now, the reality is that there is a gap of four years (or something like that, again, I do not remember the details) in 1900 where the values are incorrect because of this mistake in Lotus 1-2-3. The problem is that all dates have been stored as numbers. So you certainly could decide to "fix" the problem to be correct, but then you would have to upgrade *and* debug all spreadsheets out there that do date computations. Now most date computations might be fine (because most people would do date-to-date computations) but the cases where people mixed date computations with *other* data would be affected. How badly? Well, there is no easy way of telling.

Now, if you have debugged a spreadsheet (I have, I debugged a lot of spreadsheets in my Gnumeric days) nasty spreadsheets are not easy to debug. They are fairly complicated beasts and am not sure that *anyone* that has existing models would have to debug these problems (the amount of people using Excel as a financial planning tool are way larger than you can imagine).

Now, you might say "ODF deals with this". It does, and it does so on an interesting way, a way that requires you to enter the data again. It basically keeps track of the stored value *and* the value actually entered by the user. This works as long as the user enters the data again, but if the user did not enter the data and you just imported, you are in trouble. I tried this some time ago and importing an XLS file into OpenOffice did in fact break the date computation during import and later export.

Now, if I had millions of users using my software, I would not want to impose on them a new semantic on the numbers on the spreadsheets. Imagine the consequences of fixing something like that say in a CPU: changing the semantics of something that even if broken was known and worked around already (yes, you could say, "fix the software", but that is easier said than done).

I for one, would prefer to keep compatibility that introduce bugs that will be incredibly hard to spot.

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. It was a pretty good standard (although it avoided solving fundamental problems, I believe partially related to who was on the committee regarding fonts, you might want to google "Raph Levien fonts svg standard") until it became very bloated.

Part of the story involved Adobe trying to add a lot of features to SVG to turn it into something that could compete with Flash, turning SVG into a rather complicated standard to implement. Eventually Adobe would buy Macromedia and they lost interest in extending SVG (an

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.

Re:OOXML.

[rastos1]

Would you mind to share your thoughts on the standardization process too? A very nice article (unfortunately in Czech, but with links) says basically this:

• Portugal - had not committee so they created one just to able to vote on OOXML - chaired by MS guy. IBM and Sun were not allowed to vote.
• Germany - committee chaired by guy from Frauenhoffer institute that has close relations to MS. Google and Deutche Telecom were not allowed to vote.
• Norway - the problems pointed out were dismissed by MS with simple "that's not true!". At the end Norway admitted themselves that the standard is crap.
• Sweden - the committee got 20 new members just before voting. They all voted "yes" because they were bought.
• Czech - 50 companies attempted to influence the voting.
• Poland - committee voted "no". A new committee was created and the vote become "yes".
• Hungary - the 1st and 2nd voting were screwed up (voting rules changed just prior voting, the invitations were sent late) and so Hungary did not vote at all.
• Italy - just before voting the committee was extended from 5 to 83(!)members.

Something smells here. Horribly.

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.

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:OOXML.

[Jeremy Allison - Sam]

No Miguel, it might be ok for a Microsoft standards doc (similar to the CIFS one in that respect, I've had to read both).

But it's a *terribly* written standard if you compare it to things like the IETF standards. Have you ever read other standards work than the ECMA stuff (not trying to be nasty here, just curious) ?

Jeremy.

This is the end of my respect for Miguel

[IWannaBeAnAC]

I have been following the OOXML saga fairly closely; from Rob Weir's blog, to the NO-OOXML site (admitedly that is a rather partisan site, but I've found the technical arguments presented there generally to be both verifiable and compelling), and the Standards Blog, by Andy Updegrove who seems to know his stuff (which is bizarre since he is also a lawyer, but I guess he came from a parallel universe). I've also looked at sections of the spec myself, and I agree with the major technical criticisms; aside from being redundant in that there is already an ISO standard that could -- with well defined extensions -- cover everything Microsoft wants to include (ie, the backwards compatibility stuff), the OOXML document is a poorly worded draft of a 'standard' that is incomplete, inconsistent, and not ready for standardization.

By usual ISO standards (if it hadn't been submitted on the fast-track), it would be at the stage of a 'committee draft', with at least a couple of years of serious effort into working it into something useable. This is the process that ODF, along with most other ISO standards, went though, and if OOXML makes it through without a similar amount of scrutiny, ISO will have egg on their faces.

For Miguel to say it is a 'superb standard' means he either hasn't read it or followed the technical discussions (in which case he deserves the panning he will get for making such a clueless statement), or he really has sold out, in which case he deserves exile.

Even if it *was* a good standard...

[Anonymous Coward]

Even if we thought that it was a good standard--you know, something that would not contain ugly hacks like formatLikeWord95, would not need a major international company to brib^W cajole hundreds of Microsoft Certified Gold Partners to join NB's that are members of the ISO to get it passed--how does all that backwards compatibility hack^W support actually work in practice?

Well, let's take a look at one company's deployment of Office 2007 to 25,000 workstations. Oh, what's that? It's still crap? Figures.

Yes, the information should help people interoperate with Microsoft. But all the parts they're keeping from us are important. They want to control de facto standards and keep all other ISVs at second-tier status without having to make good products.

People would be better off with standards not controlled by any one company. Even if Microsoft were the most benevolent company in the world, there's no excuse for giving another company the power to hold your documents hostage in this day and age. And it's about time that people realized that, especially when Microsoft has intentionally perverted standards like ACPI to harm Linux.

The PDF link above is just for proof. Here's a transcript of the PDF so you don't have to view it unless you don't believe me:

Plaintiff's Exhibit 3020
Comes v. Microsoft

From: Bill Gates
Sent: Sunday, January 24, 1999 8:41 AM
To: Jeff Weslorinen; Ben Falbi
Cc: Carl Stork (Exchange); Nathan Myhrvold; Eric Rudder
Subject: ACPI extensions

One thing I find myself wondering about is whether we shouldn't try to make the "ACPI" extensions somehow Windows specific.

It seems unfortunate if we do this work and get our partners to do the work and the result is that Linux works great without having to do the work.

Maybe there is no way to avoid this problem but it does bother me.

Maybe we could define the APIs so that they work well with NT and not the others even if they are open.

Or maybe we could patent something related to this.

MS-PCA 1389717
HIGHLY CONFIDENTIAL

Gates Deposition Exhibit 32
2/28/02

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.

Re:Novell is distributing concealed patent landmin

[miguel]

Well, you quoted my posts out of context(I provided a *lot* of context).

So it is not surprising that you arrive to the wrong conclusions. I wont repeat it here, all the explanations are in the blog comments.

Miguel.

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 :)

Gnumeric dev says OOXML easier than ODF

[I'm Don Giovanni]

I might get modded down for this, but:

I notice that in the very same Google Groups thread, Miguel makes a post that refers to what Gnumeric dev Jody Goldberg has to say regarding ODF and OOXML.

According to Jody Goldberg's blog entry, implementing the fundamentals of OOXML took only a few days, and that implementing ODF "was significantly more difficult" than implementing OOXML. Jody also says, "ODF's model of 'chartness' didn't fit well with Gnumeric."
Is this not contrary to ODF proponents' claim that ODF is equally suitable for all word processors and spreadsheets to implement? That it doesn't favor any particular spreadsheet implementation (i.e. OO.o) over any other? That it was built from the ground up to be app-neutral, and that this is app-neutrality is a virtue that OOXML lacks (since OOXML of course favors MS Office)? What say you to Jody Goldberg?

Not that Novell or former-Novell employees think that OOXML is perfect. But I think Miguel has it right, for in that same Google Groups post, he writes,

He [Novell's Michael Meeks]
certainly would like clarification in various areas [of OOXML] and more details in
some. But Michael's criticism (or for that matter, the Novell OpenOffice
team working with that spec) seems to be incredibly different than the
laundry list of issues that pass as technical reviews in sites like Groklaw.

The difference is that the Novell-based criticism is based on actually
trying to implement the spec. Not reading the spec for the sake of finding
holes that can be used in a political battle.

Finally, Michael sounded incredibly positive after the ECMA meeting last
month when all of their technical questions were either answered or added to
the batch of things to review. ...

I find it hilarious that the majority (not all) of the criticism for OOXML
comes from people that do not have to write any code that interacts with
OOXML. Those that know do not seem to mind (except those whose personal
business is at risk because Microsoft moved away from a binary format to an
XML format, which I also find hilarious).

(I'm guessing that the latter comment regarding persons whose business is at risk due to MS moving away from binary formats refers to often-quoted OOXML basher Stepen Rodriguez, who has been blasting/FUDing OOXML, but who has a business based on maintaining XL spreadheets in the old binary format.)

Re:Gnumeric dev says OOXML easier than ODF

[tmarthal]

According to Jody Goldberg's blog entry, implementing the fundamentals of OOXML took only a few days, and that implementing ODF "was significantly more difficult" than implementing OOXML. Jody also says, "ODF's model of 'chartness' didn't fit well with Gnumeric."

You have to understand that Gnumeric has already parsed XLS files (MS Excel Spreadsheets), and most likely used some structure associated with that data model internally. So, when they talk about implementing the fundamentals of OOXML, they already had the XLS parser written. Which is why it was easy. Jody didn't talk anything about the extended components or the code completeness of the OOXML spreadsheet/chart spec.

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.

Re:no way it's really him

[miguel]

Actually, I did not give you gconf.

I did not originally like Gconf, but today I think that gconf is pretty cool and I think that there is now an effort to revamp it into something new. I forget its name though, something D-Bus based, I also think that is pretty cool.

Try #2

[AKAImBatman]

(Yes, sorry. I should have used the preview button.)

Jody left Novell some time ago, and today coincidentally he blogged about his opinion on OOXML and ODF, his blog post is very interesting, as he is an independent developer working now only on gnumeric and not in OOo nor being paid by Microsoft (as I know that many of you consider my opinion completely invalid and tainted):

http://blogs.gnome.org/jody/2007/09/10/odf-vs-oox-asking-the-wrong-questions/

Yes, very interesting. Jody says: "I did not comment on the quality of the formats. That will come up later."

What did Jody actually say? That OOXML was easier to support because Gnumeric already supported the XLS format. Which does nothing to address the relative merits of having a format like OOXML standardized under the terms with which Microsoft wishes to standardize it.

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.)

I just do not have the energy or the time to compete with a guy whose full time job is to make sure OOXML is blocked.

That's right. It's Microsoft's job to pay off officials, exert political pressure, and abuse due process to ensure that OOXML is forced into consumer hands before ODF catches hold.

People claimed that 6,000 pages for 4 office applications was to big, but it comes down to 1,500 pages per application. And someone mentioned that removing the examples and changing the font size to use the same font size that the ODF spec uses the spreadsheet (or word processor, I cant remember) spec goes down to 700 pages.

A disingenuous argument at best. The ODF format supports those same four applications, plus a bit more. 1,500 per application is huge in comparison. Even if we assume that it's 700 per application, it's STILL huge when compared to 867 for ALL applications.

That being said, I don't mind long specifications if they are long for a good reason. Being long because ancient cruft is being supported for no real reason is not a "good" reason at all.

ODF is predicated on the ideals of KISS, interoperability, and long-term data storage and retrieval. OOXML is predicated on the concept of converting Microsoft formats to an XML description. While the latter may be a nice goal for Microsoft, it does not conform the the former ideals required for an international standardization effort.

I'm sorry Miguel. I've disagreed with you in the past, but I can't even begin to fathom your position in this matter.

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:Try #2

[LDoggg_]

Come on, that's the only part of his argument you choose to respond to?

Funny that you shy away from: "That's right. It's Microsoft's job to pay off officials, exert political pressure, and abuse due process to ensure that OOXML is forced into consumer hands before ODF catches hold."

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

Re:Try #2

[ardor]

Care to reply to this? http://linux.slashdot.org/comments.pl?sid=293507&cid=20547295

Undocumented OLE blobs do not sound good. Not at all.

Re:Try #2

[AKAImBatman]

The first "fact" the GP references is something he pulled out of his ass,

You assume too much:

http://slashdot.org/comments.pl?sid=293507&cid=20555063

I wish I had the time to sit and correct Miguel on things he should already know, but I'm afraid I have more important work to perform. My post was only to express my disappointment in him, not to get into a pointless argument.

FWIW, I'm shocked that Miguel didn't already know about the VBA issue. It's mentioned right on the NoOOXML page for the Binary Space complaint:

http://www.noooxml.org/binaryspace

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:Novell is distributing concealed patent landmin

[pallmall1]

Well, you quoted my posts out of context(I provided a *lot* of context).

I did provide a link to the blog containing the quoted posts. Perhaps you could explain what I got wrong regarding this:

Moonlight does not have the same policy that Mono does in terms of us working around to remove infringing code. For one, we do not know what it could be (that is how the patent system works) and two we have agreed and have obtained permission from any patents that might exist in Moonlight to implement it.

This policy makes any software released under it a patent trap.

Foes of Miguel de Icaza

[Anonymous Coward]

Foes of Miguel de Icaza:

iso (87585)
java (15428)
KDE (100369)

I'm going to have to say that yes, yes it is. Although it may be somewhat sensationalized, the man DOES own a Zune. I repeat, Miguel de Icaza owns a Zune! If that isn't worthy of a pointless Slashdot flamewar, or at least a paddling, I don't know what is.

Re:Foes of Miguel de Icaza

[Anonymous Coward]

Better check out friends: http://linux.slashdot.org/~Miguel+de+Icaza/friends/

Friends of Miguel de Icaza (660439)

Billly Gates (198444)
Developers! Develope (669541)
LOL PATENTS RULE LOL (903720)
Office Clippy (442751)
Steve Ballmer YEARGH (965544)

We need an intervention.

[seebs]

First it was Gnome, an attempt to build a desktop Just Like Windows.

Then it was Mono. We've had slashdot stories on Miguel's pleas for Microsoft to please not constantly break compatibility to push people towards their implementation.

Now this.

Miguel, we care about you very much, and you need to understand that Microsoft doesn't love you. Microsoft will never feel about you the way you feel about Microsoft. Your pure heart is not enough to suddenly make Microsoft embrace any kind of genuine open standard. Microsoft has never had any goal but the ruthless elimination of any possible competition, and all you're doing is enabling the abuse.

You need to stop, and you need to walk away. You need to get into therapy, and start thinking about what's good for you, and what's good for the people who care about you.

Microsoft will never love you. They will not adopt open standards to make you happy. They will not try to make interoperation with you better. They will occasionally say just enough to string you along and make you write thousands of lines of ugly, bloated, crappy code in servile imitation of their unholy crap, but they will never actually care for you.

It's not gonna happen.

Look, face it: Bill Gates appears to be happily married. It was never meant to be. Just move on, and for the love of God, stop shipping multi-megabyte "frameworks".

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.

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.

Secretly Working Where?

[soloport]

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

Actually, he really did get the gig at MS -- he just told the rest of us otherwise. ;-)

No matter how good it is . . .

[achurch]

OOXML could be the best thing since sliced bread, and I still wouldn't accept it. Not because I hate Microsoft; I most certainly do hate Microsoft, but I also recognize the technical contributions they've made to computing. I'd reject OOXML because Microsoft has ruined its (both OOXML's and Microsoft's own) credibility with its gaming of the standards process.

I'll set aside for the moment the problems I see in the draft as it is. If Microsoft believed its format was good enough to be an international standard--as opposed to simply a de facto "standard"--why did it then try to mislead ISO members around the world with demonstrably false information? Conversely, if Microsoft didn't think its format was good enough to be an international standard, why did it submit the format to ISO in the first place? And what will Microsoft do to make amends for its improper actions? (I'm not asking you for answers to these questions, but I suspect most people in the anti-OOXML camp will want satisfactory answers before they're willing to focus on the merits.)

I'm currently developing a collaboration system for a client which will (among other things) input and output spreadsheets in an XML-based file format. I was considering OOXML for a while, since its technical issues don't impact this particular application; but with the shenanigans Microsoft has pulled to try and force OOXML through ISO, I've settled on ODF. I simply can't support a company which engages in such unethical behavior.

Word doesn't preserve layout either

[MCRocker]

Even MS Word doesn't preserve format from system to system. All you need to do is have a different default printer than the person who sent you the document and it will lay it out differently for you than it did for them. Page boundaries, fonts, pretty much every aspect of the document can change simply by not having the same printer driver they have.

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:no way it's really him

[pablochacin]

> The guy's a complete microsoft fanboy troll who's trying to destroy Linux and Free Software in general.

So, the guy who started Ximian, the company that developed Evolution and main supporter of Gnome, not to mention Mono, one of the best projects for a cross-platform development tools, is trying to DESTROY open source in general . . . wow this is the more interesting conspirancy theory since the X Files show ended!

I know Miguel in person and I don't think he is a Microsoft fan boy. He just is not a fanatical and can acknowledge that Microsoft development tools are far better that any current open source alternative and that's why he is developing Mono, which if you haven't noticed is open source.

By the way, what have YOU done for the open source movement?

Re:Novell is distributing concealed patent landmin

[geschild]

Miguel,

I'm not trolling when I ask you: have you read the OOXML proposal or parts of it?

If you have, do you believe the content is a standard? in the light of the comments from various organizations?

If you have not read the OOXML proposal, on who's authority do you base your positive comments?

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.

Miguel de Icaza, please listen with an open mind

[Tiger Smile]

The argument as to why OOXML are good or bed, vs ODF, aside there is a matter of history to think of. Microsoft can't be 100% evil, it's just hard to hire people like that and expect them to function. So I agree we should not jump on MS for everything. But to be fair they do have a history. I worked at a company that, as a result of taking MS at their word(and poor management, which took MS at their word) they went under. I famous line uttered in the meeting some 8 months before things got bad was "Come on, Microsoft would never screw us!" This was spoken by the person we'd hired from Apple after they downsized, which seemed to have something to do with being screwed by Microsoft.

Microsoft has a motive. That is everything. One motive has been to control file formats, to the end that it makes them money. They are motivated by profit. Microsoft is the smartest company in the world at insuring they make money. They were forced kicking and screaming into supporting HTML, no matter their public face. The last thing they need is for users to have a path to a different set of office applications. Do you really think that all this work on OOXML is intended to lose MS money AND give their office applications the kiss of death? They are smart when it comes to making money and they have a plan to make money from this, or why the big push? Something, sure as hell, stinks. It stinks big time, when they rig the ISO vote.

But if you can see that MS has no grand plan being OOXML to hurt people I would not mind hearing it, but I am never going to think for a second that you have the slightest understanding of the cunning and tactics, nor do I think you can stoop to that level for long enough to think like they do. But give it your best shot and tell me why you think MS would just give the store away?

I reserve the right to be completely wrong.

Legacy Blobs all over the place ??

[Jody Goldberg]

When working on filters for gnumeric my standard approach is to write a collection of test files tweaking various pieces of the format (see gnumeric/samples dir in svn). I've yet to hit any significant binary blobs that are not also in ODF (eg emf/wmf images). Indeed, while reviewing parts of Spreadsheetml I haven't come across significant binary content. There is lot's to complain about in OOX without our making up random stuff.

Dangers of taking code from Novell

[boriquajake]

Does that mean that we should all turn our noses up at the ATI drivers that are coming from Novell? No matter what else you think you heard or read, that facts are that Novel and its relationship with AMD is the only reason the OSS world is finally going to get a 3D graphics driver.

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:Novell is distributing concealed patent landmin

[huckamania]

Saying a thing and having it be true are two different things. Miguel is just acknowledging the futility of making a pledge about not violating patents he is not aware of existing.

As many people are quick to point out, Microsoft has more to lose by disclosing which of its many stupid patents the various pieces of software often refered to (rightly or wrongly) as Linux may be violating. If and when they release that list, then Miguel, and probably everyone else with half a brain, will be able to say whether or not their software is patent encumbered.

Only a Stallman type would say in advance that their code is not violating any patents. It's probably in the GPL somewhere.

Re:Novell is distributing concealed patent landmin

[MenTaLguY]

Having just read the blog comments, they didn't really help. What are the "correct" conclusions supposed to be?

I've been a defender of yours in the past (e.g. prior to Sun's dramatic liberalization of Java, I was advocating Mono as the least worst alternative), but this situation with Moonlight leaves me very uncomfortable. While the Mono patent policy seems sane, it seems the Moonlight policy means that Moonlight fails the "could you fork it?" acid test -- at least, forking Moonlight would mean knowingly assuming a patent liability with respect to Microsoft. That's a bit different from a project which has a less direct relationship with Microsoft IP.

Way off Topic, but please respond

[YetAnotherBob]

Miguel,

I see the flame fest continues, but could you please take a little time out and give me an answer to a question I have.

I've posted this in the past. I see a problem for us (humanity) in the future. We would like to be able to go to a digital world. As things stand now we can't. The reason is file formats.

Documents like birth and death certificates, property deeds, legal writs, treaty's etc. need to be available and readable for CENTURIES. File formats for the last 30 years or so change every 3 years. After two or at most 3 cycles, the format is no longer readable. That makes digital documents unacceptable. We need centuries for file retention, with full readability. We get a couple of years.

The only real contender right now is ASCII text. That file format has been with us for 50 years now, and continues to remain readable.

I work for a government body, with buildings. Permits are a matter of life safety. If we can't keep track of what is in a building, people die. There is still no substitute for paper records. They are the ONLY long term recourse we currently have. the great need is for a file format that can remain unchanged for centuries. (The best long term recording medium seems to be mud. Summarian records and literature from 5,000 years ago are still readable, if you know the language.)

we desperately need a real long term document format.

ODF tries to be that. I believe that the jury is still out on whether it can fulfill that need or not. OOXML seems to be too linked to a product that will continue to change. OOXML also has those digital blobs that will NEVER be human readable without the originating program. The standard will change radically in the next few years too. That renders it unusable for my needs.

Ideally, I'd like to have a file that would allow setting up forms that would be relatively easily for a human to read, and would explain itself adequately for document recreation. It needs to have this without having to have the originating program, or any other reference than the file itself. I need that for drawings too. It doesn't exist. Even for relatively easy things like forms and written reports it doesn't really exist.

*Shouldn't we all be pushing for standards that are independent of any product?* That seems to be the only way we'll get what we really need.

Maybe TeX? HTML showed promise for a while, but it keeps changing too. OOXML doesn't have what I need. I'm not at all sure that ODF does either.

Oh well, I guess paper is not going to go away.

It was a shock

[aim2future]

First I was shocked, then I believed that someone was pretending to be Miguel, but when checking his profile and all it seems as it really was Miguel saying this. I also had hard to imagine that he would have been paid by Microsoft to say this, so I really don't understand his motives.

Here in Sweden we are currently arguing with Klas Hammar, who is business area manager for Microsoft Sweden. Recently, in a a debate article (7th Sept, in Swedish) he claimed that OOXML is "future safe" and in another article (today 11th of Sept, also Swedish), he says "one could ask why it shouldn't become a standard".

For him and others I collected the documents I had studied before the decision to reject OOXML and put them here (all in English). It is a collection of some documents from e.g. Google, Oracle, Spain FFII, Italian PLIO etc which very clearly describes the flaws of OOXML. This page could probably be useful for Miguel to read as well. This is not to compete with <NO>OOXML, it is just to illustrate how we have come to this conclusion on our own.

We are not opposing OOXML by principle just because it's Microsoft, in fact we looked forward to the Microsoft XML format a few years ago, but that was before we understood how bad an "XML" specification could be designed. OOXML is a rough draft, nothing to take seriously as it appears now. I also have a blog entry about this if you want to send me some comments. (I'm not a blogger, otherwise)