Open Office has Calc - spreadsheet program.

opens and saves to MS formats - I use it to REPAIR corrupted MS files, both MS Word and MS Excel.
(xls/xlt for MS Excel 5,95,97,2000,XP,2003 XML,pxl)

Open Office Calc saves to following formats:
ods - OpenDocument Spreadsheet
ots - OpenDocument Spreadsheet Template
(for backwards compatibility sxc and stc)
dif - Data Interchange Format
dbf - dBase (isn't that FoxPro as well?)
(csv,HTML,supercalc,slk,starcalc)

odf is for word processing - not spreadsheets.
So I don't get Ephraims complaint.

Open Office (odf or ods) is surely a safer place for most any organization to keep ownership of data. Even if to just repair MS files - and it usually makes them smaller - save space. You have choices - don't lock yourself into someone elses software.

Get your copy of open office now, even if it is just to repair your MS files - you'll like it.

The claim by Paoli that ODF reflects what OpenOffice.org can do is demonstrably incorrect. There are three versions of ODF (1.0, 1.1 and 1.2). OpenOffice.org implements a significant subset of ODF 1.0. ODF 1.1 and ODF 1.2 add the missing spreadsheet functions, significantly improved handicap access, better metadata integration with RDF, and a few other features. The first office suite that I can recall implementing ODF was KOffice, not OpenOffice.org. There are ongoing efforts to improve the ODF standard (at OASIS and ISO) and to produce products that correctly implement the standards. ODF is the result of a many groups, it is much more than 'the OpenOffice.org format'.

You have a pretty big 'if' in your conclusion. I suggest that you install OpenOffice.org 2.2 and try to import Microsoft Office documents. It is not the role of a document standard to 'open' documents in other formats. OpenOffice.org 2.2 does this quite well. Some of the work being done in ODF 1.2 is to improve the ability to make a two way exchange between ODF and other formats lossless. This is useful, but if all you need to to is to open existing documents and save them in either OpenXML or ODF, I think you will find that OpenOffice.org does this quite well.

By the way, even Microsoft Office doesn't do two way translation perfectly. If you generate a document with math formulas in Office 2007 and save it in Office 2003's doc format, you will not be able to submit the results to Nature or Science since the files will not display property.

References to support my previous claims:

For a history of the ODF standard, Wikipedia is reasonable and doesn't seem too biased: http://en.wikipedia.org/wiki/OpenDocument

from http://www.sciencemag.org/about/authors/prep/docx.dtl
Because of changes Microsoft has made in its recent Word release that are incompatible with our internal workflow, which was built around previous versions of the software, Science cannot at present accept any files in the new .docx format produced through Microsoft Word 2007, either for initial submission or for revision. Users of this release of Word should convert these files to a format compatible with Word 2003 or Word for Macintosh 2004 (or, for initial submission, to a PDF file) before submitting to Science.

Users of Word 2007 should also be aware that equations created with the default equation editor included in Microsoft Word 2007 will be unacceptable in revision, even if the file is converted to a format compatible with earlier versions of Word; this is because conversion will render equations as graphics and prevent electronic printing of equations, and because the default equation editor packaged with Word 2007 -- for reasons that, quite frankly, utterly baffle us -- was not designed to be compatible with MathML.

'In addition, ODF is not backward-compatible with Excel -- or any other Office file format -- so you can't migrate old Excel files to ODF.

"The Office plug-in from OpenOffice does not support that," Paoli says.'

That is not a problem for ODF - it is an application problem. All it needs is for an application that can read an old excel file and write an ods file. The standard simply decribes how to save information in a particular way. So long as the format can save all the same information that came from the source document, then 'backwards compatability' doesn't enter into it. That is purely a problem for the application.

The ECMA standard is called "Office Open XML" and if you want to play into Microsoft's marketing plans by calling it Open XML or Office XML or whatever, if you don't call it Office Open XML( OOXML ) then you're already showing your stripes.

You want to play marketing tricks? It should be called MS Office Open XML then since it is tied to Microsoft Office at the brain stem.

Well, I guess Microsoft is a marketing company first and foremost so I guess if you're going to be writing about them, you are probably more likely to be their toy than not.

Mr. Schwartz,

If OpenXML is indeed accepted as an ISO standard *and* I see free implementations of the standard, then I will happily welcome it to the land of open standards. There are still a couple of stone left unturned:

1. You pretty much let Microsoft have their say up there without giving IBM's or Sun's counterpoints
2. I honestly don't care which standard wins - just as long as my data access rights are protected. This is why I support California's AB 1668 and similar open formats legislation
3. ODF is not the OpenOffice.org format. There are numerous implementations of it. Again, if there are multiple, uncrippled implementations of OpenXML, I'll use it, too.
4. Many of the comments by the Microsoft flaks are refutable. Most of their complaints re: ODF are application-level issues, not tied to a particular format.

Bottom line: OpenXML must protect our right to access data, or else I'm not supporting it.

After thinking this over for a day, I am actually quite disappointed with this article. You claim to be a 'Reality Check' but you allowed incorrect statements to be made without doing fact checks. The claim "you can't migrate old Excel files to ODF" is simply false. OpenOffice.org's Calc can do that today. You could have tested this in all of about 20 minutes by installing OpenOffice.org, assuming that you have a fast Internet connection. There is certainly an issue with ODF not having a complete spreadsheet formula specification - so that is being developed in ODF 1.2, which will be out in months. You seem to have been bamboozled

As a rule, Eliza Doolittle had it right with "Sing me no song! Read me no rhyme! Don't waste my time, Show me!". Don't accept one side of a partisan issue without evidence. Isn't that a rule that journalists should have learned? Respectfully,I expected more from a senior technology journalist.

as some have commented before, the author follows the maketing logic of MS.

1. as MS tries to do, he mixes applications and documetent standard.

2. IBM may have an interest in ODF, to see it as a battle between MS and IBM, however, is wrong, since anybody can implement ODF and therefore has an interest (Openoffice, Koffice and also IBM and even MS itself). That is different with MS and Office Open XML, since this cannot be (completely) implemented by everybody, as MS asserts patents on some parts and since there are binary objects, whose structure is not specified in the revealed specs.

3. These points - and therefore the bias - are revealed in statments from MS that are accepted without criticism like : "The Office plug-in from OpenOffice does not support that,". MS is talking application not standard here. Besides, even if talking applications: Why critise that plugin that enhances your own application with additional features that you refuse to implement? Does MS provide a Office Open XML plugin for Openoffice? That can only mean that MS is not interested in interoperability, but only in preserving the user lock they have created via their application. Why? because they are interested in preserving their application (Office) monpoly. ODF on the other hand is about interoperability, and not about applications.

4. Another point that illustrates this is the question of converting EXEL to ODF. As others have pointed out, odf is for word processing. But also, odf as a standard does not convert anything as only implementations in an application can do that. As Excel and Word are propriatary formats, it is MS that would need to be blamed if conversion to an open standard is not possible. That MS is trying to use their own deficit as an argument against ODF is quite outragous. That the author does not pick up on that, makes clear where he stands.

Try moving files created on MS office between Windows and Mac platforms. It is a complete nightmare. M$ office has its own set of mightmarish cross platform and backward compatibility problems.

-G

Reading your post, seems that it's biased. You are speculating about comments from IBM and MIcrosoft. Both sides have their own views and you only can have your own using OpenOffice to look what's going on. It's pretty ease tell people something that I want they to believe, but if I don't get my hands dirty with those products, I can barely make any comments about "interoperability". I'm a programmer and systems support; I have already used both MS Office and OpenOffice and can say that OpenOffice has opened all my MSOffice documents without any problems. Microsoft people are only spreading FUD about "backward" compatibility.

http://www.consortiuminfo.org/ has posted many articles on OpenXML. The most obvious flaw is that it includes many "descriptions" that say things like, roughly, "format footnotes as Word 95 does". That's not a specification. No one without a copy of Word 95 can write an application that formats such data properly — and even then, observed behavior is not specified behavior.

By sprinkling proprietary, unspecified behavior mandates over their specification, Microsoft has ensured no one will ever produce an application that works better with it than theirs does. Which, of course, was the point of not adopting ODF in the first place.

DEPENDS ON WHAT YOU WANT OUT OF THE FILE FORMAT

1) If you want to PRESERVE DATA FOR POSTERITY, you want ODF.
OOXML is useless for that since it is basically an XML wrapper around content using undocumented secret Microsoft proprietary file formats. The OOXML documentation refers to "will be done as in MS Office 97" and stuff like that which Microsoft will never document, so only Microsoft can implement full fidelity in OOXML. If Microsoft stops selling a reader for content saved in OOXML in ten years time say, then your content is gone, as many who saved content in MS Write ten years ago know well.

