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