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.'"
I'm sorry, Miguel, but this is getting weirder and weirder. You may be a sierra-hotel coder, but I'm not sure that translates into authority to make legal commitments on behalf of Microsoft.
Lacking <sarcasm> tags,
I'll think about getting it from Novell....as soon as MS hands over the list of "patent violations". IMHO, this is just a try to make the "If it's Novell/MS, it's legal" line of shite more palatable.
If you're going to try to feed us a crap sandwich, do NOT tell us it's filet mignon.
Don't tell me to get a life. I'm a gamer; I have LOTS of lives!
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.
CDE open sourced! https://sourceforge.net/projects/cdesktopenv/
First Mono. Now he wants us to download stuff from a specific vendor to get patent protection. And finally he thinks a standard that has hundreds of pages of backward compatibility modes for 10 year old apps is a good standard? Is there anyone not ignoring him completely yet?
I still have more fans than freaks. WTF is wrong with you people?
It's his own blog.
Done with slashdot, done with nerds, getting a life.
Miguel has been fascinated with Microsoft since long before he started writing Gnome, and that fascination shows no signs of having waned. Unfortunately, while it allows him to see the good things MS has done in a clearer way than many of those in the free software world, it also tends to give him a bit of a blind spot where some of their deficiencies are concerned.
Use his stuff or don't. It's not like all the coding talent in the world is being exhausted on his projects. I have no interest in .NET or Mono, and what's it to you if other people do?
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Read the fucking link, instead of ripping on the guy for selectively chosen comments without their supporting context and explanation.
(a) He says OOXML is great not because the specification itself is a work of engineering genius, but because out in the Real World is easier to implement than ODF. That might not be for a good reason (OOXML is similar to existing World formats in structure, and so existing code is easily modified to use it, where ODF requires an entirely new approach and so is far harder to add to existing software), but it's certainly a different story than Miguel just blindly loving the OOXML spec.
(b) The patent protection claim is exactly what it sounds like, except for the fact that there are NO known parents which Moonlight or Mono infringe. It's a simple of matter of, "if something comes up, we won't sue your customers." Those same companies (Microsoft and the MPEGLA group) are still totally free to sue the developers and companies behind FFMPEG, Linux, GNOME, KDE, Apache, X.org, OpenOffice.org, etc. Nothing about the protection Novell offers will increase the risk of those lawsuits - all it does is decrease the risk for people who download from them. It's a nice gesture that some suit-wearing types give a fuck about, and the rest of us are free to ignore just like we ignore the patent minefield for every other project, all of which are guaranteed to be infringing _something_.
(c) The article submitter is a sensationalist jackass.
> He's been praising Microsoft for years, every chance he gets.
.NET and was all setto rewrite GNOME using that patenttrap. Thankfully saner heads have prevailed.... so far.
Not only that, he has yet to encounter a Microsoft technology he didn't like so much he wanted to clone it into the Free Software world and make us all dependent on it.
For years the joke was GNOME was cloned Microsoft internals with a goofy (vaguely MAc inspired treat the user as an idiot motif but without the consistency or polish of the Mac UI to make up for it) UI while KDE was cloned Microsoft UI with goofy Trolltech internals. Then Miguel hell head over heels in love with
The sooner we all write off Miguel and Novell the better off we will all be. Taking any code from that camp is just inviting a lawsuit. Sooner or later, BOOM!
Democrat delenda est
Yes, he said this: "ODF's model of 'chartness' didn't fit well with Gnumeric. In contrast XLSX may be ugly, but it''s concepts were very familiar from XLS. We already had much of the code required to handle it."
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?
This, and comments like "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)" doesn't help your position stand up.
When you publish your opinion, people read this opinion and you get feedback on it. If you were an average Joe, probably no one would care. You're not however, this is why people like you should put more thought into what they put out in the public than you did, and then now whine that someone "obsesses" over it.
Yeah, starting with an ad hominem makes me want to take your arguments seriously.
Microsoft's Office XML Standard is clearly bad in a number of respects: unnecessary deviation from established standards, encapsulation of binary formats, and backwards compatibility with obsolete MS Office formats. It does, however, indeed have the advantage that it's easier to import for code that's already been written to import the old binary formats. On the other hand, it's just as clearly harder to process using XML tools.
Now, the question is: are the primary use cases for which we should design an XML office format office suite input/output routine, or are the primary use cases XML processing.
Well, let's see: there are half a dozen office suites around: MS, Gnome, KDE, Apple, and a couple of commercial ones. Each of those needs to implement a reader/writer once. On the other hand, there are thousands of uses and implementors for information extraction and transformation of office documents.
Seems pretty clear to me that we should optimize XML office formats for XML processing, not for the convenience of the implementors of office suites. And that, in a nutshell, is why Microsoft's office format is worse than ODF.
I dunno. I figure Miguel is a smart fellow who is managing to do well for himself and support free software simultaneously. .Net-ified version of MS Office, with obscured assemblies the run fine on Mono.
When the time and market is right, Redmond will push a
Project vomit while you may, if it keeps gives Redmond life beyond Vesta, then Miguel may be doing us all a little favor.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
> but we have to support them both *anyways*, so its not like its a big deal.
... but can't read the documents we're creating at the start of the 21st century. How will we learn from our history if we can't study it fully?
Holy mackerel.
First: I really don't care to get into a pissing match about the deficiencies of OOXML as a possible standard (they are legion and often fundamental; and whether or not you understand that and/or choose to minimize the severity of these things changes nothing). I will say that I'm very happy to finally see at least *some* open documentation for the new Microsoft Office format; that has to make things easier for the people implementing filters. As such I am completely unsurprised that those people are happier than they were a couple years ago. In fact, I'd be surprised if they weren't. That part is probably something you and I agree on =)
However the quote above is utterly shocking. Let me explain what I mean:
You are right that we have to support both OOXML and ODF out of practicality. But you know what? That sucks. It would be best for everyone if there was only one format to support. Nobody would lose in that scenario, except perhaps the owners of companies with business models that depend on format variance to sell their product.
In the case of document format storage, a standard is truly important because formats (poor or not) that eventually lose implementations over time carve out blank spaces in our history once we can't read them properly. These same formats are also the source of certain information inequalities in society (e.g. those who can't obtain an implementation for financial, social or political reasons). This may not matter so much for Acme Inc's quarterly reports but it sure does for government, health and other socially vital information. Remember when some hurricane Katrina victims couldn't use the FEMA website because they had slightly older computers? This isn't a made up boogyman, this is stuff that bites us as a society fairly regularly. Now imagine a hundred years from now when we can still read the constitutions of our countries, research papers, poetry and other examples of human kind's great literary works that are hundreds or even thousands of years old
Getting proprietary formats out of the way as soon as possible so that we do not extend this mess any further than necessary is absolutely the responsible thing to do in light of our (hopeful) future.
By allowing OOXML to pass from "specification" to "international standard" would be doing exactly that: extending the problem as it will give years if not decades more life to the format. If OOXML was rationally implementable and properly documented, it wouldn't be as big of an issue. It would be, as you put it, simply suboptimal. The fact of the matter is that OOXML is not rationally implementable and not properly documented. That's why it lost the recent vote; it wasn't because of lobbying (and trying to imply that when Microsoft got its hand caught in the cookie jar is pretty ballsy, by the way). Are some interests acting out of concerns for their business models or pet projects when they rally for ODF and against OOXML? I'm sure they are; but that alone isn't reason to dismiss the fact that OOXML is problematic and that we don't need two standards (any more than it is to dismiss OOXML just because it comes from Microsoft).
So please, admire OOXML for what it is: a step forward in documenting what historically has been one of the more pernicious sets of file formats we've had to deal with; but don't mistake that for being a reason to make it an international standard which will only prolong the issues that are part and parcel of the Microsoft Office formats, even in this current version of the specification.
I know that having a bunch of people shit on you in public sucks major donkey nuts and certainly would put most rational people into a rather ungracious mood, but please think above that noise and consider with your intell
Not only that, he has yet to encounter a Microsoft technology he didn't like so much he wanted to clone it into the Free Software world and make us all dependent on it.
That leaves us not far from where we are today.
Miguel, you seem to feel that you can play words one way one minute, then another way the next. My own personal opinion is that you are losing a lot of credibility with your own personal opinions. There is a very good non technical reason to dislike OOXML, just as there's a very good reason to dislike Mono, and your post that it would be best to download silverlight from Novell's servers to avoid patent hassles simply transfers the undesirability target from Microsoft to Novell, because enforcing users to use Novell software is no better than forcing them to use Microsoft software to avoid legal patent threats from Microsoft itself.
I don't know how many hundreds of people posted here warning you about the dangers of using Mono on Linux, the very FUD patent threat statements that Microsoft actually then later made in order to coax people like you and your bosses into becoming even more enslaved to Microsoft's whims than those who use Windows itself.
You don't seem to see Microsoft is more than likely to use OOXML and Silverlight as clubs to threaten people with later on. That's the real reason why OOXML is dangerous.
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.
I personally do not care enough on that one, just thinking that it's bit stupid that ISO would be saying "here's how you handle dates" and later say "but in a text document, you actually do it differently".
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.
SVG may have its flaws, but at least it was agreed on by different people/orgs. Again, I don't see the point in redefining a new standard (on which nobody except MS has any input) within a new text document standard.
I should add that Math people dislike MathML anyways, and they would much rather use TeX.
I have no opinion on MathML anyway (and do use LaTeX for 99% of what I write, OO.o for the rest), but again if ISO bothers creating a standard for something, it should at least make use of it.
I agree that we have a last resort with ODF "Look it up in OpenOffice", but if "look it up" is good enough, does that not defeat the purpose of documenting ODF in the first place? The idea of a standard was so others could interop without having to sort through 8 to 9 million lines of code. And your average guy that was to generate some ODF or OOXML will not really have the skills to read through all that C++. My guess is that most people would write a file in either OOo or MSO save the file and open it up in an editor to see what the thing looks like and generate with a bunch of print statements what they want. To this crowd "get the source" is probably not very useful.
I agree that even ODF should define everything in the document instead of having it in the code. That being said, the information still exists in a form that is publicly accessible. Any person with enough time and skills can implement those app-specific features. That is not the case with OOXML. MS can (and does) hide the format and the only hope to know how it works is reverse-engineering. This is much harder (and prone to legal trouble depending on how you do it) than looking at the OO.o source code. And *even* if you manage to reverse engineer the format to a point where it works flawlessly with 100% of the files you've seen (unlikely), you're still left with two problems:
1) You'll never know for sure your converter works on strange files you may not have seen (thus opening up to FUD of the kind "do you really *trust* this app with your legal documents")
2) For backward compatibility reasons, it is common to first include features only in the "decoder" for a format and then only support them later on the "encoder" side. That means that there are certain features that could be already in there, but that you will never actually see in a file (i.e. can't reverse engineer) until a new version of MS Office decides to actually generate files that use it.
Overall, it's really the "read the MS Office source code and you'll get it right" that makes OOXML completely unacceptable for me. And it would still be unacceptable no matter how beautiful the other parts are. A standard that nobody except one company has any chance of supporting perfectly is just not a standard. It's a proprietary format that pretends to be open.
You have chosen to introduce a new topic: should it become a standard? And should it be a rubber-stamp standard? Well, I do not know the answers to that. In fact, am of the opinion that most standards in the "big boys" space are tools to club your opponent ("ISO standard: check!").
It's unfortunately becoming a bit of that but it doesn't have to be. I believe most of the IETF and W3C standards are fine with that respect. Same for ISO actually. And personally, I won't mind if the "big boys" club their opponents by using open standards. I do mind if they introduce pseudo-standards that leave enough unknown to make sure they're the only ones being able to actually implement the thing.
Opus: the Swiss army knife of audio codec
- You mentioned that "things" were being taken care of; you did not (in any of your posts here, and I read them all) specify that the scoping was one of them
- You're pulling the classical "I have secret knowledge that proves that I'm right" rhetorical trick. Point me to the revised spec and we can talk.
- You've practically proven, all by yourself, that DIS-29500 isn't at the level of committee draft, much less final ISO submission. One of the basic responsibilities of a technical committee (see, for instance, JEDEC JM-21L) is clearly defining the requirements for conformance and clearing legal rights for those requirements. According to you, that hasn't been done and here we are at the ISO final vote stage. ECMA-376 needs to go back to committee until it's actually ready for prime time.
As a standards maven, I've read the controlling portions (I'm not planning to implement it, so any controlling language hidden in footnotes missed me. As they should.) I'll point out that "optional" has a predefined meaning in standards literature, much as "scope," "shall," "may," and other words that are no more subject to local redefinition than any other legal term. Apparently, the drafters of ECMA-376 had never done any standards work before (the "Scope" section alone makes that very clear) and ECMA made no effort to correct even the most basic flaws.The problems with technical details I'll leave to others.
Again, your "most of that has already been fixed by ECMA" is an indictment, not an excuse.
Lacking <sarcasm> tags,
In theory, OOXML is not a bad standard. In implementation, MS has chosen to tie OOXML to Microsoft products as close as possible. Two major criticism brought out by those who have reviewed it are that (in a standard) OOXML must replicate MS idiosyncracies to work (Spreadsheets must replicate an MS Excel date bug for dates function to work properly), and MS has chosen to write subcomponents from scratch using MS technologies instead of already accepted standards (relying on MS Math standards instead of Math XML).
Well, there's spam egg sausage and spam, that's not got much spam in it.