With ODF, what you see today is what you see in ten years time, and because it is a fully documented format, you will see the stuff that is supported the same with any vendor's software, and there are complete open source implementations that are available to download even if no company is marketing the product.

2) If you hope to AVOID FORCED UPGRADES due to format change, you want ODF.

The problem with OOXML is that the patent covenant explicitly excludes use of what is covered by the patents governing the OOXML specification in revisions or future versions of OOXML. Therefore in about three years when it is time for the next round of forced upgrades, you will see new incompatible version of OOXML which only Microsoft can legally implement. Am I sure about this? Yes, absolutely. If Microsoft doesn't have a forced upgrade every three years or so, their revenue collapses. The forced upgrade is an intrinsic part of Microsoft's business model, and Microsoft will not abandon it.

3) If you want INTEROPERABLE CONTENT that anyone can read with 100% fidelity, you want to provide content in ODF format.

As explained in the article only Microsoft Office or Microsoft licensed products will give 100% fidelity in accessing content OOXML and older legacy Microsoft formats, but if you want a format that anyone including MS Office users can read with 100% fidelity only ODF will do, because other vendor's products can't read OOXML with 100% fidelity.

OOXML will only interoperate fully with Microsoft products or Microsoft licensed products. This is due to the fact that the secret binary content format that OOXML wraps in documented XML is only known to Microsoft, and so although with a lot of work, others may be able to reverse engineer access to some of the content, it isn't going to give full fidelity. On the other hand ODF is fully documented, and so any document in ODF format can be interpreted with full fidelity by any vendor's application, including Microsoft. Of course Microsoft has resisted including an ODF plug-in, and may well supply a deliberately broken ODF plug-in with MS Office in order to discourage use of ODF precisely because it breaks vendor lock-in, but that is an anti-competitive act by Microsoft, not a fault of ODF, and there are third party plug-ins available.

