Posted
by
timothy
on Wednesday May 20, 2009 @03:43PM
from the please-sub-in-the-new-bullet-points dept.

omz writes "The ODF Alliance has prepared a Fact Sheet for governments and others interested in how Microsoft's SP2 for Office 2007 handles ODF. The report revealed 'serious shortcomings that, left unaddressed, would break the open standards based interoperability that the marketplace, especially governments, is demanding.'"

That the standards created for the ODF formats are no where near perfect.

In fact, the ODF specification for spreadsheets doesn't state where formulas should go in a document. Something OpenOffice and Microsoft handle very differently. Because of these loopholes it's possible for software deveopers (Not just Microsoft) to do what they think is best instead of follow the standard.

What the OpenOffice and Open Source communities should be doing is working to resolve these loopholes so Microsoft and other

1) The whole reason they are doing the ODF thing is pressure from the EU with regards to anti-trust. Part of that pressure is that "You have to do it according to the standard." They don't want MS to go and say "Well we implemented some of the standard, but changed it in ways we like." So MS has been sticking strictly to the standard. Not all the other implementations do. So, you get a difference in results. Now you can argue that the right way of doing

The whole reason they are doing the ODF thing is pressure from the EU with regards to anti-trust. Part of that pressure is that "You have to do it according to the standard."

So you're arguing that MS's lawyers are completely incompetent and didn't know that being incompatible was a violation of antirust law and that antitrust law doesn't mention anything about standards compliance? I think that's a naive.

All the other ODF stuff I've seen is open source. As with most open source, they borrow heavily form other open source projects. In the case of ODF, the modus operandi seems to be "Do what Open Office does." Ok that's great, but again not an option for MS. They can't take OOs code...

They already own BSD licensed code that works on MS Office. Next argument please!

Basically the ODF spec isn't clear and precise.

But it's clear an precise enough that it worked for everyone else and there are multiple working open source implementations, one of which they can literally copy and paste from and which they helped fund the creation of and probably have full rights to it even if it wasn't BSD licensed. Sorry, that argument doesn't fly either.

Then there are cases where the popular ODF implementations aren't compliant with the spec.

Example please.

More or less it looks like the ODF alliance needs to shut up, and write a better standard.

They already did. MS doesn't want a standard for interoperability. They are simply looking for any way they can be compliant but still be incompatible.

Everything has to be specified precisely.

Not really, that's what reference implementations are for. If you have any doubt about how to handle this, see the reference implementations and do it that way.

