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.
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.
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?
You can entertain it, but I never made the claim that Jody said it was a superb standard. Jody is addressing Rob Weir's criticism that "See! Gnumeric cant load it" when Gnumeric's support was written over two intercontinental flights (7-8 hours).
I never said that Jody endorsed OOXML as a great standard; I think its superb as far as standards go, but that is my opinion. I like red wine, hate white whine; I like Chomsky, hate Fox news; I like tacos, hate burritos; but that somehow does not make it to Slashdot.
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 "expert" was Stephane Rodriguez and his comments and analysis are as solid as a tabloid newspaper.
Actually, when incorrectly altering the XML file in the way that Stephane did, Excel will warn you, and still load the file (and reconstruct the data that you messed up).
That was a case of "Doctor it hurt when I do that... then dont do that".
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).
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:
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
By exposing all of the Silverlight 1.1 API, does that include all of the namespaces that are supposed to be supported by it too? Including stuff like Linq to XML, WCF, etc? (honest question here)
Correct, its is all in there. Follow the instructions on the Mono site.
Yes, Moonlight will work on Solaris (Mono already runs on Solaris x86 and SPARC)
We will support a SPARC port if someone gives us a machine that is faster than the dog that we got as a machine (A T1000 or so with 6 cores is slower than any computer six years ago).
"[D]etails that might be necessary to implement 1.0, beyond what is currently published on the web"...why are not all Silverlight specs and APIs publicly available? Are people supposed to pay money to develop on this platform, or are they strategically delaying publishing the specs, or what? In any case it sounds very fishy. Enlighten me if there is a good explanation for this that I am missing.
Let me explain.
The specs as published on the web are pretty complete as far as a programming API goes. But there are some things that we do not quite understand how they work (either because the docs are not as complete as they should be, or because as implementors we need more details about the internals than those that are visible to the end user.
One thing that we have noticed over the years is that internal specifications are probably built by PMs at Microsoft. And these PMs use these internal specifications to explain certain behaviors on their blogs. I suspect this is because it is a fast path of communication as opposed to going through the documentation pipeline for released products. They are also probably able to clarify things for docs that have been already published. This is my guess.
So access to the specs is basically access to some documents and explanations that might not have made it to the public specification (for example recently Jackson and Chris had some questions about how the namespaces for CreateFromXaml behaved in the presence of merged trees, and it was not entirely clear how it worked; Luckily the Microsoft PM in charge of this was able to resolve the question in seconds).
he only thing I am sure about is that after years of Miguel de Icaza following a not-always-popular pro-Microsoft approach, today he must feel quite vindicated: Microsoft has taken another big step towards respecting and collaborating with Linux (or at least Novell), and Miguel is a big part of that.
Thanks for the nice words; I do feel that way.
In general, I think that there is much to be gained by having friendly relations with everyone in the industry instead of taking an antagonistic position. You attract more bees with honey than with vinegar kind of thing, and am glad that this is starting to show. I hope to see more collaborations between Microsoft and the Linux community in the future, not limited to Mono, but going beyond that.
Acording to CNet (http://news.com.com/8301-10784_3-9769714-7.html): Version 1.1 will be announced in may, and will be tightly integrated with.NET. Game over. Mono can't keep up.
Actually, Moonlight as of today already integrates with Mono, already exposes all of the Silverlight 1.1 API and already runs most of the samples on the net (modulo a lot of bugs;-)
It's an ECMA thing now. Microsoft can't promise to fix anything.
Unless they lied when they said it wasn't theirs any more and was now ECMA-controlled and hence not just a one-vendor format.
By the way, name some folks implementing it. Urls please.
Microsoft is part of the ECMA committee and together with a dozen others, they triage the feedback that comes in, suggest fixes and send those to the editors. So it has to go through a discussion, but they still can fix plenty of the issues raised.
Gnumeric, OpenOffice.Org and Apple iWorks all have various degrees of support for OOXML.
Am not sure why you want me to defend their products; I do not use them, beyond the casual use. The discussion is not about their products, but about a specification they published, it is an important distinction.
We get that you try to make money programming for environments created by Microsoft. Great. We all have to pay the bills. But it seems to me your criticism of Microsoft is tempered by the fact that you ultimately make money from dealing with complexity created by Microsoft.
A few months ago I realized that the criticism of OOXML had gotten out of hand, I had not read the specs but the flash-mob like attack on it made it look terrible. I got the feeling it had to be an exaggeration, researched it, and found that what we had was basically a witch burning party.
Here he comes to save the day! It's WonderMiguel. Always read to come to the defense of Microsoft.
Otherwise, horrible things could happen, like ODF could be used instead, or it could be extended to include stuff in OOXML and then the world would have one unified standard, instead of two of them even experts can't use that are not interoperable. We couldn't have that.
So the entire FOSS world wishes to thank Miguel for helping Microsoft keep its users locked in. Hey, man, what kind of game are you playing?
Call me crazy, but unlike Bush I do not divide the world in "them" and "us" I like to live in a world of colors, a world of Pantone if you will and abandon the black and white mentality.
There are good and bad things about Microsoft. When they do something bad, I point it out, when they do something good, I do not see why I would not point it out. I also try to judge everyone with the same metric, I do not use one metric to judge Microsoft, and another one for us.
Stephane's article touches on a subject that I have plenty of experience on (I originally wrote Gnumeric, and later worked with Sun to open source StarOffice and over the years worked to grow the OOo team at Ximian and later at Novell).
Stephane's criticism lacks meat. If someone had done a review of Linux with this level of quality, we would have rightfully called it bullshit.
Don't run from the real point: the only way to properly implement OOXML is to use MS Office. Any other method, and you can never implement the whole specification.
Speak for yourself.
The fact that you can not, does not mean that real hackers or professionals can not. For instance, those that are actually implementing support for it on various project do not seem to share your opinion.
There are real problems with the specs and real limitations that must be addressed, and a lot of great feedback is being sent to the maintainers to address them. But Stephane's post contains little or nothing valuable.
As Brian Jones (a very reasonable blogger on the OOXML team) has said, they are looking forward to addressing the issues.
This is not proof of OOXML being defective by design. It only shows that apparently MS's software isn't able to handle OOXML properly.
If Office can't read OOXML files produced by other tools, and other tools can't read Office OOXML files, where do you suppose end users will place the blame?
And what do you suppose users will do when faced with incompatibilities?
but Office can read OOXML files produced by other tools; You just have to generate proper files.
Stephane basically wanted a shortcut, and gets upset that he can not use a shortcut. This is equivalent to complaining that a web browser wont display things properly when you feed it invalid CSS.
In addition, Excel happens to recover nicely from the lack of data that Stephane complains so loudly about, you just happen to get a warning if the file you feed it happens to be incorrectly formed and even offers you an option to "repair" it.
It boils down to: the fact that is XML does not mean that you can modify it in any way you want; There are rules for modifying the schema and Mr Stephane is not happy with that. Had he followed the actual rules he would have had no issue.
This is a case where two locations must be updated per the spec; He can avoid updating the two locations by removing the chainCalc.xml file (which is optional, and Excel will reconstruct). He later gets upset because if he does that, he claims performance on load will be slower.
"2) Entered versus stored values"
His second point in "2) Entered versus stored values" in an interesting distinction between entered values and stored values. It reflects the way that Excel works (and so does Gnumeric) by storing the values instead of the data that was entered by the user. This responds to the need of the spreadsheet to do something interesting with the data, for example when you enter a date, it is stored as a number with a format applied not as a string. This allows computations on dates to happen based on the underlying numeric value. The featured is used extensively by spreadsheets.
In the Excel/gnumeric case you have to generate a single value, in the ODF case you must generate and update the two values (which just a point before, Stephane was having a seizure about).
The precision issue that he brings up, I suspect is merely an issue with double format precision. He claims that the data is unusable and there is a loss of precision, but handing that out to a C compiler will produce the expected result with no loss of precision. I do not know how "atof" or the compiler work internally to cope with this issue, but at least my libc/gcc combo does not have this problem.
I would not be surprised if this is an artifact of floating point, someone with more background on doubles and floating point math could probably answer the question with more authority, but a cursory read of "What Every Computer Scientist Should Know about Floating Point" seems to validate that there is no error in the floating point representation for the values that he uses: http://docs.sun.com/source/806-3568/ncg_goldberg.h tml
3) Optimization artefacts become a feature instead of an embarrasment
His 3rd point is open for debate, like the 1st case, we have a case where he has to handle things differently. Stephane sells a commercial product to handle Excel files and I suspect that his product has to cope with the same patterns in different ways, which has naturally upset him. OOXML might be inspired by Excel's needs, but it does not mean that it has to be a 1-to-1 match.
4) VML isn't XML
VML is labeled as "deprecated" in the OOXML documentation (Section 8.6.2, page 25) and it states: "The VML format is a legacy format originally introduced with Office 2000 and is included and fully
defined in this Standard for backwards compatibility reasons. The DrawingML format is a newer and richer
format created with the goal of eventually replacing any uses of VML in the Office Open XML formats. VML
should be considered a deprecated format included in Office Open XML for legacy reasons only and new applications that need a file format for drawings are strongly encouraged to use preferentially DrawingML."
So the standard basically says "VML is still in use, but its better to use DrawingML". Stephane misconstrues the above statement and tries to portray this as evil
Is it just me or the description of the data mining sounds like an article The Onion would write for how obvious this is?
"We found that robberies happened in places where there was money, on the days that there was money".
Call me crazy, but I get the feeling that this is hardly news. The police officers that hang out in the banks are not there because the bank offers a nice shade during the hot hours of the day.
I also think the Cuban scenes were counterproductive because he goes on about how great Cuba is, while at the very beginning of the movie, he reveals a chart that shows Cuba is ranked below the US in health care.
I noticed that, too, and saw it as one of the points that many right-wingers will cling to from the movie. However, there's something to be said about it. Yes, the US has fallen to 36th or whatever in terms of quality of healthcare, with Cuba being just below it. The important part is that only the people who can afford it in the US can get that 36th-ranked healthcare, whereas everyone in Cuba is entitled to their 37th-ranked healthcare. Basically, Cuba has the same quality of healthcare as the US, but it's open to everyone.
Very interesting observation.
Although the Cuba bit is sensationalist, there was one positive outcome: the rescue workers were treated. Before the movie came out there was a news article reporting on the ongoing care that these people received after Michael Moore's crew left and the cameras stopped rolling.
Unfortunately it is and always will be Microsoft leading the way, Mono & Co lagging behind. Nothing will change that.
Of course "Mono & Co" will always be lagging behind.. What, you expect the re-implementation to come before the original? Regardless, is a lag of 21 days really a dealbreaker here? You didn't buy Vista the day it was released did you? Lighten up on the blanket defeatism, sheesh. It's not War and Peace.
Well, certainly at the core of what Silverlight can do, we are following Microsoft direction, but we have already taken Silverlight in new directions, for example we are able to use it to extend Gtk# applications and to create desklets. Both things that were not initially supported by Silverlight.
Slashdot Mirror
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.
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.
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).
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.
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.
You can entertain it, but I never made the claim that Jody said it was a superb standard. Jody is addressing Rob Weir's criticism that "See! Gnumeric cant load it" when Gnumeric's support was written over two intercontinental flights (7-8 hours).
I never said that Jody endorsed OOXML as a great standard; I think its superb as far as standards go, but that is my opinion. I like red wine, hate white whine; I like Chomsky, hate Fox news; I like tacos, hate burritos; but that somehow does not make it to Slashdot.
Miguel.
What about it?
What has OOXML got to do with that?
OOXML is a free spec released under the MS OSP, if that is what you mean.
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.
The "expert" was Stephane Rodriguez and his comments and analysis are as solid as a tabloid newspaper.
Actually, when incorrectly altering the XML file in the way that Stephane did, Excel will warn you, and still load the file (and reconstruct the data that you messed up).
That was a case of "Doctor it hurt when I do that... then dont do that".
I rebutted Stephane's "analysis" here:
http://developers.slashdot.org/comments.pl?sid=279895&cid=20363627
But there is also a long thread in Brian Jones where people pointed the same thing.
Miguel.
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
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
"but be careful: the generated tables that Ophcrack uses are really big, and you should need up to 15 Gbytes to store these tables."
Since when 15 gigs were considered "really big"?
Aren't people at conferences handing out USB sticks as schwag with 493424 gigs these days in exchange for your business card?
Correct, its is all in there. Follow the instructions on the Mono site.
Miguel.
My advise to those folks that have strong predictive powers is to invest in the stock market.
If your predictive powers are good you can turn a nice profit.
Miguel.
Yes, Moonlight will work on Solaris (Mono already runs on Solaris x86 and SPARC)
We will support a SPARC port if someone gives us a machine that is faster than the dog that we got as a machine (A T1000 or so with 6 cores is slower than any computer six years ago).
Miguel.
Let me explain.
The specs as published on the web are pretty complete as far as a programming API goes. But there are some things that we do not quite understand how they work (either because the docs are not as complete as they should be, or because as implementors we need more details about the internals than those that are visible to the end user.
One thing that we have noticed over the years is that internal specifications are probably built by PMs at Microsoft. And these PMs use these internal specifications to explain certain behaviors on their blogs. I suspect this is because it is a fast path of communication as opposed to going through the documentation pipeline for released products. They are also probably able to clarify things for docs that have been already published. This is my guess.
So access to the specs is basically access to some documents and explanations that might not have made it to the public specification (for example recently Jackson and Chris had some questions about how the namespaces for CreateFromXaml behaved in the presence of merged trees, and it was not entirely clear how it worked; Luckily the Microsoft PM in charge of this was able to resolve the question in seconds).
Thanks for the nice words; I do feel that way.
In general, I think that there is much to be gained by having friendly relations with everyone in the industry instead of taking an antagonistic position. You attract more bees with honey than with vinegar kind of thing, and am glad that this is starting to show. I hope to see more collaborations between Microsoft and the Linux community in the future, not limited to Mono, but going beyond that.
Miguel.
Actually, Moonlight as of today already integrates with Mono, already exposes all of the Silverlight 1.1 API and already runs most of the samples on the net (modulo a lot of bugs
Miguel.
Microsoft is part of the ECMA committee and together with a dozen others, they triage the feedback that comes in, suggest fixes and send those to the editors. So it has to go through a discussion, but they still can fix plenty of the issues raised.
Gnumeric, OpenOffice.Org and Apple iWorks all have various degrees of support for OOXML.
Miguel.
Am not sure why you want me to defend their products; I do not use them, beyond the casual use. The discussion is not about their products, but about a specification they published, it is an important distinction.
A few months ago I realized that the criticism of OOXML had gotten out of hand, I had not read the specs but the flash-mob like attack on it made it look terrible. I got the feeling it had to be an exaggeration, researched it, and found that what we had was basically a witch burning party.
Miguel
Call me crazy, but unlike Bush I do not divide the world in "them" and "us" I like to live in a world of colors, a world of Pantone if you will and abandon the black and white mentality.
There are good and bad things about Microsoft. When they do something bad, I point it out, when they do something good, I do not see why I would not point it out. I also try to judge everyone with the same metric, I do not use one metric to judge Microsoft, and another one for us.
Stephane's article touches on a subject that I have plenty of experience on (I originally wrote Gnumeric, and later worked with Sun to open source StarOffice and over the years worked to grow the OOo team at Ximian and later at Novell).
Stephane's criticism lacks meat. If someone had done a review of Linux with this level of quality, we would have rightfully called it bullshit.
Miguel.
Speak for yourself.
The fact that you can not, does not mean that real hackers or professionals can not. For instance, those that are actually implementing support for it on various project do not seem to share your opinion.
There are real problems with the specs and real limitations that must be addressed, and a lot of great feedback is being sent to the maintainers to address them. But Stephane's post contains little or nothing valuable.
As Brian Jones (a very reasonable blogger on the OOXML team) has said, they are looking forward to addressing the issues.
Miguel.
but Office can read OOXML files produced by other tools; You just have to generate proper files.
As its pointed out in this thread:
http://blogs.msdn.com/brian_jones/archive/2007/08
Stephane basically wanted a shortcut, and gets upset that he can not use a shortcut. This is equivalent to complaining that a web browser wont display things properly when you feed it invalid CSS.
In addition, Excel happens to recover nicely from the lack of data that Stephane complains so loudly about, you just happen to get a warning if the file you feed it happens to be incorrectly formed and even offers you an option to "repair" it.
Stephane has for a long time presented a weak case against OpenOffice XML.
"1) Self-exploding spreadsheets"
His top issue "1) Self-exploding spreadsheets" has been discussed on Brian Jones' weblog:
http://blogs.msdn.com/brian_jones/archive/2007/08/ 15/why-there-s-no-microsoft-in-open-xml.aspx
It boils down to: the fact that is XML does not mean that you can modify it in any way you want; There are rules for modifying the schema and Mr Stephane is not happy with that. Had he followed the actual rules he would have had no issue.
This is a case where two locations must be updated per the spec; He can avoid updating the two locations by removing the chainCalc.xml file (which is optional, and Excel will reconstruct). He later gets upset because if he does that, he claims performance on load will be slower.
"2) Entered versus stored values"
His second point in "2) Entered versus stored values" in an interesting distinction between entered values and stored values. It reflects the way that Excel works (and so does Gnumeric) by storing the values instead of the data that was entered by the user. This responds to the need of the spreadsheet to do something interesting with the data, for example when you enter a date, it is stored as a number with a format applied not as a string. This allows computations on dates to happen based on the underlying numeric value. The featured is used extensively by spreadsheets.
In the Excel/gnumeric case you have to generate a single value, in the ODF case you must generate and update the two values (which just a point before, Stephane was having a seizure about).
The precision issue that he brings up, I suspect is merely an issue with double format precision. He claims that the data is unusable and there is a loss of precision, but handing that out to a C compiler will produce the expected result with no loss of precision. I do not know how "atof" or the compiler work internally to cope with this issue, but at least my libc/gcc combo does not have this problem.
I would not be surprised if this is an artifact of floating point, someone with more background on doubles and floating point math could probably answer the question with more authority, but a cursory read of "What Every Computer Scientist Should Know about Floating Point" seems to validate that there is no error in the floating point representation for the values that he uses: http://docs.sun.com/source/806-3568/ncg_goldberg.h tml
3) Optimization artefacts become a feature instead of an embarrasment
His 3rd point is open for debate, like the 1st case, we have a case where he has to handle things differently. Stephane sells a commercial product to handle Excel files and I suspect that his product has to cope with the same patterns in different ways, which has naturally upset him. OOXML might be inspired by Excel's needs, but it does not mean that it has to be a 1-to-1 match.
4) VML isn't XML
VML is labeled as "deprecated" in the OOXML documentation (Section 8.6.2, page 25) and it states: "The VML format is a legacy format originally introduced with Office 2000 and is included and fully defined in this Standard for backwards compatibility reasons. The DrawingML format is a newer and richer format created with the goal of eventually replacing any uses of VML in the Office Open XML formats. VML should be considered a deprecated format included in Office Open XML for legacy reasons only and new applications that need a file format for drawings are strongly encouraged to use preferentially DrawingML."
So the standard basically says "VML is still in use, but its better to use DrawingML". Stephane misconstrues the above statement and tries to portray this as evil
If by fully specified, you mean "it completely avoided the formula issue", then yes.
OOXML contains 700 pages to document that, ODF, zero.
Miguel.
Is it just me or the description of the data mining sounds like an article The Onion would write for how obvious this is?
"We found that robberies happened in places where there was money, on the days that there was money".
Call me crazy, but I get the feeling that this is hardly news. The police officers that hang out in the banks are not there because the bank offers a nice shade during the hot hours of the day.
Very interesting observation.
Although the Cuba bit is sensationalist, there was one positive outcome: the rescue workers were treated. Before the movie came out there was a news article reporting on the ongoing care that these people received after Michael Moore's crew left and the cameras stopped rolling.
It should be very easy to support OSX, but Microsoft already supports OSX, so there is not much of a motivation for us to put the cycles on it.
Well, certainly at the core of what Silverlight can do, we are following Microsoft direction, but we have already taken Silverlight in new directions, for example we are able to use it to extend Gtk# applications and to create desklets. Both things that were not initially supported by Silverlight.