4) If you want a VENDOR NEUTRAL format, then mandate ODF.

As explained above OOXML can only be read with 100% fidelity by Microsoft or Microsoft licensed products because content is stored in secret and proprietary Microsoft formats.

Also OOXML is patent encumbered, and the patent covenant will not cover revisions eg. to fix bugs, or the next version of OOXML. This means that competing vendors cannot reverse engineer OOXML's bug fixes as they did in the past with Microsoft's binary formats as this would be illegal, and any revised versions of OOXML will be less interoperable and more tightly locked into Microsoft than Microsoft's binary doc, ppt and xls formats.

What this means that OOXML, is more tightly locked into Microsoft than any previous Microsoft format.

All this means that using OOXML mandates Microsoft or Microsoft licensed products, and mandating ODF mandates vendor neutrality. Government departments are subject to rules that ensure vendor neutrality in specifications is maintained, and need to keep this in mind when adopting standards.

5) If you want the office suite for INTERNAL USE ONLY, you are not NOT BOTHERED ABOUT VENDOR LOCK_IN, NOT BOTHERED ABOUT 3 YEARLY FORCED UPGRADE, and rather than create new documents which you need to archive for more than five years, you ONLY NEED TO READ LEGACY MS DOCUMENTS WITH VISIO DRAWINGS AND VBA MACROS, then you want OOXML.