The only argument you made that has any legs is the first one regarding compliance with the spec, but only if you assume ignorance of the law (I assume you perhaps aren't that familiar with antitrust law). I assure you, while it may at times appear that all of MS's lawyers have never heard of antitrust law, that is not the case in reality.

But it's clear an precise enough that it worked for everyone else and there are multiple working open source implementations, one of which they can literally copy and paste from and which they helped fund the creation of and probably have full rights to it even if it wasn't BSD licensed. Sorry, that argument doesn't fly either.

No, it just means that there are other implementations that behave similarly to OpenOffice.org.

Demanding that Microsoft implements the ambiguous / not standard parts of OO.o's ODF in the same way that OO.o does is sort of like demanding that Mozilla implements all the ambiguous / not standard parts of MS's HTML/CSS rendering implementation. Or demanding that Apple modify OS X's kernel so it implements the same syscalls as Linux instead of implementing POSIX, because Linux is the most popular operating system used to run programs that target POSIX.

Of course, with ODF, 1+2=1 [msdn.com]. ODF 1.1 is broken, and there is nothing that can be done to make a fully standards-compliant ODF 1.1 implementation without filling in the gaps somehow. Apparently [wikipedia.org], OO.o 1-2 uses a nonstandard forumla implementation and OO.o 3 writes to the not yet finished ODF 1.2 standard.

You are missing one ENORMOUS detail: the formulas ARE defined, they are defined by Open Office and every other ODF user as "do what Excel does" (to be pendantic they are "do what Excel does when set to a locale that uses commas as the decimal point").

Microsoft is in the BEST position to do this, better than anybody else including OpenOffice! I believe they have the most accurate implementation of Excel. Or are you going to claim otherwise?

Complicated wording and excuses from Mr Dave Mahugh just show that he is a truly sick and moralless individual. It is blatently obvious how to do the formulas. He is purposly writing stuff he knows as absolute bullshit in order to satisfy his paymasters. A bug in OpenOffice does not mean "don't write any ODF formulas" which is basically what he is claiming. WRONG.

You are missing one ENORMOUS detail: the formulas ARE defined, they are defined by Open Office and every other ODF user as "do what Excel does" (to be pendantic they are "do what Excel does when set to a locale that uses commas as the decimal point").

"Do what Excel does" is not the behavior specified by the latest published standard, and "do it however Open Office does it" is not the behavior specified in the published standard either.

People have been sacrificing standards compliance for years in order to b

Microsoft did what they had to do to break compatibility. They must have been laughing themselves silly when they realised that other users of ODF had left the door open for them to both break compatibility AND claim compliance.

Don't kid yourself, they may have been very happy to claim that they are compliant, but compliance was not the aim. Breaking compatibility was the primary purpose.

Microsoft did what they had to do to break compatibility. They must have been laughing themselves silly when they realised that other users of ODF had left the door open for them to both break compatibility AND
claim compliance.

Don't kid yourself, they may have been very happy to claim that they are compliant, but compliance was not the aim. Breaking compatibility was the primary purpose.

Why was this modded Flamebait? It is actually insightful, given Microsoft's history [vanwensveen.nl]. That moderators rarely award points to ACs is somewhat understandable, but to censor an AC when it is already invisible is puzzling to me. Must have been an unintentional error is the only thing I can imagine.

However, we arent talking about that part: in this instance, the only claim you can make against the standard is its failing to provide formula specification for spreadsheets.

This is something that MS and all implementors can be asumed to have known BEFORE starting to implement the standard. All other implementations, INCLUDING the BSD licensed one by a microsoft contractor, chose INTEROPERABILITY, Microsoft in their second and internally executed implementation, chose to BREAK IT, and thus it DOES NOT interperate with anything at all.

You can only claim compliance, but you cannot provide evidence that this choices werent taken with WRONGFUL WILL (them being the evil fuckers theyve always been). It was an ill willed decision, that is obvious and the evidence is that, hey, they DONT interoperate at all when they COULD and actually DID interoperate in OTHER implementations.

There are two implementations: OpenOffice and Microsoft Office. Microsoft Office does it differently from OpenOffice, and you conclude that "only Microsoft handles it very differently?" Or is there another reference implementation to compare to?

There's a lot more than 2 implementations. Besides OpenOffice and MS Office there's AbiWord, KOffice, Google Docs, WordPerfect Office X4, IBM's Lotus Symphony, the Sun ODF plug-in for MS Word and the BSD-licensed ODF plug-in for Word that Microsoft funded and hosted on SourceForge. That last is important, BTW. Not only is Office 2007's implementation of ODF incompatible with OpenOffice, it's incompatible with Microsoft's own other implementation of ODF.

There's a lot more than 2 implementations. Besides OpenOffice and MS Office there's AbiWord, KOffice, Google Docs, WordPerfect Office X4, IBM's Lotus Symphony, the Sun ODF plug-in for MS Word and the BSD-licensed ODF plug-in for Word that Microsoft funded and hosted on SourceForge. That last is important, BTW. Not only is Office 2007's implementation of ODF incompatible with OpenOffice, it's incompatible with Microsoft's own other implementation of ODF.

Well duh it's incompatible with that! The plugin (Microsoft's) works well with other OpenDocument programs, so it therefore must never see the light of day (from Microsoft's point of view).

Also see his later post on 1+2 [msdn.com]. Office and Lotus agree it is 3, but OpenOffice thinks it is 1 in some cases.

Here's what is really going on: for the first time, someone is actually using ODF who cares about consistency with existing documents, and making predictable behavior. Since ODF currently is ridiculously underspecified, this is revealing a lot of problems with ho

Yes, a little, but do you expect them to break down how OpenOffice does it? Could cause legal issues. "How did you (Microsoft) know to save the formulas at X? It's not in the standard, only we (OpenOffice) save there.."
[snip]

Microsoft:Well, we just created a file in OOo Calc (the spreadsheet thingie) and then unarchived it, examined its pieces, etc.

No, they could break down how the odf-converter plugin does it...This plugin supports formulas in the same way openoffice does, is released under a bsd license and it's development has been sponsored by microsoft anyway.

They intentionally created a new incompatible way of storing the formulas, despite already having the details and code of how to store them in an interoperable way...

Or, to do it perfectly, clean-room it. Have one team create an internal ODF spec based on the OpenOffice source. Give that spec along with the OpenOffice source to the lawyers, have them approve it. Give the spec to your Office devs.

The others are open source projects, and can look at each other's code. MS can't, or they'd have to open source their code.

This is a completely misleading statement and totally misses the point. Well done!

You don't need to look at the source code to see what other products do. You just need to look at the ODF files they produce. Indeed, given the licenses of the products that implement ODF, you can obtain the copies you need for testing FOR FREE.

Similarly, while your legal department might bar you from reading competitors code for fear of copyright co-mingling, there is nothing to stop you employing a third party to go look on your behalf and write a report on what was done. So you can have your cake and eat it.

Or they could ask the proper author (I don't know who owns the copyright on that particular portion of OOo) for a license to do so. I betcha that someone interested enough in OOo's future to write a save/load algorithm for it would let Microsoft use it (in part or in whole) for Office. Complete compatibility between the two program suites would work heavily in OOo's favor, for reasons that seem obvious (to me) and that I won't go into to avoid creating a tl;dr situation.

Maybe if someone out there knows anyone (or is on) the OOo team drops the idea of a public offer to give Microsoft a special license to their already working code, some traction could be gained, or at least some light could be shed on the willingness of Microsoft to rectify the situation. I hope they are honestly willing to achieve cross-compatibility, but my guess is that that is likely too optimistic.

Already done, spreadsheet formulas are being specifically addressed in ODF 1.2. But in 1.1 there was already a set of conventions for handling formulas, and Microsoft were the only ones out of all the ODF 1.1-using applications that couldn't follow those conventions. In fact their implementation even specifically violated one of the bits that was in the ODF 1.1 spec: the spec calls for cell names to be enclosed in square brackets, while Microsoft's implementation omits the brackets. Then you have just plain malicious stuff like actively removing formula information that's present. Even if you can't parse the formulas, XML makes it easy to preserve what was there. Every other implementation behaves that way: if they can't understand the formulas at least they leave them intact for applications that do understand them. Microsoft's is the only implementation that deliberately removes formulas from the spreadsheet.

What annoys me most about Microsoft's pseudo-support is that it had to be deliberate. They had to actually expend additional effort to be this incompatible. If they'd simply been lazy and taken the easiest way out, they would've been far more compatible with everybody else than they ended up being.

Pretty much, yes. Bear in mind that Microsoft already has code that does handle the spreadsheet formulas correctly. The plug-in that Microsoft itself commissioned and that they own the code for not only preserves the formulas, it correctly parses and interprets them so that cells get recalculated properly as data changes and it correctly writes changed formulas back out. All Microsoft had to do was to not do all the work a second time. And even if they had re-done the work, the XML parser automatically populates the DOM with the formula strings and the internal implementation in Excel already can preserve arbitrary metadata from external formats even when it can't interpret it. All they'd've had to do is not touch things the user hadn't edited and the preservation would've happened automatically. I do this all the time when dealing with XML code, to the point where I have to make a deliberate effort not to write data-preserving code.

To me, this is all whining by the anti-Microsoft folks. When Microsoft supports ODF 1.2, and if they goof up, then complain.

At which point you'll still be apologizing for them and say we should wait till 1.3 to complain?

ODF 1.1 was to[sic] vague and to somehow blame Microsoft because they followed a poorly written spec...

Yeah it was so vague every other company managed to implement it just fine, including Microsoft in the plug-in they hired someone to write and whose code is BSD licensed so they could have just copied and pasted, since it was already working with MSOffice as a plug in. I have this bridge you might be interested in Brooklyn.

The blame still rests on the ODF standards.

Bullshit! There are multiple reference implementations and free code available and even sma

If the standard is strict like other open standards, and they still fail to be compatiable[sic], I wouldn't "apologize" for them.

Please. The standard is just fine for any honest company trying to make a product that works. It just wasn't written as an ironclad legal contract to keep MS from playing dumb and intentionally breaking compatibility.

Actually, if you read another comment on this article, you'd see that other applications actually didn't handle the standard all that well like you claim.

Other comments? I don't have to because I actually bothered to read about the topic before discussing it. There is one other compatibility problem among the programs tested and it is because one of the programs is using the newer version of the spec. Saving from OO as ODF 1.1 is compatible. Thats completely different from being incompatible with every other program implementing the same version of the spec.

"Free code". You do realize that many of those "free" code samples are licensed that would require Microsoft to open source Office or portions of Office.

Please educate yourself before trying to argue. There is a working plug-in for MSOffice licensed under the BSD license so MS can simply copy and paste if they want. They've done it before with BSD code.

This is about a standard that was weak and failed to state everything clearly.

Bullcrap. This is about a standard that is fine for any honest company and about one company intentionally trying to break things to harm competition.

Asking any company to follow it is insane.

Yeah, except nobody else had any real problems including small hobbyist groups. Believing your crap is insane. In fact, your position is so unbelievable, I strongly suspect you're an astroturfer. You have a history of all of 13 comments, almost all of which are defending Microsoft. You're either a paid shill or you really drank to kool-aid.

Standards are created to make sure something, like software, can output a verifiable item that others can use.

Standards are created to HELP people to create interoperable software. Interoperability is the goal, not compliance. If it isn't the goal, MS is breaking the law. They have to be compliant with competitors by law, not follow standards.

If you have a standard that says to do certain things, but makes no mention of others, you don't just copy your competitor.

You don't know what a "reference implementation" is do you?

Microsoft followed a standard and because OpenOffice or anyother program can't actually open it always, you blame the company for following the standard set out?

Yes, I blame them because they went out of their way to play dumb and implement the standard in an incompatible way and they broke the law in so doing.

Please educate yourself before trying to argue. There is a working plug-in for MSOffice licensed under the BSD license so MS can simply copy and paste if they want. They've done it before with BSD code.

Sure they could use that code or inspect the ODF files, but you miss the point everyone here is making: The standard is what Microsoft follows, not the competitor's method of implementation.

First, the BSD code in question was paid for by MS, its not a competitor's Second, MS is not legally obligated to obey the standards, but they are legally obligated to honestly attempt compatibility with competitors. Not even testing against competitors does not seem like an honest attempt to me.

Again, they followed a broken standard, just because OpenOffice and others copied eachother doesn't mean Microsoft or others should.

Yes it does if their goal is compatibility and since the law requires them to attempt to be compatible with competitors lest they be leveraging their monopoly influence, that is exactly what they should have done if they had to choose between the standard and being compatible. That, however, is a false dichotomy. They could have followed the standard and been compatible. They chose not to.

You seem to support Mac/Google/OpenOffice...

This seems to be your main problem. Technology companies are not sports teams. I'm not in support of any company. I point out when any of them does something good or bad because I don't have emotional investment in any of them.

...and reading comments that always blame Microsoft is sickening.

Why? They're a criminal company that routinely breaks the law and in so doing holds back innovation in numerous technology markets. Is there any surprise that a site made up of geeks who love technology would have a lot of negative things to say about them?

Microsoft and Open Source have their problems...

Yeah, sort of the way GM and aluminum casting have problems. Open source is a method of licensing, not really comparable to a corporation.

...quit pretending that OS is perfect and Microsoft is the anti-christ.

What OS are thinking I'm pretending is perfect? I never said MS was the antichrist. That's two strawman attacks in a row. MS are just a corporation that happens to have a lot of influence in certain markets and a tendency to break the law and undermine free trade. They do a lot of damage and it is wholly appropriate to point out when they break the law yet again.

They are no different than any other corporation (Google? Sun? IBM? Don't be evil, yeah, right).

They are different from those listed above in that MS's criminal violations of antitrust law are ongoing and have not been stopped and THEY'RE THE ONES BREAKING THE LAW IN THE ARTICLE WERE DISCUSSING! When Google or IBM or Apple is breaking the law and hurting competition and an article about it is posted here, I'll complain just as loudly.

That the standards created for the ODF formats are no where near perfect.

This is indeed the case with the spreadsheet formulas. However, there's more. From TFA:

Microsoft Office 2007 does not support encryption (password-protection) in ODF files.

[...]

Encryption and password protection are fully specified in ODF 1.0/1.1 (item 17.3 of thespecification), so the failure to define this feature in ODF cannot be cited as a plausibleexplanation.

Also,

Microsoft Office 2007 does not support tracked changes in ODF.

[...]

Tracked changes are specified in ODF 1.0/1.1 so the failure to define this feature in ODF cannotbe cited as a plausible explanation.

Furthermore, one could note that

Commitment to Support Future Versions of ODF

Microsoft has dragged its feet for over 3 years (ODF 1.0 was approved as an OASIS standard inMay 2005 and as an ISO standard in May 2006; ODF 1.1 by OASIS in Feb. 2007), despiterepeated calls by governments throughout Europe and elsewhere to implement support for ODF.

Microsoft has a rich history of implementing down-level versions of open standards;e.g., Java in Internet Explorer, where Microsoft pre-installed an incompatible versionwith proprietary extensions and then to let it languish, failing to update it as the Java technology evolved.

The ODF specifications are being improved in exactly the way you describe, version 1.2 is currently being worked on and it addresses the spreadsheet formula issues.

Now while it's true that the ODF spec lacks information on exactly how to store spreadsheet formulas, it does use almost the same syntax as excel... And it's also true that all the other ODF implementations, including the plugin microsoft created a couple of years back, handle formulas in the same way as openoffice.

You'd be surprised how many web-sites turn out not to be "state-operated" and thus still have documents only available in proprietary formats though. This also doesn't cover documents made available via other means (such as e-mail).

Why take one when you can have both? It was intended to be broken by method X, but the programming teams didn't talk to each other well enough, so it was broken by method Y, and the testing showed it matched the intended result by 80%, so it was shippable.

There is a lengthy discussion about the microsoft appointed staf to ODF. They even requested current lead of ODF to stand down cause hes "biased".

And well... having non-biased-against-microsoft people in a non profit organization, id say, would be contrary to their keeping their good money.

Only people in their wallet could ever support their petty arguments. They say "we comply!", but make no effort to actually be interoperable with ANY other ODF supporting suite (google, koffice and some office plugins).

They don't warn people about it, but they do consider anyone running or develping for openoffice eligible to be sued. Here's a news article from 2004 [crmbuyer.com] about the settlement between Sun and MS over staroffice that states:

In the document, it is stated that Microsoft agrees not to sue Sun for commercial distribution of StarOffice, which is based on OpenOffice.org, but that Microsoft can still seek damages from OpenOffice users or distributors for any copy installed after April 1, 2004.

Watch what happens if openoffice makes any kind of real dent in office's market share. It'll be just like the RIAA going after downloaders...

I know Microsoft is being its usual self, but perhaps the ODF alliance should promoting a certification program and a compliance logo to raise the quality of interoperability of ALL ODF based applications.

And more than just a logo. We need the equivalent of acid test. Round trip testing. Great opp for non programmers who have been enjoying Open Source software for so long. Test the ODF export/import in MSWord and submit bugs.

If you have been saying, "I support Open Source, but since I am not a coder, I cant do much", this is your chance to contribute positively and advance the cause for open standards.

That's a very insightful, proactive suggestion. Why bitch about the usual MS attitudes if you can provide a constructive path ahead, right?

Actually, it shouldn't be all that hard (but, it may well be tedious work) to put together a document that includes samples of *all* features of the spreadsheet / text editor / drawing / presentation document.

Providing verification is probably a bigger challenge. I wonder if it could be done as macros in any of the ODF-supporting suites, or if that's akin to an SOD violation?

+1 to this.
The Office Acid Test. It doesn't exist yet. People are already used to the idea of it in the browser space and may hev already heard of it from their nerdy friends telling them why Internet Explorer sucks so much.
Its a simple way to enforce and be transparent about compatibility. Nobody should be able to "work around" the standard.
It would be a HUGE plus if there was a way for the ACID test to also check for "embrace and extends"

If the certification program will certify conformance to the standard, then Microsoft implementation will get the certification (since it does conform to it).

If it will certify something else, then what will it be? Correct interop with OO.org? But isn't that preferential treatment of one particular implementation (in effect making it a reference implementation for the standard)? And what about cases where OO.org itself does not conform to the spec?

I don't get the section on Office 2003. Their gripe is that it doesn't support ODF. Well if MS doesn't release a service pack, why complain that 2003 doesn't support ODF when 2007 doesn't either (without SP2)?
Focus on their current (insufficient) efforts to update software, not on software they haven't yet decided to update. There's no threat to ODF interop in 2003 if it can't read them at all...

Meh, there's no standard that you cannot drive a Microsoft through. It's not like it is a provable mathematical theorem or such. Basically if you sift through any standard and find loopholes. You need testing to get things going right.

Standards are normally written with the assumption that people interpreting them have a desire to interoperate. This was of course a mistake when you have a hostile party like Microsoft.

It is trivial to comply to the letter with lots of standards yet make an implementation that does not interoperate at all. Maybe this should be some new variation on the obfuscated-C style contests. Pick some computer standard and write some software that does not work with it yet technically obeys every part of the standard. More modern ones that are designed for expansion such as ODF make this pretty easy, older communication standards would be more fun I think.

Although nobody is really surprised that Microsoft has made their software comply with the letter of the law and not the spirit, is this really a big issue? If, as the summary says, the marketplace is demanding a grand interoperability between software products, then we might see the rapid uptake of OOO in the near future. Failing that, if nobody switches, then the market has spoken loud and clear, Nobody cares.

Honestly, the single most productive thing you could do to ensure the rapid uptake of open standards would be to make openoffice.org an amazing product. Put all of your time and effort into making it clearly superior, and at that point everyone will use an ODF by default.

Although nobody is really surprised that Microsoft has made their software comply with the letter of the law and not the spirit, is this really a big issue?

First, they didn't comply with the letter of the law. This is clearly a violation of antitrust law. Second, they didn't comply with the letter of the spec, both failing to implement it properly and going out of their way to not implement features they already had working code for and ignoring both reference implementations.

If, as the summary says, the marketplace is demanding a grand interoperability between software products, then we might see the rapid uptake of OOO in the near future.

We might or we might not because monopoly influence on several markets allows Microsoft to undermine and break the normal operation of the free market system by violating antitrust law. In doing so they hurt competitors, consumers, and slow innovation.

Failing that, if nobody switches, then the market has spoken loud and clear, Nobody cares.

Yeah and the market spoke and nobody wanted answering machines, speed dial, or to own instead of rent a telephone while AT&T had a monopoly on phone service. The free market cannot operate and determine the best products at the best price when undermined by abuse. That's why it is illegal.

Honestly, the single most productive thing you could do to ensure the rapid uptake of open standards would be to make openoffice.org an amazing product. Put all of your time and effort into making it clearly superior, and at that point everyone will use an ODF by default.

When faced with a monopoly, having the better product does not mean you win in the market. Clearly superior products can and do lose because of artificial problems introduced to them; artificial problems like being unable to open most ODF files which were made intentionally incompatible by a company with monopoly influence on the market.

Second, they didn't comply with the letter of the spec, both failing to implement it properly and going out of their way to not implement features they already had working code for and ignoring both reference implementations.

That's the problem - the spec is too vague to be implemented properly. Because the spec doesn't spell things out in a specific way, it's impossible to implement in a consistent way - it's open to interpretation. The problem isn't Microsoft, the problem is the spec. ODF 1.2 should f

> That's the problem - the spec is too vague to be implemented properly.

The hell it is! There are reference implementations. There's BSD code they could copy-paste. The oft-referenced "problems" have already been dealt with by many other comments. If you're going to complain about ODF 1.2 documents in ODF 1.1 programs, I'm going to have to complain about Word 2003 documents that don't work right in Word 95, even if you use save as to save it to the old version.

OpenOffice is NOT a reference implementation of ODF 1.1. OpenOffice implements features that are not even specified in ODF 1.1 (for example: formulas). It cannot be a reference implementation of something that simply does not exist. ODF 1.2 should hopefully address this, but they will need to improve the language in the spec to make it less vague. Specifications are supposed to be specific (funny that).

1. OpenOffice implements features that are not even specified in ODF 1.1 (for example: formulas).

And there goes your credibility. ODF 1.1 does specify formulas and how they should be formatted, but is vague on the details. But no one else had any problems implementing them, including MS's commissioned plug-in.

It cannot be a reference implementation of something that simply does not exist.

Which of course you were completely wrong about. In any case, reference implementations are for filling in areas where the spec is vague so people know how to implement it for compatibility.

ODF 1.2 should hopefully address this...

ODF 1.2 did clarify things so it will be harder for MS to break compatib

When faced with a monopoly, having the better product does not mean you win in the market. Clearly superior products can and do lose because of artificial problems introduced to them

You make a good point. I would take your argument a bit further and contend that one major artificial problem is government-sponsored monopoly through the broken patent system, and instruments like the DMCA which are both used not to give the inventor a chance to profit from his work, but to bludgeon anyone or anything who might represent a threat to the bottom line.

Maybe I'm completely wrong, but it seems like the patent system has given us many of these monopolies because inventors and innovators are

Honestly, the single most productive thing you could do to ensure the rapid uptake of open standards would be to make openoffice.org an amazing product. Put all of your time and effort into making it clearly superior, and at that point everyone will use an ODF by default.

(a) You're making the common mistake of conflating ODF with OOo. The two are completely separate entities. People who advocate the use of ODF are not necessarily OOo fans; they may prefer Abiword, KOffice, or even Microsoft Office. The whole point of open standards is that it shouldn't matter what software you use.

(b) Even if you take your goal to be the promotion of OOo (a particular software product) rather than ODF (a document standard), then it's naive to think that all you have to do is make a product that's better than MS Office. The sad truth is that no matter how good your product is, most people will be reluctant to switch to it. People hate change. The product would need not only to be better, but to be about 10 times better. And then you would need to communicate that fact, in the face of the best marketing that one of the world's richest companies can buy. Not an easy task.

But if you can get open standards adopted, then there's no longer any reason to care about increasing OOo market share, because it won't matter what software people use: you'll still be able to read their documents and they'll still be able to read yours.

What do I mean ? It starts by assuming that you know what ODF is, giving it a name ''the OpenDocument Format'' doesn't really help -- the average Member of Parliament/Senate/Dictatorship/... will not have a clue what you are talking about. All sorts of other buzz words abound, there are names of unknown things like KSpread and Symphony -- who has heard of them ?

I am sympathetic to what they are doing - it is a great idea, unfortunately it won't get much legislator/bureaucrat/... eyeball time because it doesn't explain what it is all about. It needs to be prefixed by a page that explains it all in nice, friendly words that everyone can understand and say that the technical details are on the next pages -- which starts with page 1 of what they have produced.

People are seriously arguing that Microsoft should munge the standard to go along with the most common implementation? Welcome to the web, circa 1996. That's exactly how web standards got to be the mess they are. Browser manufacturers wrote browsers to be compatible with each other and to support new features, instead of following the standards. And thus the standard fell behind and became increasingly useless.

Before you judge on this issue, it helps to read comments by various involved parts - those raising the issue to attention, MS people who have implemented ODF, and informed commenters outside this dispute. So, here's a bunch of links to start with.

First of all, a series of blog post by OASIS' Rob Weir (who's criticizing MSOffice) and Microsoft's Doug Mahugh (who's defending it) that evolved into a kind of a public discussion on the issue. Here they are in chronological / meaningful reading order:

Then there's some outside commentary. I've taken the following links from comments in Doug's blog posts, and they tend to either be neutral or side with MS on this, so it may not be a representative sample. If you have any representing informed argument for the other side (e.g. by members of ODF committee, or ODF implementers - in general, people who know the ins and outs of the spec, and can accurately judge on its wording and intent - not random blogosphere FUD from either side), please mention them in replies.

You're not trying to let them edit it. You're trying to influence them with a fixed document. So a display-only format is fine.

Further: You're trying to influence people who are NOT YET onboard with ODF. So you want a format that is viewable by as wide an audience as possible while displaying conveniently in an easy-on-the-eyes form. Right now that's PDF.

Putting it out in ODF means it's only viewable by people who already have ODF installed. That's mainly the people who are already onboard and don't need to be convinced. So it would be a case of "preaching to the choir" rather than "converting the heathen". Useful for giving your evangelists more talking points perhaps. But not all that useful for the purpose intended.

Perhaps, but the format is in plain xml for Office2007; xlsx, docx, etc are merely zip files containing xml documents which could be transformed to other formats.
As long as you have the schemas for the right and left the program to make the document becomes irrelevant.

For a commercial vendor, GPL licensed code is not "open" or "available" at all.

No, but BSD licensed code is and MS has already incorporated BSD code into several of their important products (TCP/IP stack for Windows for example). There exists a BSD licensed plug-in for MSOffice which MS helped to fund the creation of, but they somehow managed to make their new implementation incompatible with that plug-in and every other implementation.

They have to code it to the spec, and code to the spec they did.

Excepting, of course, that complying with the spec does not mean crap when it comes to antitrust law. Complying with the letter of the spec while still

By that token, then, OO's poor support of Microsoft formats is also OO's fault. Which was my original point earlier in the thread.

Really, where is the fully documented spec for docx? Where is the open source reference implementation of MSWord? Where is the BSD licensed version of Word formats on Linux that they can just copy and paste?

When your format is not open and documented and you don't implement it in an open source reference it is a hell of a lot harder to be compatible and that is absolutely MSs fault and their legal liability. Your point is excessively flawed.

You seem to have fallen for marketing nonsense. There exists a spec, which no one including MS has implemented. Then there exists the docx files MS office creates which are not compliant with the standards you link to and which are not fully documented anywhere.

From the first link you posted, a quote about when MS will be compliant with the published version of the spec:

On March 13, 2008 Doug Mahugh, a Senior Product Manager at Microsoft specializing in Office client interoperability and the Open XML file formats confirmed that version 1.0 of the Open XML Format SDK
"will definitely be 100% compliant with the final ISO/IEC 29500 spec, including the changes accepted at the BRM"

To date they have not managed to comply fully with their own format specification and no other company has a fully compatible version either, that I know of.

So where is the documentation for the docx format Word creates today? Where is the fully compliant, BSD licensed reference implementation for Linux that OO can copy and paste code from? I think your argument pretty much went down the crapper at this point.

Because the format hasn't been finalised as a standard. How are you supposed to conform to a standard that isn't final? Once it's final, then you can conform, until then you can conform to what you think the standard might be.

Because the format hasn't been finalised as a standard. How are you supposed to conform to a standard that isn't final?

That's a very good question. If you read the whole thread though you should be replying to "melted" who was claiming OpenOffice should have implemented OOXML and the situation with ODF is exactly the same... although I suspect they're trolling.

Which still doesn't change the fact that one is an open standard, and the other is merely a proprietary format. Open standards are agreed upon, and should grant interoperability by definition. When one company decides to break an open standard it is a big deal.

This sort of change has nothing to do with end users, they don't even know there is a format "war", they generally don't even know what a format IS. This exists because some interoperability is a good thing, and it keeps MSFT from leveraging their

If anyone is interested in specifically what is "broken"(read: incompatible with OpenOffice.org 3.0)... which I doubt... here is some very good information detailing which decisions were made in implementing ODF and why they were made:

Beyond this, Microsoft is simply implementing ODF 1.1 because ODF 1.2 is not done yet. If Microsoft is going to support a standard, they will support the standard not the most popular implementation's interpretation of the standard.

Interesting, but isn't Openoffice the generally accepted reference implimentation, even if it is not 100% of the way there yet? I'm pretty sure the other apps in the MS blog list use OpenOffice.org that way too. Really, there is no real excuse.

Interesting, but isn't Openoffice the generally accepted reference implimentation, even if it is not 100% of the way there yet? I'm pretty sure the other apps in the MS blog list use OpenOffice.org that way too. Really, there is no real excuse.

The generally accepted reference is and should be the OASIS ODF standard itself. Digging through the source code of competing products to see which assumptions they made while implementing a standard does not constitute proper standards behavior. There's no reason to assume OpenOffice is the correct implementation of ODF, since Sun went to great lengths to get governance of the standard outside their organization. The question is whether Microsoft wants to implement the standard itself or write a minor Open

The generally accepted reference is and should be the OASIS ODF standard itself.

You're being obtuse or you don't know enough about software coding to know what a "reference implementation" is. A published standard tells you how to write to the standard. A reference implementation is an open source implementation of that standard that can be used when there is doubt about how the standard is to be implemented.

Digging through the source code of competing products to see which assumptions they made while implementing a standard does not constitute proper standards behavior.

The point of standards is interoperability. MS is legally required, due to their monopoly influence, to make a valid attempt at interoperability. Hiding behind the standard doesn't

That depends on whether you want interoperability NOW and only now or continuing interoperability. By implementing the standard properly, they are opening the door to proper and easily referenced interoperability. Constantly hacking their solution to keep up with the hacks that everyone else is using to circumvent the standard will just lead to document standards being as messed up as web standards. At this point, all Sun needs to do to keep up compatibility is actually finish the ODF standard and then impl

Are you paid to astroturf? Thy did not follow it to the letter and they ignored the reference implementations and if they tested for compatibility like everyone else they did so to make sure things would not work. Given their market share, that's criminal.

ODF 1.1 was a very simple standard to follow. It was only one page. In fact, it's only one sentence: "Do whatever OpenOffice does." Is that your idea of a "reference implementation"?

If that was the case, sure since OO is open source and well documented code. That isn't that case though. It's much better to simply code to the standards and look at one of the several interoperable open source implementations when there is question about what to do. And, or course, when you have a working version you should test it for interoperability with the existing implementations, or at least the working implementation for your program, already in use, which you helped to fund.

So, when MS Office SP2 implements ODF 1.1 with MathML to the letter and OpenOffice cannot read it because of a bug in OpenOffice, who is to blame?

If there is no definition in the spec, then a "reference implementation" cannot exist. The reference implementation follows on from the spec. Anything you do that isn't in the spec is called guesswork.

If you had to reverse engineer it from the OpenOffice implementation, myy guess is that Microsoft is rightly worried about code taint from it's developers reading open source code.

If there is no definition in the spec, then a "reference implementation" cannot exist. The reference implementation follows on from the spec. Anything you do that isn't in the spec is called guesswork.

Reference implementations exist so that when there is a vague part of the spec, people know what to look at for compatibility. The ODF spec says to use Excel style formulas enclosed in brackets, which pretty much every, especially MS, should know what are by now. MS didn't even get the brackets right and that is violating the spec. If they couldn't figure it out there were plenty of references to look at or they could have tried it then tested for compatibility.

If you had to reverse engineer it from the OpenOffice implementation, myy guess is that Microsoft is rightly worried about code taint from it's developers reading open source code.