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.'"

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)

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

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.

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.

Read his latest comment . . .

[Anonymous Coward]

. . . here [google.com] 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, [e-mail] 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/ [gnome.org]

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

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 [blogspot.com]

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 [linux-watch.com]

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 [tirania.org]

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 [slashdot.org] 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

This is the end of my respect for Miguel

[IWannaBeAnAC]

I have been following the OOXML saga fairly closely; from Rob Weir's blog [robweir.com], to the NO-OOXML site [noooxml.org] (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 [consortiuminfo.org], 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.

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

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: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/ [gnome.org]

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: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/ [gnome.org]

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: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 [openmalaysiablog.com]

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: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: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: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: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: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 [nzoss.org.nz].

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

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.

Re:Try #2

[ardor]

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

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

Re:OOXML.

[rastos1]

Would you mind to share your thoughts on the standardization process too? A very nice article [abclinuxu.cz] (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: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? [atis.org] in the light of the comments [noooxml.org] from various organizations?

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

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: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 [grokdoc.net], 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: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 [slashdot.org]

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 [noooxml.org]

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.