The comments on this article make some very good points, especially those about the author needing to test for himself and not simply rely on what is said by the parties he's interviewed. At the least he should seek out a non-biased third party to try to get some perspective. Will the author do a follow up to this article addressing the concerns expressed in the comments? Is there some reason that the author does not appear to have a by line in this article?

A large issue regarding the backward compatibility that you want is that even as large as the OOXML standard is, there are many places where it simply requires backward compatibility without providing any details on the old formats, making it impossible for anyone other than Microsoft to fully implement the standard. Until Microsoft opens up the formats for all of the older versions or the backward compatibility is dropped from the standard (which hopefully ISO will do if they choose to accept it at all), the standard cannot be considered open and everyone who adopts it will be accepting the Microsoft lock-in that Microsoft desires.

On behalf of the OpenDocument Format Alliance (ODF Alliance), I have to take issue with this column.

First, this debate between ODF and OpenXML is not merely a battle between two competing businesses. This is a debate over much more fundamental questions with broad ramifications for governments and their citizens around the world. How these questions are answered will create a lasting shift in how governments operate and interact with their citizens. The answers will impact how emergency personnel are able to communicate in times of crisis. And, more fundamentally, they will determine how we preserve vital information for generations to come.

The technology community is firmly behind the belief that one true open standard must be maintained. This is evidenced by the exploding membership of the ODF Alliance, consisting of more than 400 member organizations from 50 countries world-wide, including a wide-range of companies and organizations of all sizes including the American Library Association, City of Bloomington, Indiana, Sun Microsystems, Novell, Oracle, Google, and Red Hat to name just a few. This large, diverse community shares the common goal of promoting and advancing the use of ODF because it is the only genuine vendor-neutral, open standard
specification free from royalty and restricting encumbrances.

And contrary to the point made in this column, ODF does support spreadsheets. However, Microsoft's own OpenXML isn't compatible with Microsoft .doc, and today's Microsoft documents are not even automatically compatible with older versions. Indeed, it is exactly this sort of confusion that ODF will, once and for all, eradicate.

Hi, anybody knows about the difference between the two formats in context of digital signatures? Do they support XMLDSIG or any other signature formats?

Thanks
M.D.

The debate should actually be on merits / demerits of any standard. MS is known to prefer lock-in of users to their application - which is contrary to public interest of interoperability. By guarding even a minute detail on the OOXML specification, MS has ensured that it can't and should not be accepted as a ISO standard.

@ M.D.

There is support for XML-DSig in ODF 1.2, but not in the currently approved ODF 1.0 or in currently submitted ODF 1.1. OpenOffice.org already uses XML-DSig. KOffice 2, part of KDE 4, also uses XML-DSig. So, there will soon be interoperability between at least two applications suites using XML-DSig later this year.

Thank you, Robert!

any specs available for early birds? We'd like to join the project and integrate our XAdES signatures in ODF. Need more info about the XMLDDSIG contrainer files. Please advise us. Thank you!

M.D.

Ephraim,

(May I call you Ephraim?)

I don't know how good that lunch with Microsoft's PR people was, but it was expensive! They may have wined and dined you for free, but it seems to have cost you your credibility.

This is not a battle between Microsoft and IBM.

Microsoft likes to portray it as such, probably because they want to try and narrow the scope of debate from international standards to a simple commercial competition.

OOXML is a 6000+ page specification that is incomplete, fails to re-use existing specifications, and defines practices that are quite questionable in modern application programming.

As evidence for the first allegation, I repeat the point that the specification says some parts of documents should be "formatted as Word 95 did", or perhaps Word 97 in other instances. Yet at no point is it explained exactly HOW these previous versions of Word formatted the document, or what this means. That is plainly inadequate.

For my second allegation, failing to re-use existing standards, I would direct you to how OOXML handles dates in spreadsheets. Not only does OOXML ignore existing ISO date standards, but it actually asks you to duplicate bugs in Excel by pretending that 1900 was a leap year. In effect, rather than fix their application when building an open standard, Microsoft have instead decided that everyone else must reproduce their bug. I'd like to know how you think this is defensible behaviour for a suggested international standard...

