de lcaza calls OOXML a "Superb Standard" 615
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.'"
Is Miguel speaking as a Microsoft officer? (Score:5, Insightful)
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.
Riiiiiiiiight.... (Score:5, Insightful)
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.
Nope (Score:5, Insightful)
Table like Word95
Only Microsoft has that information. No one else can implement this "superb" standard like MS can.
Does this guy have any credibility left? (Score:5, Insightful)
Re:First things first. (Score:5, Insightful)
It's not too surprising (Score:5, Insightful)
The retarded cousin no one wants to acknowledge (Score:1, Insightful)
At what point are we going to treat him as an adult and tell him he is either out of his freaking mind or so far up the Microsoft orifice that he cant see the light of day anymore?
Mono always left me a nauseous feeling and I tried not to attack Miguel because of his work with GNOME but I think we've past the point where he was harmless and maybe misguided.
Yes Miguel, we all get our technical news from Groklaw because you obviously think that everyone who doesnt agree with you is an FSFer. Check the comments from AROUND the planet this past few weeks from people who've studied the specs and you might be shocked to find out a few things.
Had this been signed by Bill Hilf, I wouldnt have said a word, its part of his job description but Miguel was supposed to be one of 'us'.
Watch as his language starts incorporating more and more of the key phrases that Microsoft execs repeat like a mantra.
A buddy on IRC just mentioned that Miguel must have been very unpopular as a kid and is now trying to fit in with the older, cool kids. And whenever that situation used to happen in school, the dweebs who try to 'fit' in usually come across as ackward, clumsy and borderline retarded.
Just like Mig.
And forget folks, Novell is the best distro out there because they have patent protection.
F U Miguel.
Sincerely,
Lyle Howard Seave
Re:Another non-story posted by kdawson (Score:2, Insightful)
Re:Does this guy have any credibility left? (Score:2, Insightful)
Re:Nope (Score:1, Insightful)
I'm willing to believe that Office Open XML might in fact be a better format than ODF, because I've never actually taken the time to look at ODF.
I can't help but wonder if what he really meant is that if you remove all the backwards compatibility elements, OOX becomes a superior format than ODF. Personally I think Microsoft should remove all elements like that and resubmit their format. Then they might have a spec that really could be better than ODF.
Don't support ODF just because it's not the Microsoft format. Unless you've actually looked at both specs, there's no way you can say one is better than the editor.
And since you're just repeating classic anti-OOX FUD, I can be pretty sure you haven't.
Technical proficiency more common than wisdom. (Score:4, Insightful)
One can disagree with someone without losing sight of their strengths, and respect someone's strengths without losing sight of their weaknesses. In this case: just because someone is technically proficient, that doesn't mean he's wise.
I don't consider depending on standards that Microsoft (or any company) controls "wise", whether that's OOXML, CIL, or Silverlight. Miguel's score on the subject is public knowledge.
Comment removed (Score:5, Insightful)
RTFL - Submitter is a Jackass (Score:5, Insightful)
(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.
That statement proves it: (Score:2, Insightful)
OOXML is objectively horrible/unworkable as a "standard" and if Icaza's attitude is reflective of (or impacts) Novell's then IMO what little FOSS credibility and good standing Novell had will have vanished.
It seems Mono has become a non-starter and he needs another way to grab attention.
Re:RTFL - Submitter is a Jackass (Score:4, Insightful)
I would rather wait another year or two for tools that implement a good spec than get MORE tools that implement Word's fundamentally broken document model. I would rather work in raw HTML 1.0 using ED than try and write anything sophisticated in a program like Word (or Pages, for that matter, which uses the same structure). Unfortunately since I work with people who use these formats, I must adapt.
Re:Always been a MS Shill (Score:5, Insightful)
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!
Re:Nope (Score:5, Insightful)
That's the completely wrong way to specify it. A "standard" that says things like "tables like Word 95" is worthless, just what's that supposed to mean anyway? If you want to standarize a method of brewing coffee you don't say things like "The way Bill Gates makes it", you specify the exact procedure to be followed. If the behavior can't be fully determined based on the standard, then it's crap.
Things like that shouldn't be in the standard in the first place. If you're opening a Word95 document and saving in another, then to preserve the formatting you don't say it's "like in Word95", you specify the list of attributes to achieve the same effect: padding, alignment, margins, etc.
Really? (Score:4, Insightful)
And yet his blog sounds like it's written by someone very young. Consider this from his answer to a post on his site:
"You do not have to pay anyone any money. Duh.
Nobody said so. Either English is not your first language, or your reading
and comprehension skills are busted.
Miguel."
Is that what passes for civility and adult behavior at Novell from a VP? I must say I'm a bit surprised.
Novell is distributing concealed patent landmines (Score:2, Insightful)
Thanks, Miguel. You make it very clear: all code downloaded from Novell must now be regarded as (Microsoft) patent encumbered.
I _want_ moonlight to succeed. (Score:2, Insightful)
Re:Nope (Score:5, Insightful)
The problem is that OOXML defines a bunch of tags for 'backwards compatibility', but doesn't define what they do. To say that 'ODF fanboys and FSF-sponsored trolls don't care about that sort of thing' is insulting. Lots of people, including FSF members, have spent thousands and thousands of hours trying to reverse-engineer Microsoft binary formats. A document specifying this behavior would be universally welcomed, by both the FSF and 'ODF fanboys', because it would then be possible to write high-fidelity converters between old MS formats and ODF (or from MS binary formats to a non-legacy subset of OOXML, for that matter).
Having a bunch of tags with no definition as to what they do is not an ingredient of a good standard. If you wanted to define a bunch of custom tags, it could just as easily be done as an extension to ODF, which, if it was well-defined, ISO and the open source community would surely have no problem with. Having a international standard where significant parts of it are 'depreciated', is itself rather bizarre. If the backwards-compatibility binary-format tags are depreciated, why include them in the international standard?
Re:Nope (Score:5, Insightful)
Re:OOXML. (Score:5, Insightful)
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.
Re:Nope (Score:3, Insightful)
Patent Pledge [microsoft.com]
(This Post is Preview Button Approved!)
Re:That statement proves it: (Score:5, Insightful)
Yeah, starting with an ad hominem makes me want to take your arguments seriously.
Re:Nope (Score:2, Insightful)
*REQUIRED* for backwards compatibility? What's wrong with converting them to standard markup instead of hacking in undocumented things like that? And besides, you do realize that that means that every word processor from now on has to know and care how ancient word processors once worked, simply because the newly converted documents are really old documents in a shiny OOXML wrapper.
If they really care so much about backwards compatibility, shouldn't they bother to document how these things work? You know, so that everyone can use them? Oh, right, they don't want anyone else to use them...
> If the ODF fanboys and FSF-sponsored trolls don't care about that sort of thing, I reckon they can safely ignore them and not implement them. But I guess that's no fun because it eliminates one of the fav memes being thrown around to prove that the standard is somehow deficient.
Oooh! I had no idea the FSF was sponsoring me! Where do I get a paycheck? Oh, right, I don't. It's really clever to argue like that, too, when a "rogue" Microsoft employee was caught trying to bribe Microsoft partners to join their NBs and vote in the ISO. True, we can suppose that that one employee stepped over a line, but you do realize just how many Microsoft partners have jumped out of the woodwork to vote on this, right?
If "we" are the "trolls", why are the OOXML supporters the ones with financial and business incentives to do things that aren't sensible in terms of technology or standards? And I say "we" loosely because I'm just some lone geek nobody who knows that he will have to support the crap that is in MS Office at work and hates it because of that. I'm an absolute nobody that no one in either camp has heard of, but I gather and submit most of the ODF articles here, including Slashdot story on those back compatibility hacks that you're trying to debunk (which was my favorite, BTW).
> Complete with "OMFG the 1.0 implementation as a BUG!!! Therefore the standard SUCKS!!!"
Funny that: why is it only one side that brings up technical arguments and actual data on what actually works and what doesn't, while the other side calls people names? Oh well, I really hope you never learn that lesson. If PR actually had a clue, they might be more dangerous in spreading FUD to geeks. Though I suspect that you were just trolling me and aren't actually paid by anyone, I figured it was worth posting for the people who are actually interested in this information.
Well, you see, the reason I hate all those old bugs is because Microsoft shows no interest in fixing them. ODF is going through revisions to actually *fix* all of its problems. OOXML? They have tons of people spouting "it's not THAT bit a deal! calm down!" and NOBODY actually fixing the damn thing. Hint: if you actually *fix* the problems identified in the NBs' votes, the "no with comments" votes would become yes votes and you wouldn't need to cram the committees full of Microsoft Certified Gold Partners.
Oh, and while I already explained why "just don't implement" them isn't an option (those legacy tags NEVER go away!) I might as well point out that Microsoft does a really crappy job on backwards compatibility in Office 2007 [slideshare.net]. You know, their flagship product?
Might want to know about THAT before you go shooting your mouth off... Or not. Frankly, if you don't, it just makes things a lot easier for me.
Re:Nope (Score:2, Insightful)
I have contributed code to OpenOffice.org and Abiword (not much, but a little). Mostly however my focus has been on word processor conversion software (not spreadsheets though, granted)
The formulas you reverse engineered from previous versions of XLS were unfortunately riddled with bugs (this isn't your fault -- these bugs came from Microsoft who were sometimes copying IBM!). See the problems in the CEILING function for example, and how with proper design OpenFormula has been able to emulate legacy bugs while providing a clean slate for the future.
I note that in your post you don't disagree with the cryptic naming conventions of OOXML (who could?), but you apparently think that ODF doesn't specify existing standards(?). Could you give some examples please of what you think?
ODF builds upon XML, Unicode, XSLT, XHTML, XForms, SVG. Because these are existing standards you can choose from many vendors, and you can find a lot of developers skilled in this tech (well, perhaps not XForms)
OOXML builds upon XML, Unicode ... then it's all VML, DrawingML, and so on. The backwards compatibility isn't actually defined in OOXML (eg, autoSpaceLikeWord95 for east asian languages isn't defined)
I'm not a zealot and personally I think OOXML has a lot of good features that should be merged into ODF.
And please Miguel, I didn't insult you, so lets not use the "armchair general" insults. We can stick to the technical arguments :)
wrong use case (Score:5, Insightful)
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.
Re:Nope (Score:1, Insightful)
Microsoft however cannot afford to throw away almost two decades of compatibility, least of all compatibility with versions of Office that still have hundreds of millions of users. Nor are they required to tell you or anyone else how Word 95 rendered a table.
BTW, it's hilarious that someone who uses terms like "the open source community" is happy to suggest that Microsoft can modify ODF to support its own legacy customers. I can almost hear the cries of "embrace extend extinguish" coming out of that.
Re:Always been a MS Shill (Score:2, Insightful)
In other words...
No boom today. Boom tomorrow. Always boom tomorrow...
Re:Always been a MS Shill (Score:4, Insightful)
When the time and market is right, Redmond will push a
Project vomit while you may, if it keeps gives Redmond life beyond Vesta [wikipedia.org], then Miguel may be doing us all a little favor.
Re:Nope (Score:3, Insightful)
No, I'm not missing the point. Microsoft can do whatever tricks they want to keep their vendor lock-in. That is the way the captialist system works, and under those rules it is allowed. Their rights to do that end at the point where they submit an international standard. At that point, it must be open and completely independently reproducible. If they can't accept those terms, then don't submit it as an ISO standard.
I was trying hard to word my reply in such a way as to NOT invoke cries of "embrace extend extinguish". Again, the bottom line is standards of documentation and openness befitting an international standard. If Microsoft chose to document their proprietary binary formats in the form of an extension to ODF, and (especially!) if they submitted the resulting document as a well-formed standard to ISO, then I am sure that 99% of the open source community would welcome it. Better still, though, would be a converter from the binary into a non-legacy format. That almost certainly isn't possible without loss of fidelity, but most people could live with that. Note that if you are going to use any non-Microsoft software that uses OOXML, then you are not going to get a lossless conversion anyway, because no one other than Microsoft will ever be able to implement the depreciated and not-defined backwards-compatibility tags!
Re:Nope (Score:3, Insightful)
Are you serious?
Browsers lay out HTML differently from one another.
Hell, K-Office and OO.o lay out ODF differently from one another.
Hell, frikkin plain text editors lay out ASCII text differently from one another (some use \r\n (or \n\r), others use \n, and others use \r for line-endings).
Same goes for any data-processing format you can think of.
These aren't print-layout formats like PDF. Content is the primary issue, "lay out" is a secondary concern.
Re:Try #2 (Score:3, Insightful)
Got a reference for that? This is the first time I hear that the bit field was for encapsulating VBA and I do not see that referenced.
Miguel
Re:Nope (Score:5, Insightful)
I didn't ignore it at all. I'm glad this is something that the EMCA is eventually going to resolve. My comment is solely as to why it's important that it is documented, and why your statement that "it's optional" is hardly a solution. It may be optional, but it's important to implement to give users the expected level of interoperability, and this is why many people have expressed concerns about the standard as Microsoft has originally submitted it.
I think you and I can agree that the standardization organizations are doing a good job of ensuring that the standard is itself up-to-standard. But I can't subscribe to your opinion that nobody has any right to complain about the standard as it was submitted by Microsoft, just because it will (hopefully) eventually be fixed. I can appreciate that these faults will be fixed, but that doesn't mean that I (or anyone else) have no right to comment on its current state.
So they say, and for now, but I've been a Microsoft watcher for more than long enough to say that I'll believe it when I see it. And "trying not to" doesn't mean "won't" -- I'd be significantly happier if Microsoft were to say "we won't use these legacy tags ever", and then kept their word (forever -- in which case they would be unnecessary to have in the standard, as I imagine nobody else is going to need to use them if MS itself isn't going to use them).
Yaz.
Re:Nope (Score:3, Insightful)
Re:Nope (Score:1, Insightful)
You do know that you sound like a 12-year-old, don't you?
A couple of points, just because I feel like arguing:
And yes, 6000 pages is a legitimate debating point. That's just plain ridiculous.
Re:OOXML. (Score:5, Insightful)
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
Re:Nope (Score:1, Insightful)
Not to mention that the so-called patent pledge is joke anyway: any company that implements the standard pretty much forfeits its ability to sue Microsoft, even on unrelated products. So unlike Sun's ODF license... And, as I noted back then, it's a promise to you, not a redistributable license. There's nothing in there that says Microsoft won't sue your customers. There's no guarantee that they won't pull it either.
Standard, to anybody but you, means you can pick it up, as well as the standards it references, and implement the thing and expect that it interoperates with the other implementations out there. OOXML is no such thing. It might be superb (the 1900 is a leap year thing, 1-2-3 bug or not, and the profusion of text styles formats suggests otherwise tho). I'm sure it's much easier than ODF to add to an application that's already based on the the binary Microsoft file formats, such as Gnumeric. But it's not a standard. End of story.
And will you please stop ending your comments with ad hominems like a spoiled brat!
I'm not asking you what's the status on those C/C++ extensions allowing the seamless integration with
D'oh!
Re:Good morning, people. (Score:1, Insightful)
Plays well with others (Score:3, Insightful)
And why do you suppose this is? And who started politicising it?
Microsoft pulled out of the OASIS ODF working group during the creation of ODF. Instead of working for a standard, they decided to go their own way. As the giant in the industry, they have the clout to do so. When it seemed they didn't have a sure vote for fast-track of their own single-vendor standard, they are the ones who gamed the system, strongly urging their close partners in member countries to join and vote in the ISO process.
Microsoft has arrogantly assumed the industry will follow them. It is this arrogance, and a good memory, that has produced this resistance to their market push. Microsoft has twisted standards to funnel customers their way (Kerberos, IMAP/MAPI, etc). They have shown they have no interest in playing well with others, which is the entire point of a standard.
As far as Jody hacking in support to import cells from a spreadsheet: good for him. But how is the display and print and graph fidelity? Will it look the same as it does when printed from Microsoft Office? Will cell styles look the same on-screen? Or does Gnumeric only do about as well as it does with
Support for reading in cell data is one thing. For that, the OOXML-published spec is a godsend. But that isn't the real test-case here. ODF is designed for disparate word processors to operate on the same files with equal fidelity. It's designed with internationalization in mind, including dates and times (something at which I hear OOXML isn't so great, though maybe I'm just swilling the FUD-aid.)
If OOXML is such an excellent spec, then Novell should be able to create a filter that will be able to import and export moderately-complex OOXML files that look almost identical (in print and on screen) in MS-Office and some other non-Microsoft product. (Sorry about that sentence.) If it's as good as you claim, we should see this product before ISO voting begins in February. And if it is to make a good standard, I should be able to download the filter from anywhere, hack it, and redistribute it without fear of patent litigation.
Do you imagine this is doable? Are you willing to back up your claims with some promises (not as a Novell employee, but as Miguel the hacker)?
Actually, I don't think even Microsoft can claim I will be able to download it, hack it, and redistribute it without permission from Microsoft. And that right there is reason enough for me to fight it.
Re:Always been a MS Shill (Score:5, Insightful)
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.
Again, once more with feeling (Score:5, Insightful)
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.
Re:Nope (Score:3, Insightful)
Table like Word95
Re:Always been a MS Shill (Score:2, Insightful)
Re:That statement proves it: (Score:4, Insightful)
Isn't it obvious by this point that Microsoft wants to take over Linux and is trying to do this via Novell (SuSE) and threatened patent litigation? Similarly, Mono is an attempt to draw Linux (and even Macs) into trying to compete with the Windows O/S in a game stacked in Microsoft's favour. OOXML is [b]demonstrably[/b] a hideous mess. A person in this position cannot be sincerely mistaken in thinking that it's a good format. They have to be lying.
Re:OOXML. (Score:5, Insightful)
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.
Re:Nope (Score:5, Insightful)
If a major Office competitor implemented OOXML but ignored the backwards compatibility parts, Microsoft would be sure to use those when saving OOXML files in MSOffice just to make sure they don't look right in the competitor's office suite. Which part of that did you fail to grok?
The BSI also disagree (Score:3, Insightful)
Well written and critiqued from the Granddaddy of all Standards Organisations. They have no axe to grind whatsoever, now someone tell me THAT's FUD.
7000 pages says its fundamentally wrong (Score:3, Insightful)
I think it will be next to impossible for ANYONE except Microsoft to implement OOXML. Which is just the way they like it.
Re:Always been a MS Shill (Score:2, Insightful)
I wonder why the community keeps listening to the sold out crap he has to say. If we treted him like what he is -- a troll and a sell out -- and ignored him like we ignore the retarded Windows Vista using Microsoft trusting neighbour, he wouldn't have the power he has and he couldn't hurt the libre software community as he's doing.
Re:Nope (Score:1, Insightful)
>>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.
Only because the vote BARELY failed, even though Microsoft bribed partners to vote yes, and officials from corrupt third world countries who NEVER before has shown any interest in the standard process suddenly shows up to vote yes.
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).
No thank you, I prefer to devote my programmer hours to REAL standards and open source projects, not your divide and conquer bullshit.
Re:deficiency (Score:2, Insightful)
The point is that the complete read-write implementation of OOXML, interoperable with Office, is clearly impossible in practice without access to the legacy Office codebase, and even a partial implementation is far harder than it has any right to be, proven by the example of ODF which is demonstrably easier. In fact, a partial implementation may not even be realistically possible because of all the interdependencies which ODF has fewer of. What is a standard if it is not interoperable; not implementable? What's the point of making it a standard if it's not going to be fully implemented by anyone but Microsoft?
Re:Try #2 (Score:2, Insightful)
Oh, I am so sick and fucking tired of hearing this. Should we not buy Intel products because they are a convicted monopolist in Japan? Should we never buy anything Samsung because they were convicted of price fixing (along with other major DRAM manufacturers)?
In 2030 we're still going to be hearing this bullshit line of reasoning. Somehow you believe that we should hold Microsoft to a different standard, and this is the justification you use.
The very phrase "convicted monopolist" implies that there's something illegal about having a monopoly.
But, hey, this is Slashdot. Ever since Miguel stopped drinking the Flavor-Aid, he's been pissed on by the community. Miguel has done more to enable FOSS on the desktop than pretty much anyone here. You may not like Mono, but that doesn't mean that it's not a completely legitimate and valuable project.
Personally, I don't generally agree with Miguel's assertion that OOXML is a "superb" standard.
OOXML has a lot of problems, not the least of which is the fact that it was generally designed as a drop-in replacement for Microsoft's old formats. That's understandable, but it also means that the standard is much less clean than something that was designed from the ground-up without any legacy baggage.
But, let's be real. ODF isn't a great standard, either. It's biggest problem is that it is incomplete, but it also suffers from the same problem as OOXML (except that it's designed around OOo rather than Office).
ODF is getting better through things like the OpenFormula specification. But OOXML is getting better too.
There's so much crap around OOXML. Whatever you think about it, it's still a million times better than the undocumented binary formats that it replaced.
Miguel is right about the FUD storm. You people probably hate ReactOS too, just because it dared to admit that maybe Microsoft got something right.
Re:Nope (Score:5, Insightful)
Re:OOXML. (Score:3, Insightful)
Re:Nope (Score:3, Insightful)
a) Specify what exactly the tag means, not just "like word95", but put down in words what exactly that was.
b) Mark that particular tag as deprecated, meaning new implementations should *read* it correctly, but never *write* that particular tag, unless it was already there in an opened document.
Microsoft did neither.
Re:Does this guy have any credibility left? (Score:5, Insightful)
I'm sorry, and I do not mean to detract from his significant accomplishments, but I have to agree that this episode speaks poorly to Mr. de Icaza's credibility. The deficiencies of OOXML are severe, well-known, and unfixable. Not only is it not a "superb standard," but it is not something that could correctly be described as a "standard" at all, because no one, including Microsoft, could implement it correctly, and no one including Microsoft even claims to be able to do so. ODF, for whatever problems it might have, is implemented by and/or for all major office suites, including (via a third-party plugin) Microsoft's own, and it is a published ISO and IEC standard.
I don't know whether Mr. de Icaza simply cannot see this, has chosen not to see this, or has not really bothered to seriously examine it before making such an authoritative pronouncement. But any of these problems speaks poorly to his credibility, and bodes poorly for his continued status as a spokesperson for the free software community. My advice to him would be to continue to write great code, but try to refrain from public comment about things he for whatever reason clearly does not understand.
Re:OOXML. (Score:2, Insightful)
That Lotus never thought of spreadsheets dealing with dates beyond the nearest economic horizons, need not to be any of our concerns. To the contrary, an ISO standard should instead stick to well known established sane standards. Leap year bugs, Y2K issues and what have you, simply does not meet that specification.
Appeal to secret knowlege (Score:5, Insightful)
- 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.
Arm twisting (Score:3, Insightful)
You open every meeting with a statement of the organization's patent policy. You make participation contingent on agreement with the policy, which includes an affirmative obligation to identify any known blocking IP. When a submission comes from a company, you require a binding letter from the company covering all IP they have covering that submission. You do this for every single point in the draft specification. Anything that doesn't get IP clearance doesn't make it into the draft.
Microsoft could have simply issued a blanket IP clearance for ECMA-376 as passed. Any additions after that point might not be covered, but anything sticking to ECMA-376 as submitted would have been. That's a very common industry practice; in a normal standards body that would have been required. They didn't. Now, I'm a believer in the law of intended consequences, which is similar to "intention" in common law: when a rational party goes out of their way to do something that has predictable consequences, it's reasonable to conclude that they intended those consequences.
Microsoft (and Microsoft Legal) isn't run by idiots. Logic follows.
Re:Always been a MS Shill (Score:3, Insightful)
Perhaps, as it currently stands. The problem with buying into any MS "standards" is that they morph over time to suit their requirements, while either not including the new bits into the open standard, or publishing them much later to give themselves a head start on using the new features. That way all other users of the "standard" will forever play feature catch-up.
In concrete terms, while it may appear that they currently exhaustively expose all object model entities in the file format spec, nothing prevents them from adding extensions along the line of base64-encoded-and-encrypted-data-storing-juicy-new-Word-functionality-that-nobody-else-can-read. A fat lot of good that does you.
Re:That statement proves it: (Score:3, Insightful)
And this makes you so angry that you hope ODF will fail?
The function is called ceiling. The mathematical definition is here: http://mathworld.wolfram.com/CeilingFunction.html [wolfram.com]
ODF is correct, OOXML is wrong. Nuff said.
Re:OOXML. (Score:2, Insightful)
As many people here and on many other sites have already pointed out, these "backwards compatibility" measures are impossible to implement for anyone except MSFT and those who were able to see the actual code under some chain-linked NDA.
Let's say, OOXML gets implemented as a standard and every word-processing application implements it, what keeps MSFT from just applying a little patch to MS Office to make heavy use of these backwards compat tags? Since the majority of users are still using MS Office this would have dramatic consequences for those who don't
If, say, in fifty years Linux has taken over the world, MSFT is in smithereens because someone decided to revise the antitrust case and MS Office is out of use for several years, nobody will be able to read those OOXML documents anymore, unless MSFT releases the complete specifications.
Therefore OOXML shouldn't be accepted as an ISO standard, because it can only be implemented completely by one party. You shouldn't even call it standard, if it can't be ensured that future generations will be able to read those documents without having to find an x86 Windows PC with MS Office installed!
On a side-note: If MSFT had really really been interested in providing backwards compatibility, they would have just written an application/Office plugin that converted old documents into OOXML without having to use some obfuscated tags. Instead they just squeezed these formatting instructions into their new standard to ensure a steady flow of money from people forced to use MS Office in order to view their documents.
Re:no way it's really him (Score:2, Insightful)
No, I didn't say he were my friend. I said I knew him in person (some improvements needed in your reading skills, I think). And from knowing him and what he pretends from the mono project I couldn't say he is a microsoft fanboy
>Well, he is trying to lure people into using more all-Microsoft technologies, just waiting for the patent trap to close.
Actually, he intends to liberate all those thousands of microsoft based applications and take them to linux. I found this particularly important because many linux fanboys forgot that there are many, many (I mean, MANY) home made business applications (most of them made using microsoft tools) that are a big obstacle when considering the migration to linux desktops. I know this well because I was part of some big studies for massive migrations to linux desktops
>This OOXML-preaching is the best evidence there is.
Did you read it? I've found over the last five years that most linux and open source fanboys tend to over-react to the headlines BEFORE even reading anything. And, actually, one interesting think about any conspiracy theory is that ANY counter argument is actually turned upside down to fit (and actually confirm) the theory.
In any case, life continues. Criticisms will continue but hopefully, Mono project will continue and will bring an important tool to the OPEN SOURCE world and, most important, will bring MILLIONS of business application programmers to linux. Time will tell.
Re:Always been a MS Shill (Score:5, Insightful)
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).
Re:Gnumeric dev says OOXML easier than ODF (Score:3, Insightful)
Re:That statement proves it: (Score:3, Insightful)
If(TODAY() = '11/02/2008', "Due Today!", "Not Due Yet")
Which, I believe, you can do with most anything. A random number with no relation to how people perceive dates is not useful in a spreadsheet. Just because Excel does it doesn't make it right, and doesn't make it something we should continue to do. You don't still have a kick-start on your car, do you?
Re:That statement proves it: (Score:3, Insightful)