Office 2007SP2 ODF Interoperability Very Bad 627
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."
What did we expect? (Score:5, Insightful)
I mean, really?
Re:What did we expect? (Score:5, Funny)
I might be confusing Microsoft with a wife beater, but the mentality is roughly the same it seems.
Re:What did we expect? (Score:4, Funny)
Say what you will about Microsoft, but I'll start using Linux on my production machines when I want to start losing money. Get the facts [getthefacts.com], people.
Re:What did we expect? (Score:4, Insightful)
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? (Score:5, Funny)
I might be confusing Microsoft with a wife beater, but the mentality is roughly the same it seems.
What do you tell a user with two black eyes?
(I propose that the answer is "Did you really think Apple was different from Microsoft?" but that might not win me too many points around here. The converse would work almost as well, but nobody would have believed that Microsoft was the good guys.)
Re:What did we expect? (Score:5, Insightful)
That's unfair. Apple have never made an iWorks product intentionally produce a broken ODF document! *cough*
Re:What did we expect? (Score:5, Informative)
nobody would have believed that Microsoft was the good guys.
Actually there was a time when Microsoft was hailed as the white knight in the shiny armor freeing us from the evil IBM empire.
Re:What did we expect? (Score:5, Insightful)
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? (Score:5, Insightful)
| 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? (Score:5, Informative)
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, ...
It was pretty obvious to many techies by the early 90s that Microsoft software was crap. The printed press was one of its tools and perpetuated the myth that companies would be better off with Microsoft. By 1995 it was getting out to a more general crowd how bad Microsoft was but these people still required having their eyes and minds open. Considering where they are today, it's obvious many are still pretty ignorant to their business practices and technology in general. By 1995, even the author, Douglas Adams saw this:
Microsofthttp://www.gksoft.com/a/fun/dna-on-microsoft.html
Here's a quote from the end of that short article:
"The idea that Bill Gates has appeared like a knight in shining armour to lead all his customers out of a mire of technological chaos neatly ignores the fact that it was he who by peddling second-hand, second-rate technology, led them all into it in the first place."
Over $200 million in marketing spent on Window 95 and about the same amount the following year pushing NT as _the_ server OS suckered in enough to seal their position in the market. That seal is leaking now but unfortunately, the general population of computer users and IT execs are mostly just as naive as they were in the early 1990s. It's the OEM's who are driving the market now because of very low margins and the high relative cost of Microsoft software.
LoB
Re:What did we expect? (Score:5, Insightful)
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.
Re:What did we expect? (Score:5, Insightful)
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? (Score:5, Funny)
Godwin'd!
That wasn't MS (Score:4, Insightful)
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.
Re:What did we expect? (Score:5, Funny)
Nothing. He's already been told twice.
Re:What did we expect? (Score:5, Informative)
"...1 second or so that it took to open the "Save file as" dialog..."
It takes 2 seconds for a menu to appear on my work XP laptop when I click the Start button. It takes forever to open a Word document. Virus scanning is now part of the Office experience and can't be disregarded. And this is on a more modern computer. What is your point.
Re:What did we expect? (Score:4, Funny)
Hey, it is different. Hence not compatible.
Re:What did we expect? (Score:4, Informative)
I use Windows for compatibility, but open-source for everything else: VLC, WinAmp, OpenOffice, Utorrent, et cetera.
I don't think you understand what open source is. Winamp and uTorrent are not open source.
Re: (Score:3, Funny)
I dont see why you're comparing MS to congress. Why not compare it to being eaten by a shark (with frikkin laser beams if thats your thing) or abducted by aliens.
Congress doesn't have a history of lying to people... oh hang on
Congress doesn't have a history of screwing the public for money/business interests... wait a minute..
Congress... errr.. never mind
Also... uTorrent isnt open source.
Re:What did we expect? (Score:4, Insightful)
Re: (Score:3, Interesting)
Not likely that they'll embrace a competing standard antytime soon.
Re:What did we expect? (Score:5, Interesting)
Well, that depends on who you talk to. Here in the US, that's probably true. Pretty much it's up to Europe to send the lawyers back in.
But, there is a comment at the end of the article to check for an obvious abuse:
The only way for Microsoft to make their legacy ODF documents work and to exclude other vendors would be to specifically look in the document for the name of the application that created the documentThis should be simple to test with a text editor, change the name of the application to match one that works and test that.
Since I don't have access to Office 2007 until I get home tonight, I can't try this out. But if someone feels compelled in the meantime, I'd love to see the results. If the document "magically" works after changing the header, then Microsoft did *not* do enough to keep the lawyers at bay.
Re: (Score:3, Insightful)
Tried it. Not the case.
Re:I tried as well (Score:5, Insightful)
No, that's not it. (Score:4, Informative)
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).
Excel, not Word (Score:4, Informative)
Re:What did we expect? (Score:4, Insightful)
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? (Score:5, Interesting)
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.
Except if you look a little closer, the EU doesn't just fine them. The fine is trivial, and does nothing but make the news in the computer press. Just money. A fine is like a parking ticket. And if you are rich enough, you can theoretically see a parking ticket as a parking fee.
Forcing them to correct the problem to the satisfaction of a neutral third party acting as a technical "expert witness" however, is a worthwhile activity. And this can really sting. This is more like taking away their car, or revoking their license. Way more than a slap on the wrist and a stern look.
Re:What did we expect? (Score:4, Funny)
Doh, how do Governments force people to do stuff? Just jail the people at the top of MS in the relevant countries. If they refuse to go to jail, send people authorized to inflict force and violence to drag them off to jail.
That's well within the authority of any country which MS operates in.
You don't even have to fine at all. Once you start jailing top executives, they'll start taking things really seriously.
After all, if you're a CEO, the fines don't really come out of your pocket[1].
But time in prison comes out of your lifespan.
[1] They might in theory affect your bonus etc, but in practice just look at the AIGs of the world.
Re:What did we expect? (Score:5, Interesting)
If it achieves 100% technical compliance with the standard, but zero interoperability, this is certainly a problem with the standard itself.
And the problem in this case is the missing formula specification. It's not in ODF 1.1, and ODF 1.2 is still a draft. While this is Microsoft and we all "know" that this was intentional, ODF is what should be fixed first. We were all bashing OOXML specifications, but ODF 1.1's far from perfect, as we can see.
Did the author of the article test with anything else than a spreadsheet with formulas? Formula breakage was expected and mentioned in the comments to the previous article. The interesting part is are there other flaws with ODF 1.1, are they addressed by 1.2?
Re:What did we expect? (Score:5, Informative)
And the problem in this case is the missing formula specification. It's not in ODF 1.1, and ODF 1.2 is still a draft. While this is Microsoft and we all "know" that this was intentional, ODF is what should be fixed first. We were all bashing OOXML specifications, but ODF 1.1's far from perfect, as we can see.
That is, curiously, not quite true. ODF 1.1 doesn't fully specify formulas, but it does specify the general syntax that should be used for them, and Microsoft seems to have ignored this. (Also, in practice, the major spreadsheets are quite similar in terms of what expressions they accept in formulas. This makes it relatively simple to convert between MS Office formulas and OpenOffice.org ones, which are what most ODF-based apps use.)
Re:What did we expect? (Score:5, Informative)
Re:What did we expect? (Score:5, Insightful)
Software Engineers. It is what we do for a living.
Re:What did we expect? (Score:5, Informative)
From the article:
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. Excel supports 1-2-3 files and formulas and legacy Excel versions (back to Excel 4.0) neither of which have standardized formula languages. Why are these supported? Also, the fact that the Microsoft/CleverAge add-in correctly reads and writes the legacy ODF formula syntax shows not only that it can be done, but that Microsoft already has the code to do it. The inexplicably thing is why that code never made it into Excel 2007 SP2.
Re:This is a REQUIREMENT so that Excel can be read (Score:5, Informative)
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!
Agreed ... interoperability harms Microsoft (Score:5, Insightful)
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 (Score:5, Interesting)
Oh course. This has always been true with Microsoft, where in the late 80s/early 90s they advertised they could read WordPerfect files from Amigas or Macs, but all it did was strip all the formatting to leave-behind plain text. Yuck. Even later when Word was released for early PowerMacs, I found that Windows Word could not read the Word documents from my Macintosh.
Microsoft does not want interchanging of information. They want everybody using MS Word on an MS operating system. The end.
Re:Agreed ... interoperability harms Microsoft (Score:5, Insightful)
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: (Score:3, Insightful)
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 (Score:4, Insightful)
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 (Score:5, Funny)
To really add flavor to the discussion, let us further assume that planet Earth is spherical, and space is pretty big.
Because you look ridiculous claiming you were able to follow the standard for reading documents, but unable to do so when writing them?
Re:Agreed ... interoperability harms Microsoft (Score:5, Informative)
Åpne dokumentstandarder blir obligatoriske i staten. [regjeringen.no]
My rough translation from Norwegian:
- Norway has so far lacked a policy regarding the area of software. This have now changed. This Cabinet has decided that IT-development in the public sector shall be based upon Open Standards. In the future we will not accept that State activities locks users of public information to Locked Formats. - Heidi Grande Røys [wikipedia.org] (Minister of Government Administration and Reform).
Microsoft might play their games to hinder development as much as they can, but at least in this country the turn towards Open Standards seems inevitable.
Re:Never ascribe to malice... (Score:5, Interesting)
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/ [robweir.com]
Re:Never ascribe to malice... (Score:4, Funny)
Re:Never ascribe to malice... (Score:4, Funny)
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."
Counter-adage (Score:5, Insightful)
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.
They also claim Windows supports Posix (Score:5, Insightful)
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 (Score:4, Insightful)
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!
Re:They also claim Windows supports Posix (Score:5, Funny)
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.
Ah, I think you might have misread that one. The latest version of Windows is fully compliant with the ISO's 'Piece of Shit v9' standard. POS IX, not POSIX.
Re:They also claim Windows supports Posix (Score:5, Informative)
Microsoft Windows is POSIX.1 compliant, which will not help anyone today but which is nonetheless true.
Re:They also claim Windows supports Posix (Score:5, Informative)
Well if you just go for the basic level of posix support, then yes it does support it. So does 100 other OSes, including weird embedded OSes that can't even run executables. Everything has to be compiled in, but they are "POSIX" too.
To be far UNIX Services for Windows is pretty decent and gives you a very complete POSIX environment on Windows.
Problem with the Spec (Score:5, Insightful)
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?
Good point! (Score:5, Interesting)
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?
Re: (Score:3, Interesting)
Not necessarily broken, but certainly incomplete.
Re:Good point! (Score:5, Interesting)
Sure, it might be "incomplete" rather than "incorrect", but if we're talking about a standard for interoperability, doesn't "incomplete" pretty much imply "broken"? That sort of standard only has one job, and it isn't going to do it...
Which means it won't get used.... (Score:5, Insightful)
...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.
I'm shocked! (Score:5, Funny)
The article speaks about spreadsheets. (Score:5, Insightful)
The article speaks about spreadsheets, which the slashdot blurb neglected to mention.
Re:The article speaks about spreadsheets. (Score:5, Interesting)
Unfinished sayings (Score:5, Insightful)
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 [wikipedia.org]. The extinguishing is the goal here, the former two are merely tools to help them achieve this.
Next stop - customer support (Score:3, Funny)
Now that'll be good for some fun calls to customer support.
Still no OOXML!! (Score:4, Insightful)
Surprisingly MS has decided to implement ODF in their own strange way, but OOXML is still not available.... why??
Everybody pile on Microsoft... (Score:5, Insightful)
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... (Score:5, Informative)
this is how [wikipedia.org]
Kind of looks like the whole thing was a farce to begin with given how they created a bad spec and then went on to support a worse one before imploding.
Re: (Score:3, Interesting)
And from the article, the format version 1.1 doesn't even define how spreadsheet formulas should be stored! Which is why Microsoft's implementation, which doesn't bother to store the formulas at all, is compliant with the standard. This is a joke. Gee, I wonder why Microsoft fought a bunch of non-technical government offices from forcing them to use a file format that's woefully insufficient for their (both Microsoft's and the government offices') needs?
Re: (Score:3, Informative)
Re:Everybody pile on Microsoft... (Score:4, Insightful)
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 [robweir.com] which is both more relevant, and substantially newer... and which says:
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:Everybody pile on Microsoft... (Score:5, Insightful)
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... (Score:5, Insightful)
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... (Score:5, Insightful)
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... (Score:5, Insightful)
Re:Everybody pile on Microsoft... (Score:5, Insightful)
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... (Score:4, Interesting)
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.
Conversely, if the files produced by MS Office are valid standards-compliant ODF files (which they may be according to the letter of the standard) we should also blame the other apps if they fail to use them, isn't so? They will also fail to open standards-compliant ODF files.
Well, interoperability wasn't the goal. (Score:5, Interesting)
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.
EXCELLENT article (Score:3, Interesting)
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.
Hypocrisy (Score:4, Insightful)
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.
Sun ODF plugin for Microsoft Office (Score:5, Informative)
holes in the standard (Score:5, Interesting)
Spreadsheets, people, spreadsheets (Score:5, Insightful)
Bullshit (Score:3, Insightful)
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 (Score:4, Interesting)
Re:Bullshit (Score:4, Insightful)
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.
The problem is formulas. (Score:5, Informative)
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?
Re:The problem is formulas. (Score:4, Informative)
Because it's bloody hard to do.
Microsoft's spreadsheet formula language in OOXML is actually a copy-and-paste job from the Excel help files. It doesn't provide nearly enough information to re-implement. It was only added as an afterthought, when Microsoft started complaining that ODF didn't have a spec for spreadsheet formulas, made a big deal about it, and then realised that OOXML didn't either.
ODF does have a formula language specification. It specifies something like 400 functions in precise detail, loosely based on what OOo, Gnumeric, and others (including Excel) already do. This has been a work-in-progress since 2005 (before Microsoft started complaining about ODF), and is basically finished (for now). It's to be included in OpenDocument 1.2 (the next version), but most other OpenDocument-capable spreadsheet apps already use these formula specifications on OpenDocument 1.1 documents.
Microsoft just chose to ignore it, and roll their own. As usual.
Badly Specified Standard (Score:4, Insightful)
Pigs (Score:4, Funny)
Now, ODF == .doc and .xls (Score:4, Insightful)
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
Self-defense, perhaps? (Score:5, Insightful)
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.
The Microsoft formulas aren't actually conformant (Score:5, Informative)
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.
Re: (Score:3, Funny)
Bloody hell. I wonder why they would ever want to ship a software product that did that.
You must be new here. (grin)
Re:Really? (Score:5, Insightful)
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?
Re:Really? (Score:5, Insightful)
Because apparently it's really difficult:
http://www.robweir.com/blog/2007/07/formula-for-failure.html [robweir.com]
Oasis and ODF committees would rather get it right than have something busted and broken like competing suites.
Re:Really? (Score:4, Insightful)
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? (Score:5, Insightful)
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?
Re:Really? (Score:5, Informative)
Interesting. According the article [linux.com] referenced in the Wikipedia [wikipedia.org] even OpenOffice and KOffice don't get along.
Re:Really? (Score:5, Insightful)
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:Really? (Score:5, Insightful)
Re:Really? (Score:5, Insightful)
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.
Re:I just hope (Score:5, Insightful)
Re:Chickens are coming home to roost (Score:4, Insightful)
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?