For my third allegation, defining the use of practices that are at best questionable, I would remind you that OOXML uses bitmasks in its document formats. No current XML tools can handle bitmasks. Bitmasks are a legacy programming method of getting one number to represent many potential options by toggling individual bits in the number on or off. If you have used XML, then you will realise that bitmasks - opaque and sometimes platform-specific due to endian-ness - are the very antithesis of XML's goals of files that have sensible sets of tags that could be almost self-documenting, or at the very least obvious in purpose to those handling the files.

Given these three failings, an ungenerous critic of OOXML could make the case that OOXML simply appears to be the binary file formats for Office applications - but using XML tags instead of binary flags where possible.
OOXML's biggest flaw is that it has little defence against such an allegation.

Actually, that's not true. Its lack of defence against the accusation is its second-biggest flaw. Its biggest flaw is that Microsoft appears to be doing nothing to answer such criticisms as those I have given here.

Yes, ODF does not have a standard within it yet for formulas in spreadsheets. Yes, this is a fairly major ommission - but it is an ommission that is being handled right now. A specification is on the drawing board. It is being worked on in an open and multi-vendor manner.

Where is OOXML's similar handling of the criticisms laid at its feet?

OOXML is not fit for purpose. It will not be fit for purpose until it is divorced from the behaviour of the applications that Microsoft made it for, simply because it asks the rest of the world to try and clone Word or Excel rather than interoperate with Word or Excel.

If you cannot see why that makes it an unfit standard, then you will not regain any of the credibility you have lost with this piece.

The ball is in your court now, Mr Schwartz. I await your response eagerly.

Yours,

Philip Storry.

Re: Comment above from Philip Storry --

No, I did not accept a lunch from Microsoft. And as far as my track record goes I criticize Microsoft far more often than I praise them. My record speaks for itself. Do a search on my name and Microsoft and I think you will see that I am right.

As to the ins and outs of ODF versus OpenXML, I admit I am no expert on the subject. I never tried in the blog to say I was. I kept repeating so and so says this and so and so says that. I also qualified what what I had to say, by saying the following,

"If what Robertson and Paoli say about OpenXML and ODF is correct, then I think OpenXML is needed, at least until ODF becomes backward-compatible with older Office file formats and offers the capabilities large organizations require in their productivity solutions to run their business."

Truth is I get the impression that those who favor ODF are not impartial. They seem to gloss over its shortcomings but come down very hard on Microsoft's. Is ODF perfect? Did somoone at ISO buy you a good lunch?

I am glad you are willing to admit that ODF has shortcomings in how it handles spreadsheets. Although you don't address the other issue about how ODF can identify data types to handle integration issues.

However, the real problem with dong a column like this is I could have called IBM back and said this is what Microsoft said and asked for their response. Then I would have to call Microsoft back and say this is what IBM said what is your response.

At some point the debate has to be cut off. I did it sooner rather than later. However, I got the debate going as you can see from all of the comments above. And I think that alone has value.

You're right, the ping pong game could go on all day. But a couple of facts could have been checked into a bit further. For example, Microsoft notes that Dataviz has implemented OpenXML. According to Dataviz's website, the only code shipping is something that supports viewing Office 2007 documents. That's a far cry from implementing full round-trip edit and save support. Dataviz does promise that it is coming, and I'm sure they are working hard on doing it. But until they ship, they can't be held out as an example of "an implementation".

That opening paragraph seemed off-kilter to me, too. While I understand that open source is a large part of IBM's business strategy, I don't associate ODF with IBM. Sure, IBM is a member of the ODF Alliance, but so are hundreds of other organizations. ODF is open source and as such, is part of IBM's strategy.

The key line is at the end where Ephraim buys Microsoft's brand of spin: "...If what Robertson and Paoli say about OpenXML and ODF is correct, then I think OpenXML is needed, at least until ODF becomes backward-compatible with older Office file formats and offers the capabilities large organizations require in their productivity solutions to run their business."

Thus he just missed the whole point of ODF.

Hello Mr Schwartz,

