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

Comments

What did we expect?

[TechForensics]

I mean, really?

Re:What did we expect?

[Vanders]

Did you really think Apple was different from Microsoft?

That's unfair. Apple have never made an iWorks product intentionally produce a broken ODF document! *cough*

Re:What did we expect?

[narfspoon]

Well it's just gaming the system.
They follow the letter of the law.
But they go against the spirit of the law.

Re:What did we expect?

[MrHanky]

You really think so? The EU will probably slap them with a hefty fine yet again. This is just another example of Microsoft being deliberately anti-competitive.

Re:What did we expect?

[FishWithAHammer]

Tried it. Not the case.

Re:What did we expect?

[dem0n1]

Microsoft can't suck money directly from my paycheck

At least not until they get that subscription thing down and start charging by the month.

Re:What did we expect?

[just_another_sean]

Actually there was a time when Microsoft was hailed as the white knight in the shiny armor freeing us from the evil IBM empire.

Yeah but that was ~twenty years ago, which is like two hundred in do^H^H computer years.

Since then Lancelot has screwed the king's wife and is off in the wilderness slowly going insane.

Re:What did we expect?

[mevets]

| Actually there was a time when Microsoft was hailed as the white knight in the shiny armor freeing us from the evil IBM empire.

I've heard this said, but somehow I managed to miss it. I started work in the industry in 87, and had first encountered microsoft probably in 84. Outside of ziff-davis style vanity press, everything about MS was about what crap they were technically and ethically. The white knights were DEC, BSD, Borland, Commodore, ...

Re:What did we expect?

[Zero__Kelvin]

We really need a special mod option "Offtopic + Idioitic"

Re:What did we expect?

[Zero__Kelvin]

"Who wants to target a moving standard?"

Software Engineers. It is what we do for a living.

Re:What did we expect?

[jbengt]

Actually there was a time when Microsoft was hailed as the white knight in the shiny armor freeing us from the evil IBM empire.

While I certainly remember thinking of IBM as the evil monopolistic overlords in the '80s, I thought of Microsoft as more of the black knight working with IBM, then stabbing them in the back as soon as they got a chance in order to become the new evil overlords.

Re:What did we expect?

[arth1]

As opposed to LD_LIBRARY_PATH hell and no codecs at all?

Comparing Windows and Linux feature by feature is always going to be futile. The two are different, and if trying to make Linux a direct replacement for Windows, you'll necessarily have to chop down the things that make Linux great (like the toolbox approach and not being designed from the "one user, one application, one machine" philosophy).
And comparing Linux with Windows is like wrestling a pig. You'll just get dirty, and the pig enjoys it.

Re:What did we expect?

[jedidiah]

> As opposed to LD_LIBRARY_PATH hell and no codecs at all?

What "hell" are you refering to exactly?

Most people never even see this.

As far as "no codecs" go: you simply should not comment on things you obviously know NOTHING about.

Not only does Linux have codecs, they are also much easier to deal with a "package manager" based approach.

Comparing Windows and Linux feature by feature is NOT futile as your brainfart of a post amply demonstrates.

Re:What did we expect?

[Vegard]

Yah. The real heros bringing us the PC revolution was the guys reverse engineering the hardware/BIOS, and made cheap clones. The OS was just what became the de facto standard.

As we all know, DOS won over CP/M. CP/M was technically superior at the time, but lost for political and/or contract reasons, whatever.

Digital Research then went on to create a better DOS to compete. MS fought it with all means it could, and it went into oblivition.

At early stages, MS Windows was just a graphical shell on top of DOS. It wasn't particulary good either. There were competing graphical shells, for example Digital Research' GEM. Digital Research lost the patent lawsuit that MS essentially won, and GEM was limited to have only two windows simultaneously...who knows what it could have been.

MS has not had the technical best/superior solutions at any time. It was just better at legal and marketing stuff than anyone else.

The PC revolution would have come with or without MS. We'll never know how much innovation MS have killed on its way where it is, so to hail it as a savior is just plain stupid.

They also claim Windows supports Posix

[dyfet]

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.

Re:They also claim Windows supports Posix

[Z34107]

Well, Windows is at least somewhat POSIX compliant.

A few semesters ago I took an Operating Systems class; our labs were simple programs involving forking processes, named pipes, sockets, and file I/O, which we were to develop on an old Solaris box.

Not much of a Pico fan, I developed my programs on Vista using Visual Studio 2005. They all compiled and ran on Vista, and then also compiled and ran on gcc and Solaris. These were simple programs, mind you, but it worked.

