Slashdot Mirror
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.'"
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.
Systemd: the PulseAudio of init systems
. . . 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
Some reasons why OOXML is unacceptable:
:P
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?
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
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.
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.
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 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.)
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.
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.
Javascript + Nintendo DSi = DSiCade