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