Now ODF... TFA only looks at spreadsheet compatibility, and evidently there is no way documented in the ODF standard to store spreadsheet formulas. Article claims that they should have reverse engineered it or reused code from some other plug-in, but really I'm surprised they included any ODF support at all - "new markets" be damned.

But, if no-one's satisfied, they also introduced a whole new API for writing file format converters. Go write your own plug-in!

Problem with the Spec

[Anonymous Coward]

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?

Never ascribe to malice...

[Anonymous Coward]

Never ascribe to malice that which is adequately explained by incompetence.

That's what I keep telling myself. I simply can't believe that they are brilliant masterminds crafting up BS like this. I'm probably wrong, but it saves me a lot of time (as far as trying to comprehend such stupidity).

Which means it won't get used....

[syousef]

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

Re:I just hope

[arthurpaliden]

They won't. All they will see is the ODF box checked off.

The article speaks about spreadsheets.

[Anonymous Coward]

The article speaks about spreadsheets, which the slashdot blurb neglected to mention.

Unfinished sayings

[Bogtha]

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.

Still no OOXML!!

[jkrise]

Surprisingly MS has decided to implement ODF in their own strange way, but OOXML is still not available.... why??

Everybody pile on Microsoft...

[Blakey Rat]

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?

Re:Everybody pile on Microsoft...

[Vanders]

The current spec doesn't cover spreadsheet formulas: it has a big whole and basically says "Do what OpenOffice.org does for now". ODF 1.2 will cover spreadsheet formulas but it isn't finished yet. So yes, it is valid to say "Well the spec doesn't cover formulas, not Microsofts fault".

Except...Microsoft already have a perfectly good plugin that can read & write ODF documents. It appears they've gone out of their way to break that existing code and do things differently to how everyone else (including themselves) are already doing things. As the author of the blog says "If your business model requires only conformance and not actually achieving interoperability, then I wish you well.".

If Microsoft have put all that effort into adding ODF support without actually achieving interoperability then it's a thinly veiled paper exercise on their part.

Re:Everybody pile on Microsoft...

[hal9000(jr)]

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?

Because specifications are written by people and then read and interpreted by others. While specification creators try to be as complete and thorough as possible, there are still gaps. In something as complex as a document format like spreadsheets, I'd imagine it's an impossible task. Bake-offs where all the stakeholders get into a room, try to get this shit to interoperate, and then decided the proper interpretation, is where the interoperation work gets done. All of the Internet protocols went through a similar cycle. Then, when there is consensus on the interpretations, guidance and reference implementations can be written.

Re:Everybody pile on Microsoft...

[clone53421]

Self-replying, I know, but I just thought of something else.

According to TFS, Office fails to load ODF files created by any other application. If those files are compliant with ODF standards, the blame for this lies squarely on Microsoft. They fail to open standards-compliant ODF files.

Re:Everybody pile on Microsoft...

[Sockatume]

If those following the standard act in good faith and cooperate outwith the standard to ensure compatability, a flexible standard allows for innovation and invention. You can always pin things down further as the standard evolves, but you can't really undo excessive constraints further down the line. If one of the players decides to act in bad faith, then it falls apart. In this instance, MS is either only supporting ODF in the most box-checking token manner (as they have a long history of doing with important features), they're deliberately, or they're pulling the old "embrace, extend, extinguish". They're morons or assholes.

Re:Everybody pile on Microsoft...

[Culture20]

The current spec doesn't cover spreadsheet formulas: it has a big whole and basically says "Do what OpenOffice.org does for now".

The problem with MS's specs saying "Do what Word 97 does" is that no one other than MS knows what Word 97 does. But OpenOffice's source code is... open. Anyone can know what OpenOffice does, and if MS is afraid of GPL, they're big enough for proper cleanroom approach.

Re:Everybody pile on Microsoft...

[drinkypoo]

The reason for this is that it's a hard problem

I don't think you can really use that blog post for that citation, because it's the same source as TFA which is both more relevant, and substantially newer... and which says:

We might [also] hear concerns that supporting other vendors' ODF spreadsheet formulas cannot be done because this formula language is undocumented. The irony here is that the formula language used by OpenOffice (and by other vendors) is based on that used by Excel, which itself was not fully documented when OpenOffice implemented it. So an argument, by Microsoft, not to support that language because it is not documented is rather hypocritical. Also, the fact that the Microsoft/CleverAge add-in correctly reads and writes that legacy formula syntax shows not only that it can be done, but that Microsoft already has the code to do it. The inexplicably (sic) thing is why that code never made it into Excel 2007 SP2.

Editorial [brackets] and note mine.

