Slashdot Mirror
ODF Alliance Warns Governments About Office 2007 ODF Support
omz writes "The ODF Alliance has prepared a Fact Sheet for governments and others interested in how Microsoft's SP2 for Office 2007 handles ODF. The report revealed 'serious shortcomings that, left unaddressed, would break the open standards based interoperability that the marketplace, especially governments, is demanding.'"
Malice, or simple incompetence? Given Microsoft's track record, I can believe either one.
I know there are a lot of smart people working for Microsoft. But somehow it's as if there's a reverse gestalt phenomenon going on in their company - the whole is less than the sum of the parts.
#DeleteChrome
Just wondering, is Microsoft warning governments about OpenOffice's .DOC support?
I know Microsoft is being its usual self, but perhaps the ODF alliance should promoting a certification program and a compliance logo to raise the quality of interoperability of ALL ODF based applications.
If you write a standard and clamor to get it adopted by law, don't leave Redmond-sized holes in it. Someone might just try to drive a Microsoft through it.
Doesn't seems strange to you that only Microsoft handle it very differently?
L.
Although nobody is really surprised that Microsoft has made their software comply with the letter of the law and not the spirit, is this really a big issue? If, as the summary says, the marketplace is demanding a grand interoperability between software products, then we might see the rapid uptake of OOO in the near future. Failing that, if nobody switches, then the market has spoken loud and clear, Nobody cares.
Honestly, the single most productive thing you could do to ensure the rapid uptake of open standards would be to make openoffice.org an amazing product. Put all of your time and effort into making it clearly superior, and at that point everyone will use an ODF by default.
Shouldn't the file be an ODF format?
You're not trying to let them edit it. You're trying to influence them with a fixed document. So a display-only format is fine.
Further: You're trying to influence people who are NOT YET onboard with ODF. So you want a format that is viewable by as wide an audience as possible while displaying conveniently in an easy-on-the-eyes form. Right now that's PDF.
Putting it out in ODF means it's only viewable by people who already have ODF installed. That's mainly the people who are already onboard and don't need to be convinced. So it would be a case of "preaching to the choir" rather than "converting the heathen". Useful for giving your evangelists more talking points perhaps. But not all that useful for the purpose intended.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Um, the difference is Office 2007 formats aren't a standard. OOXML is, but even MS's own implementation doesn't match up to the specs.
ODF on the other hand has an open implementation, free source code, open specs, royalty free, etc.
ODF alliance warning about sub-par ODF support on Office 2007 which ODF is totally open, is different than MS warning about not supporting their closed, undocumented format.
Taxation is legalized theft, no more, no less.
Already done, spreadsheet formulas are being specifically addressed in ODF 1.2. But in 1.1 there was already a set of conventions for handling formulas, and Microsoft were the only ones out of all the ODF 1.1-using applications that couldn't follow those conventions. In fact their implementation even specifically violated one of the bits that was in the ODF 1.1 spec: the spec calls for cell names to be enclosed in square brackets, while Microsoft's implementation omits the brackets. Then you have just plain malicious stuff like actively removing formula information that's present. Even if you can't parse the formulas, XML makes it easy to preserve what was there. Every other implementation behaves that way: if they can't understand the formulas at least they leave them intact for applications that do understand them. Microsoft's is the only implementation that deliberately removes formulas from the spreadsheet.
What annoys me most about Microsoft's pseudo-support is that it had to be deliberate. They had to actually expend additional effort to be this incompatible. If they'd simply been lazy and taken the easiest way out, they would've been far more compatible with everybody else than they ended up being.
If you can believe Microsoft, they're not the only ones. Lots of ODF implementations have interoperability issues.
Doug Mahugh at MSFT has been blogging about this: http://blogs.msdn.com/dmahugh/archive/2009/05/09/1-2-1.aspx
and
http://blogs.msdn.com/dmahugh/archive/2009/05/13/tracked-changes.aspx
That's a very insightful, proactive suggestion. Why bitch about the usual MS attitudes if you can provide a constructive path ahead, right?
Actually, it shouldn't be all that hard (but, it may well be tedious work) to put together a document that includes samples of *all* features of the spreadsheet / text editor / drawing / presentation document.
Providing verification is probably a bigger challenge. I wonder if it could be done as macros in any of the ODF-supporting suites, or if that's akin to an SOD violation?
"Good news, everyone!"
If anyone is interested in specifically what is "broken"(read: incompatible with OpenOffice.org 3.0)... which I doubt... here is some very good information detailing which decisions were made in implementing ODF and why they were made:
http://blogs.msdn.com/dmahugh/default.aspx
The last couple blog posts should be what everyone is looking for.
Beyond this, Microsoft is simply implementing ODF 1.1 because ODF 1.2 is not done yet. If Microsoft is going to support a standard, they will support the standard not the most popular implementation's interpretation of the standard.
Microsoft followed the ODF specification to the letter
Are you paid to astroturf? Thy did not follow it to the letter and they ignored the reference implementations and if they tested for compatibility like everyone else they did so to make sure things would not work. Given their market share, that's criminal.
Pretty much, yes. Bear in mind that Microsoft already has code that does handle the spreadsheet formulas correctly. The plug-in that Microsoft itself commissioned and that they own the code for not only preserves the formulas, it correctly parses and interprets them so that cells get recalculated properly as data changes and it correctly writes changed formulas back out. All Microsoft had to do was to not do all the work a second time. And even if they had re-done the work, the XML parser automatically populates the DOM with the formula strings and the internal implementation in Excel already can preserve arbitrary metadata from external formats even when it can't interpret it. All they'd've had to do is not touch things the user hadn't edited and the preservation would've happened automatically. I do this all the time when dealing with XML code, to the point where I have to make a deliberate effort not to write data-preserving code.
The others are open source projects, and can look at each other's code. MS can't, or they'd have to open source their code.
This is a completely misleading statement and totally misses the point. Well done!
You don't need to look at the source code to see what other products do. You just need to look at the ODF files they produce. Indeed, given the licenses of the products that implement ODF, you can obtain the copies you need for testing FOR FREE.
Similarly, while your legal department might bar you from reading competitors code for fear of copyright co-mingling, there is nothing to stop you employing a third party to go look on your behalf and write a report on what was done. So you can have your cake and eat it.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
Or they could ask the proper author (I don't know who owns the copyright on that particular portion of OOo) for a license to do so. I betcha that someone interested enough in OOo's future to write a save/load algorithm for it would let Microsoft use it (in part or in whole) for Office. Complete compatibility between the two program suites would work heavily in OOo's favor, for reasons that seem obvious (to me) and that I won't go into to avoid creating a tl;dr situation.
Maybe if someone out there knows anyone (or is on) the OOo team drops the idea of a public offer to give Microsoft a special license to their already working code, some traction could be gained, or at least some light could be shed on the willingness of Microsoft to rectify the situation. I hope they are honestly willing to achieve cross-compatibility, but my guess is that that is likely too optimistic.
Watch what happens if openoffice makes any kind of real dent in office's market share. It'll be just like the RIAA going after downloaders...
Gentlemen! You can't fight in here, this is the war room!
If the standard is strict like other open standards, and they still fail to be compatiable[sic], I wouldn't "apologize" for them.
Please. The standard is just fine for any honest company trying to make a product that works. It just wasn't written as an ironclad legal contract to keep MS from playing dumb and intentionally breaking compatibility.
Actually, if you read another comment on this article, you'd see that other applications actually didn't handle the standard all that well like you claim.
Other comments? I don't have to because I actually bothered to read about the topic before discussing it. There is one other compatibility problem among the programs tested and it is because one of the programs is using the newer version of the spec. Saving from OO as ODF 1.1 is compatible. Thats completely different from being incompatible with every other program implementing the same version of the spec.
"Free code". You do realize that many of those "free" code samples are licensed that would require Microsoft to open source Office or portions of Office.
Please educate yourself before trying to argue. There is a working plug-in for MSOffice licensed under the BSD license so MS can simply copy and paste if they want. They've done it before with BSD code.
This is about a standard that was weak and failed to state everything clearly.
Bullcrap. This is about a standard that is fine for any honest company and about one company intentionally trying to break things to harm competition.
Asking any company to follow it is insane.
Yeah, except nobody else had any real problems including small hobbyist groups. Believing your crap is insane. In fact, your position is so unbelievable, I strongly suspect you're an astroturfer. You have a history of all of 13 comments, almost all of which are defending Microsoft. You're either a paid shill or you really drank to kool-aid.
The whole reason they are doing the ODF thing is pressure from the EU with regards to anti-trust. Part of that pressure is that "You have to do it according to the standard."
So you're arguing that MS's lawyers are completely incompetent and didn't know that being incompatible was a violation of antirust law and that antitrust law doesn't mention anything about standards compliance? I think that's a naive.
All the other ODF stuff I've seen is open source. As with most open source, they borrow heavily form other open source projects. In the case of ODF, the modus operandi seems to be "Do what Open Office does." Ok that's great, but again not an option for MS. They can't take OOs code...
They already own BSD licensed code that works on MS Office. Next argument please!
Basically the ODF spec isn't clear and precise.
But it's clear an precise enough that it worked for everyone else and there are multiple working open source implementations, one of which they can literally copy and paste from and which they helped fund the creation of and probably have full rights to it even if it wasn't BSD licensed. Sorry, that argument doesn't fly either.
Then there are cases where the popular ODF implementations aren't compliant with the spec.
Example please.
More or less it looks like the ODF alliance needs to shut up, and write a better standard.
They already did. MS doesn't want a standard for interoperability. They are simply looking for any way they can be compliant but still be incompatible.
Everything has to be specified precisely.
Not really, that's what reference implementations are for. If you have any doubt about how to handle this, see the reference implementations and do it that way.
The only argument you made that has any legs is the first one regarding compliance with the spec, but only if you assume ignorance of the law (I assume you perhaps aren't that familiar with antitrust law). I assure you, while it may at times appear that all of MS's lawyers have never heard of antitrust law, that is not the case in reality.
There's a lot more than 2 implementations. Besides OpenOffice and MS Office there's AbiWord, KOffice, Google Docs, WordPerfect Office X4, IBM's Lotus Symphony, the Sun ODF plug-in for MS Word and the BSD-licensed ODF plug-in for Word that Microsoft funded and hosted on SourceForge. That last is important, BTW. Not only is Office 2007's implementation of ODF incompatible with OpenOffice, it's incompatible with Microsoft's own other implementation of ODF.
Microsoft did what they had to do to break compatibility. They must have been laughing themselves silly when they realised that other users of ODF had left the door open for them to both break compatibility AND claim compliance.
Don't kid yourself, they may have been very happy to claim that they are compliant, but compliance was not the aim. Breaking compatibility was the primary purpose.
No, it just means that there are other implementations that behave similarly to OpenOffice.org.
Demanding that Microsoft implements the ambiguous / not standard parts of OO.o's ODF in the same way that OO.o does is sort of like demanding that Mozilla implements all the ambiguous / not standard parts of MS's HTML/CSS rendering implementation. Or demanding that Apple modify OS X's kernel so it implements the same syscalls as Linux instead of implementing POSIX, because Linux is the most popular operating system used to run programs that target POSIX.
Of course, with ODF, 1+2=1. ODF 1.1 is broken, and there is nothing that can be done to make a fully standards-compliant ODF 1.1 implementation without filling in the gaps somehow. Apparently, OO.o 1-2 uses a nonstandard forumla implementation and OO.o 3 writes to the not yet finished ODF 1.2 standard.
Absolute nonsense and petty attempt to justify malice.
There IS a standard which was NOT completely respected by Microsoft.
However, we arent talking about that part: in this instance, the only claim you can make against the standard is its failing to provide formula specification for spreadsheets.
This is something that MS and all implementors can be asumed to have known BEFORE starting to implement the standard. All other implementations, INCLUDING the BSD licensed one by a microsoft contractor, chose INTEROPERABILITY, Microsoft in their second and internally executed implementation, chose to BREAK IT, and thus it DOES NOT interperate with anything at all.
You can only claim compliance, but you cannot provide evidence that this choices werent taken with WRONGFUL WILL (them being the evil fuckers theyve always been). It was an ill willed decision, that is obvious and the evidence is that, hey, they DONT interoperate at all when they COULD and actually DID interoperate in OTHER implementations.
Damn... how much do they pay for astroturfing?
NO SIG
Before you judge on this issue, it helps to read comments by various involved parts - those raising the issue to attention, MS people who have implemented ODF, and informed commenters outside this dispute. So, here's a bunch of links to start with.
First of all, a series of blog post by OASIS' Rob Weir (who's criticizing MSOffice) and Microsoft's Doug Mahugh (who's defending it) that evolved into a kind of a public discussion on the issue. Here they are in chronological / meaningful reading order:
http://www.robweir.com/blog/2009/05/update-on-odf-spreadsheet.html
http://blogs.msdn.com/dmahugh/archive/2009/05/05/odf-spreadsheet-interoperability.aspx
http://www.robweir.com/blog/2009/05/follow-up-on-excel-2007-sp2s-odf.html
http://blogs.msdn.com/dmahugh/archive/2009/05/09/1-2-1.aspx
http://www.robweir.com/blog/2009/05/battle-for-odf-interoperability.html
Then there's some outside commentary. I've taken the following links from comments in Doug's blog posts, and they tend to either be neutral or side with MS on this, so it may not be a representative sample. If you have any representing informed argument for the other side (e.g. by members of ODF committee, or ODF implementers - in general, people who know the ins and outs of the spec, and can accurately judge on its wording and intent - not random blogosphere FUD from either side), please mention them in replies.
http://ajg.math.concordia.ab.ca/?p=4
http://adjb.net/post/Notes-on-Document-Conformance-and-Portability-4.aspx
http://broadcast.oreilly.com/2009/05/odf-11-formula-support-in-office-sp2.html
You are missing one ENORMOUS detail: the formulas ARE defined, they are defined by Open Office and every other ODF user as "do what Excel does" (to be pendantic they are "do what Excel does when set to a locale that uses commas as the decimal point").
Microsoft is in the BEST position to do this, better than anybody else including OpenOffice! I believe they have the most accurate implementation of Excel. Or are you going to claim otherwise?
Complicated wording and excuses from Mr Dave Mahugh just show that he is a truly sick and moralless individual. It is blatently obvious how to do the formulas. He is purposly writing stuff he knows as absolute bullshit in order to satisfy his paymasters. A bug in OpenOffice does not mean "don't write any ODF formulas" which is basically what he is claiming. WRONG.
Microsoft did it: they managed to make ODF scary - it may or may not work. It was a brilliant FUD move.