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.'"
Maybe the opposite is Uninformed Praise and Optimism (UPO).
It seems he hasn't read about how you can "look but not touch" when it comes to the internal data. An expert in the Office format recently proved you could modify the xml in the new Office formats but Office would complain and not load it.
The fact that it's XML seems to only benefit the world in one way, it compresses nicer.
Now, to put this in perspective: Jim Mason (of Oak Ridge National Laboratory) isn't on one side or the other, but has been doing document-format specifications for a looooong time -- he was, I believe, the founding chair of SC34 and had a hand in the creation of SGML. The dude knows documents, he knows standards, and when he writes
I'm inclined to take his word for it than Miguel's.Lacking <sarcasm> tags,
The fact that Microsoft has their legacy blobs all over the OOXML that they write is exactly why I don't like it. They don't seem to want to implement it in an open fashion. They just want to fein like they are being open so that all of the goverment agencies and corporations that are concerned about vendor lock-in are given a warm fuzzy feeling.
So yeah, the standard is shit. Nobody can implement it the way that the creator can, by the creator's very design. It is defective by design, as the nutty FSF people like to say.
v4sw6PU$hw6ln6pr4F$ck 4/6$ma3+6u7LNS$w2m4l7U$i2e4+7en6a2X h
The implications of this are that OOXML is considerably more expensive to implement because there aren't a lot of components to choose from (eg, compare the number of SVG serializers to DrawingML serializers). Building upon existing standards is a very important part of a good standard, I think (and so do the ISO)
Don't take my word for it though, both files are ZIPs of XML* so google for some files and see which one makes sense to you :)
[*] although it's recently been discovered that OOXML refers to OLE objects which are undocumented in OOXML and in Office '07 these are stored as binaries :( ODF and OOo have their own problems of course, but nothing complex like this.
Well, let's take a look at one company's deployment of Office 2007 to 25,000 workstations. Oh, what's that? It's still crap? Figures.
Yes, the information should help people interoperate with Microsoft. But all the parts they're keeping from us are important. They want to control de facto standards and keep all other ISVs at second-tier status without having to make good products.
People would be better off with standards not controlled by any one company. Even if Microsoft were the most benevolent company in the world, there's no excuse for giving another company the power to hold your documents hostage in this day and age. And it's about time that people realized that, especially when Microsoft has intentionally perverted standards like ACPI to harm Linux.
The PDF link above is just for proof. Here's a transcript of the PDF so you don't have to view it unless you don't believe me:
Not if Microsoft keeps using it you can't.
Sure, you can ignore it if it comes up in a document, but if a user with little care or knowledge about such issues loads a document up that uses such a tag in (for example) OOo and their table doesn't look like it did in Word, they're probably going to think that OOo is at fault, and may make a decision to not use the alternative software in the future (or may go around telling everyone they know that said software sucks).
If Microsoft, the developer of the main product which generates these data files continues to use these tags, they become impossible to ignore without introducing rendering issues which will be sufficient to annoy potential users of alternative software.
Yes, purportedly these tags are only supposed to be used by Microsoft when converting documents in older Word formats -- but how many hundreds of millions of such documents exist out there? Quite a few, which seems to guarantee that these "ignorable" tags are going to occur quite frequently, and will impose sufficient differences on document rendering if they are ignored. So unless these optional tags are fully documented, why should anyone outside of Microsoft want to adopt this standard?
Standards aren't often perfect the first time around, but someone at Microsoft should have realized this, and should have prevented themselves from trying to fast-track this standard. The biggest problem is that there is the appearance that Microsoft was trying to pull a fast-one on the international standardization community with an incomplete, and highly imperfect standard that they wanted to rush to fruition for purely competitive (and not technical) reasons. With time and revision, OOXML may indeed be a fine standard, but as it stood at the point where they tried to ram it through the ISO, it had (and has) serious flaws.
In one of your other posts to this thread, you mention:
Here you admit that you've already seen first hand how incomplete standards can affect Open Source (and really any third-party) development. You had a problem with the lack of documentation, and pressured MS for more details to get your software working correctly. So why is it that you have an issue when others want to pressure MS into either rectifying other areas lacking proper documentation, or removing them from the standard altogether, in areas that matter to them?
Yaz.
3 things about computers: they're alive, they're self-aware, and they hate your guts.
Icaza being a Microsoft shill seams to be the only logical explanation.
Nobody who would create an international standard with the intent that it is actually used by the public would have created a standard covering 6,000 pages. That is just ridiculous.
A "superb" standard would build on existing standards, like using standard XML (which is something you would really expect from something called OpenXML). It wouldn't introduce bugs in its date handling because some application (Excel) not using that standard has the bugs. If you read the comments from the British committee examining that "standard", it is completely riddled with errors big and small.
Now I wouldn't want to decide whether the problems come from some Microsoft evilness, or from this being a complete rush job (if you compare this to how long development of the C standard or C++ standard takes, where every single line is examined again or again), but this "standard" should never, ever have been put on the ISO fast track. Maybe in a few years time, if Microsoft has had time to fix all the problems.
For those who don't know: Usually introducing an ISO standard is a multi-stage process. The standard is suggested, then comments are collected, problems are fixed, again and again, until eventually the whole thing has the quality and the consensus that is required for an international standard and then it goes to the vote. This proposal has gone on the fast track, which should have been reserved for standards that have passed all the early stages. Like if there had been an industry wide consensus where everyone followed the same document, and then someone has the idea to turn this wide consensus into an official standard. It shouldn't be used for something thrown together quickly.
No, I don't think that Icaza could call this a "superb" standard unless he was paid to do it. Not that I blame him; I would do the same thing if you gave me enough money. This post here is my unpaid-for opinion, I'll write another one if anyone comes up with say a five digit number.