In summary: Your source, the same person who wrote the article which explains why it isn't hard also says Ecma dropped the ball. (in your link.) Another particular gem, this time from the current FA again: Everyone knows what TODAY() means. Everyone knows what =A1+A2 means. To get this wrong requires more effort than getting it right. So to say "The trouble is, it doesn't standardise them - in particular, there's no standard list of spreadsheet functions and what they should do." is just crazy talk which actually apologizes for Microsoft. In fact, there is such a list; the list documents what Excel does, since there was nothing else available; Microsoft itself had this functionality in a previous version, and now it is gone. Therefore the trouble is that Microsoft has deliberately broken spreadsheet compatibility in Office 2007 SP2. There is really no other way to look at it. It might not have been the goal (an alternate excuse might be to take advantage of another, newer codebase in order to eliminate some old code which is otherwise unnecessary) but it was trivially testable and therefore is inexcusable.

Re:Really?

[plague3106]

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?

Agreed ... interoperability harms Microsoft

[golodh]

Seriously, Microsoft has a huge cash-cow to protect in MS Office. And the first layer of defense is lock-in. If MS Office were truly inter-operable, then that would remove an enormous barrier against the introduction of Open Office.

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.

Re:Agreed ... interoperability harms Microsoft

[badpazzword]

Ok, let's assume they were malicious and all they worried about was lock-in. Then it would make sense to bork the ODF writing part.

But being able to correctly read ODF files would just be a big plus in an already great product like Excel. Why break the reading part?

Re:Agreed ... interoperability harms Microsoft

[99BottlesOfBeerInMyF]

Microsoft does not want interchanging of information. They want everybody using MS Word on an MS operating system. The end.

Every major vendor would probably like their own product to dominate. The difference is not the motivation, but the methods. Some vendors honestly try to make the best product and win customers by so doing. MS prefers to leverage monopolies to artificially break competing products and prevent users from being able to choose based upon the individual merits of the products in question.

I have no problem with MS wanting their OS and office suite to dominate. I have a problem with their breaking the law and hurting the industry, innovation, and end users to make that happen.

Re:Agreed ... interoperability harms Microsoft

[99BottlesOfBeerInMyF]

But being able to correctly read ODF files would just be a big plus in an already great product like Excel. Why break the reading part?

Because they don't want to discourage just other products that use ODF, they want to slow and discourage adoption of ODF as a format. Anything that makes more users stick with MS proprietary formats longer, makes MS money. Every user who sends an ODF file from Google docs to an Excel user, then finds it doesn't work is discouraged from using Google docs and encouraged to buy a license for MSOffice so they can interoperate easily with that other person.

Re:Agreed ... interoperability harms Microsoft

[99BottlesOfBeerInMyF]

Well, at least it works on OO and MSOffice 97 -2007.

Sigh. That's the point. MS's market share allows them to artificially break other programs by making it really, really hard for those companies to writer interoperable programs, thus costing them money and slowing their ability to work on other aspects of their programs, like making them better or faster.

I also do not know if the "better" ODF works on MS Office prior to 2007 at all (does it have a converter?).

Yes, there are several, but whether it works or not is largely dependent upon MS, who is financially motivated to make it not work. And by that I mean they are motivated by making you pay for more licenses at a higher cost than the free market would normally determine.

Well, if I send a .doc file at least I know that almost everyone will be able to open it.

I strongly disagree. As a professional writer I've been in the position of trying to open old .doc files, and I often ended up setting up multiple VM's with old versions of Windows and MacOS and various versions of word, simply in order to export the files to a more modern format currently sold software can read. There are companies that make big money just taking your old Word files and translating them to PDFs and newer Word formats so they can be used again. Have you tried opening a ten year old Word file? Sometimes they open and sometimes they don't. Sometimes a different version of Wood will open them. Sometimes only OpenOffice will open them. Often they are at least partly garbled.

Moving to ODF doesn't guarantee that a given program will be able to open the ODF file 10 years from now, it just guarantees the information needed to do so will be available to any company that wants to add that functionality. For old .doc files, MS might have the info needed but never completely succeeds and everybody else is just reverse engineering and hoping for "good enough".

Spreadsheets, people, spreadsheets

[hal9000(jr)]

TFN talks ONLY about spread sheet interoperability. It's important to note that. Has interoperability testing been done with documents?

Re:Really?

[Benanov]

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.

Bullshit

[Anonymous Coward]

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.

Re:Bullshit

[clone53421]

Microsoft should go and reverse engineer the implementation by OpenOffice

Reverse-engineer it? You have the source code. You don't have to reverse-engineer anything.

Re:Really?

[rekoil]

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.

Badly Specified Standard

[SwashbucklingCowboy]

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.

Re:Really?

[Bill_the_Engineer]

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.

Re:Really?

[Sockatume]

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.

Counter-adage

