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
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.
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.
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 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?
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.
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
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.
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?
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.
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