I understand your position, and this is often the level of understanding one gets after interviewing (or being persuaded) by Microsoft spokespeople. It is common even for experienced journalists such as your good-self to be convinced by Microsoft's seemingly valid arguments.

However here are some counter arguments which you can internalize and investigate further. I hope this will help in your future articles.

1) The name OOXML is accurate. The full name prior to Ecma's standardisation is "Microsoft Office Open XML" (MSOOXML). After Ecma it became: "Ecma Office Open XML". So the commonality lies at "OOXML".

Calling it OpenXML is vacuous if not misleading, because if you read through the spec it is not entirely "Open" nor is it the XML as we are used to.

So OOXML or MSOOXML is a suitable name for the standard.

Additionally I think MSOOXML is more accurate as the purpose of the TC in Ecma was to create a specification to mirror the functionality of the Microsoft Office productivity software. So at this point in time, until Apple or Novell introduce functionality from their office software reflected in this spec, it should be called MSOOXML - Microsoft Office Open XML format.

2) MSOOXML is not backward compatible either. It does not support Macros. A huge resistance to migrate from MSOOXML to any other format is due to the binary nature of spreadsheet macros (even though macros are written in text). Even Microsoft is finding difficulty in this migration from the old binary .xls to MSOOXML + Macros (.xlsxm) on the Macintosh platform.

Additionally, the legacy tags (lineWrapLikeWord6) are not defined. This serves no utility in the reference document.

3) The formula issue is completely over hyped. ODF v1.0 specifies clearly how formulas are described in the file, (namespace:"formula( [.Address ] )") but it was agreed that the formula functions themselves should be defined at a later version.

What is a formula function list? It is basically a printout of the Help file! This is what Microsoft contributed for MSOOXML.

Not convinced? Press F1 in a spreadsheet cell and compare that to the MSOOXML spec. It is virtually the same.

ODF v1.2 has all the fringe cases, test cases, backward compatibility, inclusive, multiple implementation notes, mathematical accuracy and a forward looking specification without the legacy baggage.

It is far more valuable than the MSOOXML "help file" specification.

You can verify this by downloading the draft ODF v1.2 at the OASIS website.

4) Consumers do not want choice in standards. See what is happening with Blu-Ray and HD-DVD. There is market confusion between the two competing standards with little innovation. Consumers however want choice in Applications of one single standard. Perhaps Microsoft should give choice to its consumers by implementing ODF as a native file format.

Why is Microsoft limiting choice? How can an open source product (OpenOffice.org) be more feature rich than a proprietary product (MS Office)?

5) Other software will support MSOOXML. But how many will use MSOOXML as its default file format? Only MSOffice 2007? Will Corel change their default file format from .wps to .docx? Will Gnumetric change theirs to .xlsx?

Compare this to ODF. OpenOffice.org uses ODF by default. More amazingly, KOffice which historically had their own file format, will now use ODF as its default file format. AbiWord will also ODF in the future. So it is one thing to "support" a certain file format, but it is a whole different thing to make that file format one's product's native format.

This I think is a powerful case for the vendor neutral file format in ODF.

I hope this helps in your future articles on this topic.

yk.

Maybe I'm a "biased ODF supporter", but I was quite shocked by some clearly untrue statements I found in the article. Fortunately, a lot of people did a good job in commenting the article and re-establishing the truth.

That being said, I notice that not a single comment is supporting Ecma OOXML, while quite a long list of people took time to correct the inaccuracies related to ODF (this shows once again that it is not "a battle between IBM and Microsoft" : a lot of people with no links at all with IBM are pushing the ODF standard).

So, where is the "growing community of people who care deeply about OpenXML", as touted by Microsoft's Brian Jones (http://blogs.msdn.com/brian_jones/archive/2007/05/08/openxml-community-growing.aspx) ?

What a shallow article that spends more time distilling juicy PR quotes than trying to do any form of investigation.

It fails on technical analysis. I fails on market analysis. It just echoes vendor spin for people that don't want to check facts but don't want to admit they know nothing about the problem either.

ODF was derived from StarOffice internal format and to this day SUN's StarOffice and its open source variant OpenOffice are pretty much the reference ODF implementations (nor are they the only ones).

And this is reduced to a workplace vs Office battle? Anyone but Microsoft would tell you that's a laughable approximation of the truth (bordering on plain lie)

Mr. Schwartz,

DO you consider my comments make me a 'biased ODF supporter?'. I have tried to make comments that are accurate and that I am willing to defend. This is why I am willing to put my name on my comments. I have backed up my claims with first hand experience with Microsoft Office, OpenOffice.org and KOffice. I have also attempted to programatically generate the document that conform to these standards. This is actually easier on the ODF side, as the code used in the open source programs is available and it works well under any OS. Where are the OOXML tools that I can use to quickly knock off something simple like mailing labels using an Avery supplied template?

My criticism of this article is that is is superficial to reduce this issue to MS v. IBM. With this reduced to a battle of titans, you then achieve fairness by letting both side use you to spin. You allowed demonstrably false statements to be published. Does accurately quoting an inaccurate statement help your readers form accurate understanding of this issue? I wanted to point out factual errors. If you don't like the comments that point out errors, do the fact checks before you publish demonstrably false statements.

An interesting discussion, this. I recently retired as CIO of a company, so I have some grey hairs and perhaps some insite that the technical discussion here misses.

I don't like Microsoft any better than most and I agree that they have done some pretty anti competitive things including documentation that says nothing, twiddling bits and hiding specifications.

That is all true. It is also not revelent to the vast majority of all computer users.

How many of you can think back to the 1960's when there were much bigger ishues. A DEC computer could not exchange data with an IBM computer which could not exchanged data with a Burrors computer which could not exchange data with a Spery Rand. Yes there was sort of a exchange format, but it did not work.

In the 1970's if you had a Wang word processing program, you could not send your file to your attorney who used Word Perfect, and what about your Electric Pencil file? There was no such thing as interoperability or file sharing.

As much as I dislike Microsoft, they have done one very important thing. By their sheer size that have crammed defacto standards down everyone's throat. Today we think nothing of sending an e-mail to another person. It will get there and be readable on their computer.

American business would still be in the dark ages were it not for Microsoft. Love them I do not. Respect them for the interoperability they have given us I do.

I truly do appreciate all of the technical assessments you have all written about here. They are important and the debate is a healthy one. But corporate america neither cares or understands. They have a standard, and by and large it is Microsoft.

You know what really is amaizing is that IT works as well as it does, and we own a lot of that to Microsoft cramming defacto standards down everyone's throats.

Dalton, while I agree with you that some of the defacto standards (esp. the operating system itself) have been big successes, you can't give MS that much credit for being able to send e-mail to another person. SMTP was an actual (not defacto) standard 20 years ago, and countless products had implemented it well before MS did anything with it (Exchange's first three releases were X.400-based).

I also don't think that corporate America has forgotten IBM, Oracle, SAP, Adobe, Symantec, and many other vendors. It is the interoperability of certain key standards that allows all these vendors to compete in the market.

you are totally owned by MS... or you have no idea what you are talking about. IT professionals that have to work with whatever thing their clients have want ODF.. clients might not know it but they want odf so they can change whatever they want and still have tech support. you want xls? you want OOXML? alright then... you will have upgrades when MS wants.... you will pay what they charge... you will have no choice later. in Brazil we have the same subject going on... i vote odf, and evryonelse in IT business votes for ODF.

Even it were only a commercial battle, between a monopoly and an underdog, consumers have a benefit in having a more level playing field and more competition. Giving the current monopoly a headstart does not seem the best thing to do.

"However, the real problem with dong a column like this is I could have called IBM back and said this is what Microsoft said and asked for their response. Then I would have to call Microsoft back and say this is what IBM said what is your response."

By writing that, you make it clear that you have bought into Microsoft's framing of the debate. You accept that the only other party to the issue is IBM--a real slap in the face to the other 400-odd members of the ODF Alliance.

P.S.: I *did* enter the security code; then when I previewed my comment your hosting software lost track of it. Would it overburden your host's IT staff to display a note saying don't enter the security code until you are ready to post?

To Ephraim Schwartz,

Using the argument "At some point the debate has to be cut off" as defense for a poorly researched and rather biased piece is not valid.
Claiming past articles show you to be critical of Microsoft just add to the suspicion of this being a make-nice piece. I'm sorry, but that's how it looks from here.
To uncritically accept statements from MS, a company specializing in spin, shows very poor judgment on your part, and, quite frankly makes me question your integrity.
There's nothing wrong with being a Microsoft mouthpiece, but there is something wrong in not being honest about it.

I just wanted to write that I find it quite amusing that so many of the posters here are better informed about this story than the person who allegedly researched it in the first place.

Posted by: Dalton Williams at May 23, 2007 05:05 PM:
"How many of you can think back to the 1960's when there were much bigger ishues. A DEC computer could not exchange data with an IBM computer which could not exchanged data with a Burrors computer which could not exchange data with a Spery Rand. Yes there was sort of a exchange format, but it did not work."

I can, and I am disappointed at your inaccuracies.
DEC did not exist in the 1960s. Neither did Burrors and Spery Rand although there were Burroughs, Sperry Rand, Honeywell, RCA, and some European makes (Ferranti, ICT, Siemens, Bull).

WordPerfect did not exist in the 1970s either.

Data formats boiled down to two: ASCII and EBCDIC, with a relatively straightforward conversion routine between them. Card punch machines and paper tape punch/readers used common coding formats but the interpretation of the contents of the medium did differ. Magnetic tapes however, used common data formats to enable large organisations to exchange data (eg. banks, insurance companies and government bodies).

Standards were already being developed while Master Gates III was still in short pants. As someone else has already pointed out, email and other internet standards precisely do NOT owe their existence to Microsoft, but could have been extinguished if the onslaught of Microsoft's MSN had succeeded.

Business was only in the Dark Ages prior to the 1400s, the coming of the printing press, and Rev Pacioli's development of double entry bookkeeping.

Since I live and work in Australia, I can't say where American business is right now...

However, I have relished the opportunity to add to your knowledge.

You are, no doubt, in the Microsoft pocket, due to lack of information, probably.
First, it is not about Microsoft and (only) IBM.
It is all about a format owned bye Microsoft and a Open Format not owned bye anyone.
Microsoft is a master of screewing up the truth about things like this (or any thruth).

They really want you to think it is a business to business thing, a company to company thing a Microsoft versus IBM question.
IBM is their only weapon of defence in this case.

It is a question about a open format or a closed format "run" bye Microsoft.
It would be sort of funny if IBM supported a closed format owned bye Microsoft.
Sertaily they would support a closed format owned bye IBM.
To day, however, the only logical reaction bye IBM is to support a Open format.
What if you tried for a second to think about what you would support your self.

I must admit I have had the occasional chuckle over Microsoft's IBM-fixation, moreso since Microsoft seems to be drifting into becoming a 1980s style IBM clone, too full of itself to actually get anything done, full of past glories and tripping over its feet in equally glorious style.

That said, I expect ECMA 376 to spin out of control the moment Microsoft introduces some "enhancement" to MS Office that involves altering the way a file is stored in memory - because at that point, ECMA 376 will cease representing it well. And that is the excuse Microsoft uses for not implementing ODF in any satisfactory way. Adding complexity without adding value is generally not a wise thing to do; but that is what the ECMA 376 TC will be faced with, and it won't be a pleasant sight - though it will amuse some people, bet on it!

Anyone who claims they are adding to someone's knowledge by saying DEC didn't exist in the 1960s is a rather sad case.

PDP mean anything to you?

If DEC didn't exist in the 60's, then it is very odd how the first Unix implementation was in 1969 on a DEC PDP-7.

Maybe Unix didn't exist in the 60's either. Well, if you want to split hairs, then it didn't, as it was originally called unics and only became Unix in 1970.

Anyone can make a mistake, but if you purport to be an authority, then get your facts straight.