[SteveFoerster]

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.

Now, ODF == .doc and .xls

[IGnatius T Foobar]

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.

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 .doc and .xls space.

Re:Really?

[mR.bRiGhTsId3]

But... But... That's what microsoft did with OOXML. How dare you compare us to the vagabonds!

Re:Chickens are coming home to roost

[Rakshasa Taisab]

"One the one hand we require Microsoft to follow specs to the letter, and now we somehow fault them for doing so?"

If you're following a specification to the letter, you're already breaking the spirit of the specfication.

Hypocrisy

[benjymouse]

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.

Re:Really?

[Sockatume]

You fail at reading the licence.

Re:Really?

[Mr Z]

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?

Self-defense, perhaps?

[thethibs]

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.

Re:I'm shocked!

[99BottlesOfBeerInMyF]

MS, a for-profit company, refuses to embrace a format that gives an advantage to their open-source free competitors? Surely not!

Coca-Cola, a for-profit company, refuses to stop shooting farmers who want to be paid for their land which would cost them money, giving an advantage to their Pepsi competitors? Surely not!

I think what you're missing here, is MS's actions are ILLEGAL actions to hurt competitors, which normally is news. It's just that MS breaks the law so often and the laws are so poorly understood by the general public that many people aren't as outraged as one might expect. If another company were breaking the law to hurt smaller competitors would your attitude be the same?

Re:I tried as well

[Burkin]

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.

Re:Chickens are coming home to roost

[99BottlesOfBeerInMyF]

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?

Re:It doesn't give an advantage

[InvisiBill]

It works the other way too. MS Office is now able to share documents flawlessly with other suites. While most people think this is a win for FOSS, it can be a win for MS too. Picture a small organization that can't afford MS Office. Regardless of anything else, they are not using MS Office. MS Office supporting ODF allows them to interact with this organization's OpenOffice (or whatever alternative suite they use) ODF files. Yes, this is not the most common situation, but it does happen. In some cases, MS supporting ODF will actually be an advantage for MS.

As AC said, it's more that MS is giving up their proprietary format advantage, than ODF providing an advantage for others. ODF is a level playing field. MS proprietary formats are advantageous to MS for lock-in reasons, and supporting ODF well may negatively impact that.

Re:Really?

[99BottlesOfBeerInMyF]

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?

Re:The pertinent point in the article

[99BottlesOfBeerInMyF]

Sun is just as bad or worse than Microsoft by implementing incomplete standards leading to the same incompatibility that ODF is supposed to resolve.

Sun fully implements the very latest version of the spec. Maybe they should not use that as the default (probably a poor decision at this point) but that does not make them "just as bad as MS". Unlike MS Office, OpenOffice reads in all versions of ODF spreadsheets just fine. The fact that they write to the newer version has caused one incompatibility issue with the current version of Koffice which will soon be fixed and their documents work fine in everything else (except of course MS Office). Koffice gracefully fails using the fallback method.

MS Office, on the other hand, uses the failback method for everything, be it old or new versions of ODF. They are incompatible with every other implementation in this regard. Trying to equate the two is either very misguided or very disingenuous.

Now this makes sense

[ilo.v]

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.

The spec assumes good faith.

[Rob Y.]

If the spec assumes that all implementers are doing it with the intention of achieving interoperability, then there's not as much need to nail down every byte of the syntax.

If, however, one of your implementers is Microsoft, and you can more or less assume that one of their goals is to assure *incomplete* interoperability, then you've got a whole other thing.

The folks designing ODF were building a standard that they thought all implementers would treat as a standard. Yes, things were left out, and I guess the OOo implementation was assumed as a reference implementation to go to for the details. But it's not quite incompetence to assume people are approaching implementing your standard in good faith.

By the way, wasn't there a Sun-generated plugin for MSOffice to handle ODF? Does that work better?

Re:Really?

[Bill_the_Engineer]

Is it a problem with the C standard that I can embed Pascal in a C comment?

YES! If the C standard considered compilers that executed arbitrary code within comments to be compliant and the goals of the C standard was to allow any compiler that met the C standard make the same resultant object code.

The problem is not that you could put any text within a comment. It's a problem if your Pascal code is required to produce the desired object code.

If the goals of the ODF was to make file formats readable by other office suites then they technically succeeded, but if they intended to have a format that enforce rules that made the file interoperable with other office suites then they obviously didn't meet that goal.

I know a lot a people here on Slashdot feel personally invested in ODF, but that only makes it uncomfortable to point out the obvious.

All I'm saying is that you can't just fault Microsoft for having the ability to produce a file that other software can't use and still be ODF 1.1 compliant.

That wasn't MS

[Xtifr]

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.