Slashdot Mirror
Office 2007SP2 ODF Interoperability Very Bad
David Gerard writes "Microsoft Office 2007 SP2 claims support for ODF 1.1. With hard work and careful thinking, they have successfully achieved technical compliance but zero interoperability! MSO 2007sp2 won't read ODF 1.1 from any other existing application, and its ODF is only readable by the CleverAge plugin. The post goes into detail as to how it manages this so thoroughly."
I mean, really?
Those are my principles, and if you don't like them... well, I have others.
As they also claim Microsoft Windows is Posix compliant! It is simply to be able to tic a "mandated" requirement in some government procurement, not as something one would actually use or deploy.
So, this is either a problem with the specification or a problem with other implementations. If MS has made a compliant program, who are we to complain?
...which is probably the point of this. The only reason to use ODF instead of MS native formats is for interoperability. When people don't use it, MS can point and say "see people don't want or need it and didn't care when we put it in". Useful at all manner of legal proceeding (antitrust anyone) to show that it's not important.
These posts express my own personal views, not those of my employer
MS, a for-profit company, refuses to embrace a format that gives an advantage to their open-source free competitors? Surely not!
SJW: Someone who has run out of real oppression, and has to fake it.
They won't. All they will see is the ODF box checked off.
Undetectable Steganography? Yep, there's an app fo
The article speaks about spreadsheets, which the slashdot blurb neglected to mention.
This is the trouble with people saying the first half of a saying and then trailing off. The people who know the saying get the point, and the people who don't remember a fragment and repeat it even though it makes no sense on its own.
To the people tagging this "embraceandextend". Embracing and extending is not a particularly bad thing to do. Many formats, including XML (upon which ODF is based), are built with this in mind. The complete saying that is referred to with "embrace and extend" is embrace, extend and extinguish . The extinguishing is the goal here, the former two are merely tools to help them achieve this.
Bogtha Bogtha Bogtha
Now that'll be good for some fun calls to customer support.
Surprisingly MS has decided to implement ODF in their own strange way, but OOXML is still not available.... why??
If you keep throwing chairs, one day you'll break windows....
In the meantime, how the HELL is it possible the spec is so bad that you can be technically-compliant with it, and yet not be read by (almost) any existing implementation?
Comment of the year
Well, from the article: "First, we might hear that ODF 1.1 does not define spreadsheet formulas and therefore it is not necessary for one vendor to use the same formula language that other vendors use."
Seems like a rather large hole in the spec itself. ODF 1.1 doesn't define spreedsheet forumlas? So, what version will? I wouldn't put any effort into guess, nor making my application read various other vendor formats.. when I may well have to recode again when 1.2 comes out.
If anyone's to blame here, it's the ODF people for not having a COMPLETE spec. If formulas are so important to spreadsheets (and they are), why the hell would your spec not include how to store said forumlas?
Even if MS fails all interoperability (which I would bet they do), at least someone could use ODF with office 2007 and 10-20 years later be able to use the spec to develop an app to recover the documents.
This is one of the best-written articles submitted to slashdot in a long time. Not only is it well-written (at least, it didn't make my brain hurt) but it gives you the technical background AND it tells you in advance how to debunk the stupid arguments which will certainly by coming from M$ trolls and astroturfers. Scrapbook this one, kids. You're going to be referring back to it for months, if not years.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Never ascribe to malice that which is adequately explained by incompetence
Of course, I am not that cynical. I was taught to never assume malice where incompetence would be the simpler explanation. But the degree of incompetence needed to explain SP2's poor ODF support boggles the mind and leads me to further uncharitable thoughts. So I must stop here.
from the referenced article....
http://www.robweir.com/blog/
If you keep throwing chairs, one day you'll break windows....
Sun's ODF plugin for Office.
My ism, it's full of beliefs.
No surprise that MS has done this. What it does show, however, is that the ODF standard is incomplete. If MS can write out an ODF compliant file that no-one lese can read, ODF has a problem. In an odd sort of a way, MS are doing us a favour here by shaking out the holes. Role on ODF 1.2.
Clearly Microsoft's best interests are served by denying their customers interoperability.
That's what drives Microsoft's policy: cash. Everything else is PR. Which is duly born out by their actions.
TFN talks ONLY about spread sheet interoperability. It's important to note that. Has interoperability testing been done with documents?
Because apparently it's really difficult:
http://www.robweir.com/blog/2007/07/formula-for-failure.html
Oasis and ODF committees would rather get it right than have something busted and broken like competing suites.
This article focuses very specifically on formula support in OpenDocument Spreadsheet. The problem with that is that ODF 1.x does not provide ANY specification for formulas whatsoever. This article claims that the standard be damned and that Microsoft should go and reverse engineer the implementation by OpenOffice. This is only demonstrative of how incomplete and irrelevant the ODF specification really is. There are massive gaping holes in it that implementers are filling on their own which will invariably lead to incompatibilities. The ISO OOXML specification may be absolutely massive, but that's because it's complete, and very specific (I'm referring specifically to the one that did pass ISO, not the first few iterations).
This is like bitching that Internet Explorer can't be CSS compliant because it doesn't implement the moz-* CSS extensions.
Either fix the spec, or get used to this.
ODF does not specify the a language for formulas. Everybody but MS uses one language, MS uses another. Of course there are incompatibilities.
Why did ODF not specify a spreadsheet formula language?
Go green: turn off your refrigerator.
I was thinking exactly the same thing. If MS have made a compliant implementation but it isn't compatible with anyone else's, doesn't that mean that ODF is broken? Isn't this exactly the sort of complaint certain people around here have made against Microsoft's own formats in the past: just because there's a standard that officially states what the document format is, it's no use if other people can't realistically implement it and then trust that interoperability will work?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
In order to claim (in a legalistic sense) technical compliance with the spec in order to be able to sell Office to companies/governments who have adopted policies requiring this, while at the same time making it virtually impossible for those organizations to actually USE a competing office product.
If you have a standard where there are implementations that are 100% compliant and yet are totally non-interoperable then you have a badly specified standard.
If Microsoft is ODF 1.1 compliant, and other ODF 1.1 compliant software can't use the software, then it looks like the ODF committee didn't get it right and has something busted and broken.
I think the ODF committee was more concerned about getting their standard approved quickly than having a complete specification.
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
One could argue that MS could've chosen any formula spec it wanted and naturally went with Excel, leading to the incompatability, but the existing Cleverage ODF add-in was perfectly happy to read and write other ODF spreadsheet formula systems. There was no need for them to spend time and money creating a less compatible version of that bit of software, except with incompatability as a goal.
No kidding!!! What do you say at this point?
I'm waiting for the Microsoft Knowledgebase article explaining the incompatibility and showing you how to fix the problem by using the Save As function and selecting the .XLSX type.
Interesting. According the article referenced in the Wikipedia even OpenOffice and KOffice don't get along.
You don't know what you don't know.
Seems the pigs took a trip to the airport, but then failed to achieve take off
There's another saying, and one that I think better applies here: "Once is an accident, twice is a coincidence, three times is a conspiracy."
And with Microsoft we're way past three times.
Space game using normal deck of cards: http://BattleCards.org
Almost overnight, Microsoft becomes the market leader in ODF-compliant office suites. So now, OracleOffice.org and KOffice will have to code up all sorts of ugly hacks and reverse engineering tricks to maintain compatibility with Microsoft Office ODF documents. Exactly as they had to do to get compatible with .doc and .xls documents.
.doc and .xls space.
Microsoft plays dirty. All the time. This was totally expected, of course.
It's ok though; we're still in better shape than we were just a few years ago. A Microsoft ODF document, or even a Microsoft OOXML document, is still at least roughly following a standard that has some documentation somewhere. The free world can develop Microsoft Office compatibility in this space a lot easier than in the
Tired of FB/Google censorship? Visit UNCENSORED!
I'd say that it had a bad smell of Hypocrisy. If the standard doesn't cover important(I dare say) areas such as the friggin formula language, what good is the standard?
No, the author is trying to preempt the obvious and very valid argument that if the standard didn't cover this and implementers need to reverse engineer a specific implementation (OpenOffice), maybe the standard wasn't good enough?
The author is making silly analogies with someone willfully going through hoops (investing time) to sabotage interoperability with an implementation in which the implementor has chosen not to invest time and effort reverse engineering and testing functionality which is clearly outside the specification.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Microsoft put all their Excel formulas into a private namespace. This is almost as bad as, say, writing a compiler that claims to be a C compiler, but really, all it does is validate the syntax of the C program and then look for C comments containing Pascal code, then compiling the Pascal code instead.
BEGIN
writeln("Microsoft rules!");
END
*/
int main(int argc, char *argv[])
{
printf("This is standard C code.\n")
}
Is it a problem with the C standard that I can embed Pascal in a C comment?
Program Intellivision!
It looks like Microsoft has learned from its IE experience. Instead of chasing an "anything but Microsoft" standard put together by a community that's actively hostile to Microsoft, they've decided to wait them out. Microsoft is refusing to give them a target and telling them to get off the pot.
What Microsoft has done should speed up the ODF standards process. We should thank them for that.
I'm a Programmer. That's one level above Software Engineer and one level below Engineer.
The problem isn't that you can't open a Word 2007 ODF document in another ODF compliant program, it's that it refuses to open to other program's ODF documents. Hence why the summary says they are compliant but not being interoperable. Interoperability is a two-way street.
If you RTFA (yeah, yeah, I know...), the problem is with spreadsheet formulas.
One the one hand we require Microsoft to follow specs to the letter, and now we somehow fault them for doing so?
No, we're faulting them for following the specs to the letter and at the same time going out of their way to make sure their technically compliant implementation still doesn't work with all the other, existing implementations.
What is wrong about asking OpenOffice to follow the specs?
ODF does, for the most part, follow the specs. The problems between OpenOffice and MSOffice's implementations are that ODF implements a newer version of the spec and MS hasn't caught up to that, and MS decided the suggested (but not required) formulas, which use the same syntax as Excel and for which their is already BSD licensed code that works in MS Office as a plug-in, were "too hard to understand" so they just strip all the formulas out.
MS may, technically, be minimally compliant with the spec, but it is clear they went out of their way to be as minimally compliant as possible to make their version as incompatible and unfriendly as they could manage while still being within the spec. This was not an honest attempt at being compatible, despite MS's claims that they were making an honest attempt.
What goes around comes around. ODF was initially just a clever assault launched by Sun and IBM.
Yeah, but it was an attempt to level the playing field and let products win based upon merits instead of criminal leveraging of monopolies. I don't understand why people have such a hard time understanding antitrust laws and how they work and why we have them.
OpenOffice and derivatives, Sun and IBM just have to eat their own dogfood. Admit that the "perfect" ODF was at least partly a hype.
No one claimed ODF was perfect and the early spec MS is using left room for ambiguity... which is why they also provided several open source reference implementations which everyone else has had no real problem implementing. Aside from MS, the only real problems are bugs between the stable and draft versions of the spec. MS is just playing dumb. "Oh they say if we can't understand Excel formula's, we can fail back to just reading the value the formula would produce. We're so stupid we can't understand formulas identical to the one we already use, har har, and we're too stupid to use the free BSD licensed implementation that already works with MSOffice, har har."
The "problem" with the ODF spec in this case is that they wrote it as a spec assuming it would be used to make interoperable implementations, instead of as an ironclad legal contract with no loopholes for dishonest companies that wanted to try to be compliant but as non-interoperable as possible. After all, only one company had motivation to do that, and for them to attempt it would be criminal. That doesn't seem to have stopped MS though, as usual.
The chickens are coming home to roost. Suck it up. Fix it instead of point fingers.
Please. They already have a draft that removes the ambiguity and it is already implemented by several companies. If MS were interested in being honest or even obeying the law, there would be no issue. There is room for more than finger pointing, MS should be prosecuted for one more criminal antitrust violation. Why do you hate free market competition so much?
Interesting. According the article referenced in the Wikipedia even OpenOffice and KOffice don't get along.
The difference is OpenOffice reads everything fine. KOffice fails to read the latest OpenOffice docs perfectly because OpenOffice uses the new draft version of the spec as the default... and it is perfectly appropriate for KOffice to fall back to reading those formulas as the last value until they release a new version of KOffice that supports the new spec. That is why there is a failback mode in the spec.
MSOffice, however, fails back even when reading the old version of the spec, because they seem to have decided understanding Excel style formulas in Excel was too hard, despite the existence of several open source implementations and the spec being the formulas they already use. The difference is huge. Koffice is doing the right thing and being reasonable. MS is going out of their way to be as poor at interoperability as the spec allows by feigning extreme incompetence. I mean, did you look at the chart in the article. Why is it even small, unfunded projects seem to work interoperably pretty well, while MS can't manage to work with anyone else's implementation. Do you truly believe they are that incompetent?
I was puzzled by Microsoft's decision to imbed ODF compatibility in their current Office program so quickly. Now I understand why. They realized that if they hurried they could release BEFORE the spec was usable for spreadsheets. Now they will stall as long as possible. Their lobbyists are happy because they can say "we support ODF." Their marketers are happy because there is something labeled ODF in the program that is utterly useless. Pointy haired bosses will never understand the distinction between version 1.1 vs. 1.2, and will conclude forever that ODF is broken.
Am I the only person who reads that extension aloud as "Ex-Lax"?
Actually, the first two times I read it, it parsed as "Excel sucks."
Don't tell me to get a life. I'm a gamer; I have LOTS of lives!
The problem isn't that you can't open a Word 2007 ODF document in another ODF compliant program, it's that it refuses to open to other program's ODF documents.
If you actually read the article, you'll find that Google, KSpread, Symphony, OpenOffice, and the Sun plugin are all unable to open documents created in Excel 2007. The issue here is not that it's one way, it's that the MS interpretation is different from what everyone else uses (though the actual specification leaves it open). And it's also about spreadsheets (Excel), not word-processor documents (Word).
Microsoft's supposed ODF 1.1 spreadsheet output is not compliant with the ODF 1.1 specification.
From 8.1.3 (emphasis mine):
From 8.3.1 Referencing Table Cells (emphasis mine):
Now look at a Microsoft formula in their ODF 1.1 spreadsheets. You'll see a formula attribute value of "msoxl:=B4-B3". For that to be correct per the ODF 1.1 specification, that should be "msoxl:=[.B4]-[.B3]". Compare this to the OpenOffice.org and OpenFormula syntax:
msoxl:=[.B4]-[.B3]
oooc:=[.B4]-[.B3]
of:=[.B4]-[.B3]
Ignoring the prefix, they're identical. Furthermore, the formula functions used by OpenOffice.org are generally based on the functions in Excel to begin with (such as "TODAY", for example), so I can only conclude that Microsoft is intentionally sabotaging interoperability to keep people from using ODF while still claiming conformance.
Actually the early 80s. You see, before MSFT started the clone market by selling Compaq MS DOS and thus creating the IBM PC compatible market, things were VERY different. It was 'welcome to proprietary land" where my VIC wouldn't talk to your TRS80 [...]
Actually, it was Digital Research's CP/M (and AT&T's UNIX) that were leading the charge against "proprietary land". Bill Gates just got lucky when DR's Gary Kildall was out the day IBM came calling, and managed to steal DR's thunder with a hastily-purchased CP/M clone and IBM's marketing power. BG doesn't deserve credit for anything except dumb luck and being in the right place at the right time. The market was already headed in the direction of platform-independent OSes as fast as it could go.
On the contrary, it does make sense to alter them because there is something wrong with Microsoft's formulas. For example, consider the MAX() function in Excel:
Now consider the OO.o (and forthcoming ODF 1.2 standard) equivalent:
OO.o uses semicolons instead of commas to separate parameters; so what? Well, let's what would happen if you were European, and tried to do the same thing in Excel:
Uh-oh! Now, since Europeans use commas instead of periods to indicate decimals, Excel suddenly thinks that there are 8 integer parameters instead of 4 decimal ones! Excel is wrong! In contrast, here's how it looks in OO.o:
Hey, whaddya know: still four decimal numbers! It works!
But that's just the tip of the iceberg. If you read previous posts in the linked blog, the guy points out how (for example) most of Excel's date and financial functions are wrong (not just because of syntax, but because they implement the wrong algorithms).
Actually, it does -- 300-odd pages worth of one, in fact. But Excel doesn't follow that either!
In fact, those date and financial functions tend to give answers different from both the OOXML standard and the original financial standards they are supposed to be based on!
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz