Depending on who you ask, document standard harmonization is either impossible or inevitable, anathema or nirvana. Let’s dig a little into this question and see if the two sides are really that far apart.
First note that many JTC1 NB’s raised the issue of harmonization in their DIS 29500 ballot comments last September. Some merely requested harmonization, such as Korea, South Africa, Belgium, Peru, Switzerland, or the Czech Republic, while others in addition outlined ways to achieve harmonization. For example, AFNOR, the French NB stated:
After 5 months of extensive discussions between stakeholders in the field of revisable document formats, AFNOR, in the aim to obtain a single standard for XML office document formats within 3 years, makes the following proposal:
- Split the current ECMA 376 standard in 2 parts in order to differentiate the essential OOXML core functions necessary for easy implementation from those functionalities that are needed for the exchange of legacy office file formats;
- Incorporate the technical comments below and those in the attached comment table submitted to the Fast Track;
- Attribute the status of Technical Specification to both parts;
- Establish a process of convergence between ODF (already standardized as ISO/IEC 26300) and the above mentioned OOXML core. ISO/IEC shall invite parties involved to commit themselves to initiate simultaneously the revisions of the existing ODF v1.0 and the OOXML core in order to obtain at the end of the revision process a standard as universal as possible.
(Note that a Technical Specification, in ISO process, is for proposals which lack insufficient support for approval as an International Standard, but for which publication is still desired. This may be appropriate for OOXML.)
New Zealand’s proposal was similar:
- OOXML should be considered by JTC 1 for publication as a Type 2 Technical Report.
- Seek to harmonize with the existing ODF standard to reduce the cost of interoperability, cost of having two standards, and cost of support/maintenance .
Further, the NB’s of Great Britain, New Zealand, and the United States requested that specific features be added to OOXML in order to improve interoperability with ISO ODF, in total 40 features such as the ability:
- to have more than 63 columns in a table
- to have background images in tables
- to have font weights beyond “normal” and “bold”.
Notably, these were the same features that Microsoft sponsored translator project on SourceForge identified as needed to improve translation with ODF. These are the features that the project noted were lacking in OOXML.
Ecma rejected every single one of these requests. They did not argue that the requested features were unreasonable. They did not argue that the requested feature was not needed. Their argument was that harmonization of the formats was not necessary because there exist tools that will translate between OOXML and ODF. In other words, they rejected these requests merely because they were pro-harmonization, regardless of the underlying merit or need of the feature. Ironically, Microsoft’s conversion tools are restricted in their fidelity because of the lack of these very features.
On the question of harmonization, we are either moving toward it, or we are moving away. There is no time better than the present to harmonize. Waiting will only make matters worse, as we will then need to consider legacy OOXML documents as well as legacy binary and legacy ODF documents. The Ecma response does not move us toward harmonization, but starts down the road toward further divergence, a long and costly divergence.
Tim Bray made the critical observation back in 2005, “The world does not need two ways to say ‘This paragraph is in 12-point Arial with 1.2em leading and ragged-right justification’.”
Microsoft likes to claim that harmonization is impossible, that slapping together the features of both standards would lead to a messy, impenetrable mess. Of course, but only an idiot would suggest that as an approach to harmonization. So why do they always bring that up as their strawman?
A look at OpenOffice and Microsoft Office shows a huge degree of functional overlap. Harmonization starts from looking at this functional overlap – and there is a significant, perhaps 90%+ area where they do overlap – and expresses the functional overlap identically, using the same xml schema. In other words, harmonization identifies the commonalities at the functional level and finds a common representation for that commonality.
It would also be expected that the common functionality between ODF and OOXML would also include a common extensibility mechanism, a way for a vendor to express application-specific features that are outside of the harmonized standard.
The remaining 10% of the functionality would be the focus of the harmonization work, the area that requires the most attention. Some portion of that 10% will represent general-purpose features that we can imagine multiple application supporting. We take those features and add them to ODF. That remaining portion of the 10%, which only serves one vendor’s needs, such as flags for deprecated legacy formatting options, could be represented using the common extensibility mechanism.
Does this sound impossible? That’s not what Microsoft says. Gray Knowlton, Group Product Manager for Microsoft Office, was candid to PC World a couple of weeks ago:
Also, if individual governments mandate the use of ODF instead of Open XML, Microsoft would adapt, Knowlton said. The company would then implement the missing functionality that ODF doesn’t support. However, those extensions would be custom-designed and outside of the standard, which is counter to the idea of an open document standard, Knowlton said.
So we’ve agreed that this approach is technically feasible. We’re also agreed that extending ODF outside of the standards process is not a good idea. So the obvious solution is to extend ODF within the standards process. So, let’s do it! What are we waiting for?
There is no reason why, by a harmonization process, all of the functionality of Microsoft Office cannot be represented on a base of ISO 26300 OpenDocument Format. I personally, as Co-Chair of the OASIS ODF TC, stand ready and willing to sponsor such a harmonization effort in OASIS. So let’s start harmonization now, and avoid further divergence.
My read of NB comments indicates that there is a sizable bloc, perhaps even a decisive bloc, of NB’s who are in favor of harmonization. Lets push on this and articulate a roadmap along the lines of the proposals by France and New Zealand, that accomplishes this.
There is no reason why, by a harmonization process, all of the functionality of Microsoft Office cannot be represented on a base of ISO 26300 OpenDocument Format.
Why bother. Microsoft has already designed a format that does just that.
Perhaps the best approach is indeed to identify two distinct subsets of OOXML, one for future document interchange (OOXML-Clean) and one for legacy fidelity (OOXML-Legacy).
And then replace ODF with OOXML-Clean. There. Now everyone is happy.
Well, EBCDIC and ASCII don’t interoperate completely. They do to a large extent; but what are you supposed to do with [ and ] when getting a C program from a PC to a mainframe. Trigraphs are the usual solution. Also what are you supposed to do if you are Chinese ?
SNA and TCP don’t interoperate completely either. You can make a gateway for email, and another gateway for transaction programs, and so on; but not a general one for everything all the time.
S/360 floating point and IEEE floating point likewise. You lose a few bits of precision on a round-trip, and ‘very large’ numbers might be turned into ‘infinity’.
How is it with VHS videotapes and ISO standard DVDs ? Certainly most DVD recorders aren’t built with integrated VHS tape decks for ‘legacy media access’ .
So getting the ‘single-vendor’ standard to harmonize, or interoperate fully, with the ‘vendor-neutral’ standard might be easier said than done.
What’s the solution if we want to do ‘office productivity’ on our games consoles, our infrastructure computers, our cellphones, our One-Laptop-Per-Child boxes, our Apples, as well as on our Lenovo-type machines ?
Actually OOXML can support a lot more columns in tables than 63 when used in a spreadsheet.
Why would anyone want more than 63 columns in a Wordprocessing document.
Oh wait that is because ODF does not distighuish between tables and related functionality in the wordprocessing part and the spreadsheet part. In ODF every table is actually automatically a full spreadsheet embedded in a wordprocessing document.
“Ecma rejected every single one of these requests [for add elements to achieve interoperability with ODF].
However, since these conversion tools are restricted in their fidelity because of the lack of these very features, Microsoft’s argument is rather weak.”
this is the key in all this DIS 29500 fast-tracking process: ECMA and Microsoft responses are a kind of PR/Marketing/Salesman speech, and not serious, technical sound nor fundamentally relevant to the comment of the NB.
It seems that they are trying to *convince* them ( to get a “yes” vote ) and not to collaborate to achieve a good-enough-for-fast-track specification. Then fundamental problems with DIS 29500 remain: interoperability, unnecessary complexity, implementability, clarity, completeness, consensus, closed development, binary-XML-dump philosophy, etc.
The sad part IMHO is that there are *few* ISO JTC1 P-members really trained and with the necessary expertise to don’t get fooled by this PR-type responses. I see three main groups there:
First group ( with expertise ):
. UK ( BSI )
. Japan
. USA ( in the technical era, before INCITS/V1 MS Gold partner infamous stacking[1] )
. France/Italy/Spain
. China
. Germany DIN ( too political and “corporatized” now, but there are smart guys there, mainly in government agencies and education, but minority in DIN )
Second group( most of them try to do their best but with no deep expertise on the matter, fooling candidates, some without enough guts to confront big corporations like MS ):
. Czech Republic
. Switzerland
. Ireland
. Australia
. Finland
. Slovenia
. Canada
. Denmark
. Ecuador
. Malaysia
. Iran
. Korea
. New Zealand
. Norway
. Belgium
. Netherlands
. India ( guts here, they are confronting MS and rushed standardization )
. South Africa ( guts here, they are confronting MS and rushed standardization )
Third group ( just pawns in the game, very influenciated [to say the best] by the submitter, most of them NBs upgraded by JTC1 to P-member status few days before DIS 29500 setember/07 ballot just to record and “unconditional approve” vote ):
. Jamaica
. Côte-d’Ivoire
. Malta
. Cyprus
. Kazakhstan
. Azerbaijan
. Pakistan
. Lebanon
. Trinidad and Tobago
. Uruguay
. Saudi Arabia
. Venezuela
. Kenya
. Turkey
. Singapore
My wishes:
Long life to openness, well-engineered, consensued, interoperable and implementable formats.
Stop the rushing in standardization.
Incorporate end users and independent interest-groups in this processes.
–orlando
[1] As for Rob’s request for a “smoking gun” regarding the Microsoft partners who are working with Open XML and have joined V1, unfortunately there isn’t one. I contacted a couple of those partners myself, but I just picked up the phone and said “hey, there’s this committee that is discussing Open XML but nobody involved has actually implemented it from the spec and the debate is therefore 100% theoretical, so it would be great if somebody like yourself with actual hands-on experience got involved.”
(
http://blogs.msdn.com/dmahugh/archive/2007/08/30/oh-the-drama-of-it-all.aspx )
Thanks for the reference Rob, but I’m not sure I agree with your conclusion. Any two XML markup languages are (in theory) capable of being ‘harmonized’, but I’m not sure that we’d want to do that. What good will it do to harmonize NewsML and XBRL?
Besdies, harmonizing Open XML and ODF doesn’t create leave you with one standard, it leaves you with THREE. I don’t think it’s as easy as you would make it seem.
>>There is no reason why, by a harmonization process, all of the functionality of Microsoft Office cannot be represented on a base of ISO 26300 OpenDocument Format.<< Hmm, tough one. Any reason why the converse can’t be done instead. Or is it one and the same thing?
Rob-
Having one format: good. Harmonization: laughingly complex.
What are “deprecated legacy formatting options” and why are they needed?
OOXML is a brand new standard so nothing should be deprecated.
Microsoft keeps adding features to MS Office in order to entice people to upgrade. So newer versions of MS Office must be improvements on older versions.
I don’t see why a feature in an older format can’t be converted into the new format without having to retain legacy information.
How many documents would actually be affected by a word on a page shifting left or right a few pixels? Or having a word move to the next page? The document should still be readable.
I remember (circa 1990) when a document formatted for one printer caused the document to reformat when changing to a different printer due to the different fonts and margins available on different printers. Is this still the case? Probably. With downloadable fonts this alleviates the font problem but some printers can print closer to the margin than others.
What about changing the paper size (A4 vs US Letter)?
Minor changes shouldn’t affect the content too much to render the document unusable.
When OOXML 2.0 comes out then features from 1.0 can be deprecated.
Interesting ZD-Net story about what Microsoft revealed in that complaint about IBM killing OOXML (i.e. clearly admitting that their whole revenue stream relies on lock-in).
Okay, so it’s not dead yet, but if they’re pushed to complain like this, it makes me feel better about the odds. The more pressure they’re under, the more they’ll slip up and the more pressure that will create, after all.
@anonymous, Why bother harmonizing on top of ODF rather than on top of OOXML? I think that Microsoft was given that opportunity, when they received requests to add those 40 ODF features to DIS 29500 but refused on every single one of them. They do not seem open to the idea.
@Chris, is harmonization complex? Yes. But however complex harmonization is, translation between divergent formats, on an ongoing basis, from now until eternity, will be far harder and far more expensive. The easiest time to solve this problem is now. Waiting only makes the problem harder.
The way you solve office productivity on cell phones, etc., is via defined and standardized functional subsets which we call application profiles. We would need to define those.
@anonymous, You are misinformed. ODF does not represent tables in a word processor as an embedded spreadsheet. We do have a single table model,but that is a virtue, not a fault.
@orlando, What makes you think there is no smoking gun? Just because I haven’t blogged about it…yet?
@Gray, With that attitude we would never have had any harmonized standards like SQL or C++. Your argument can be used to forestall any progress in any standards domain. On the other hand, you’ve clearly been quoted in the press as agreeing with me, so this is clearly not a technical hurdle for Microsoft, but only a lack of sufficient motivation. Let’s work on the motivation part.
@skc, Same answer as the first anonymous. It appears that JTC1 NB’s attempted this, but Microsoft refused to add to OOXML the very ODF features that their own translator projected identified as missing in OOXML.
@Sam, It depends on how you harmonize. If you attempt to simply mergeat the standards text, or the markup level, then I’d agree, that will be a mess.I wouldn’t suggest that. But bump it up a level and harmonize at the requirements level. And remember, doing this once and achieving a harmonized standard saves us decades of document conversions and the resulting fidelity losses. So it is a worthwhile investment by my estimation.
@jamie, I agree with you on the deprecated legacy features. Most of this work should be done by the application that actually reads the legacy binary formats and writes out OOXML,e.g., Office 2007. It should be doing a full conversion there, not a lazy partial upgrade.
@anonymous, when an adjudicated monopolist, with 95%+ market share, whines and complains about competition and their inability to have “business as usual”, then it is good to breath deeply and smell the irony.
“@orlando, What makes you think there is no smoking gun? Just because I haven’t blogged about it…yet?”
rob, i was quoting a Doug Mahugh post, when he talked about how he phoned a couple of “friends” to share a couple of beers ;-) and by the way vote “yes” at Incits/V1 voting
when i saw this Mahugh’s post i was scared. My god, this is the way that standardization works?!!
If that is the case, then i don’t want more ECMAs , ISOs and the like, they worth nothing to me, to end users and consumers… they are just corporations proxies ( i want technically and well engineered computer standards, i’m a system analyst , i don’t want to see my profession bastardized )
–orlando
In truth there are two conflicting pictures presented on the net.
Actual developers who sit down and try to work with both formats encounter that ODF is better designed and more feature rich than OOXML. With ODF you have a tree that you can transform with regular XML technology and manipulate without to much difficulty. OOXML on the hand give you a chain of chunks that are wrapped in XML. Oooxml is with others words flat and transformation into anything at all require that you reimplement the full parsing capability office including all weird legacy quirks. Microsofts translator project among much similar are actual proof of this.
The other picture presented on the net are the one coming from Microsoft PR people. These people keep insisting that ODF lacks capabilities needed by Microsoft office. Unfortuneatly they never tell what capabilities that are missing or give any evidence.
It is great the Oasis offer to bring order to this mess. Microsoft have lost much valuable time and will without doubt need assistance when the market demand for using ODF keep climbing.
I see four different sides to this two-sided debate.
1. Many people realize that there will eventually be one standard, and only one standard. Of course, that standard will not be the exact same as either contender now, but it’ll probably be a newer version of one of them. Effectively, whether an official harmonization happens or not, the functionality will be represented in that standard, thus there will be harmonization.
2. Harmonization is the logical step. Having two standards is silly. Since we aren’t silly people (I’m not so sure about that), we will, of course, harmonize.
3. We want to make harmonization impossible, because if the standards are harmonized, our product is dead.
4. Various people are making harmonization impossible.
Personally, my thought is, given the stance of the Microsoft crowd on this matter, I think the OASIS should start working on the harmonizing process now. If Microsoft actually wanted to help them, I’m sure Microsoft could provide invaluable assistance. However, judging my their track record, Microsoft won’t. If Microsoft even gets involved, their actual involvement will not help the process – for a universal, open standard for documents ends life as Microsoft currently knows it. The fact that the company could survive it and even continue to dominate the marketplace even in the face of it doesn’t register with these people. As a result, they will continue fighting the inevitable and doom their company to annihilation. (Yes, my prediction is in 15 years, Microsoft will not exist as a software company, and it will be due to their current efforts to maintain their illicit monopoly.)
There will be no harmonization unless Microsoft is forced into it.
Look no further than the recently settled antitrust process. They refused 10 years to provide interoperability information on their network protocols.
European Commission forces Microsoft to open its protocols
Read their recent claims (30 January 2008):
“Let’s be very clear,” he said. “It [the Reject of OOXML] has been fostered by a single company — IBM. If it was not for IBM it would have been business as usual for this standard.”
(from an article written by Brett Winterford, published at ZDNet.com.au)
Business as usual for them, who are used to push things down the throat of others. Well done, IBM! Please keep it up.
But let me cite a little more from their post:
<<"They are doing this because it is advancing their business model. Over 50 percent of IBM's revenues come from consulting services."
A growing proportion of those revenues are being derived from the support of open source software, he said.>>
What does open source, IBM consulting services and business models have to with technical argumentation against a standard?
They claim that ODF promotes “free software” (actually they call it “open source”), although there are a lot of “non-open source” products that happily use ODF, without any twist of business model. I am sure IBM, Google can name quite a few.
So, does ODF support open-source, just by that it does not allow Microsoft to lock-in their users?
“IBM have asked governments to have an open source exclusive purchasing policy,” Tsilas said. What no proofs?
There are, in turn statistical information that many pro-OOXML votes in September have been from corrupt countries.
Corrupt countries were more likely to support the OOXML. So Microsoft uses dirty tactics and then they come out accusing others of it! Now how’s that?
So they they tried every possible trick and now they have come out empty handed.
The trickster has played foul and got defeated. Now they admit it and try to put the blame on people that showed their flaws and ill-doings. Or maybe they admit defeat just as another trick. Who knows, we have to wait and see!
Cheers to ODF interoperability fighters!
@zbog:
you quote one of the most amusing stories from this whole saga.
If you look at adoption by share of Office and Operating Platforms then those same “corrupt” countries that you point to are more likely to choose Linux and OpenOffice as a platform.
Working on your assumtpion, I have to wonder who is paying them to do that? or maybe it is just poorly collerated data, built into a fictional story to serve somebodies purpose?
Rob said:
“So we’ve agreed that this approach is technically feasible. We’re also agreed that extending ODF outside of the standards process is not a good idea.
…
“This common functionality between ODF and OOXML would also include a common extensibility mechanism.”
So we are to take two so-called “standards” that both allow and encourage vendor and application-specific extensions and combine them into one standard that includes a “common extensibility mechanism?”
Embracing, extending, and extinguishing a standard is embracing, extending, and extending a standard, whether it’s Microsoft, Sun Microsystems, or IBM doing it.
While a standard may legitimately include a mechanism for extensibility, in no way, shape, or form should files containing markup not fully specified by the standard be granted “conformant” status as ODF and OOXML both do.
Moreover, neither ODF nor OOXML require that vendor and application-specific extensions be non-proprietary. The embraced and extended standards can permissibly be armored with software patents.
OOXML at least has the courtesy to say that specifications for extensions “should” be published. But ODF offers not even that suggestion and I still see no progress on that ODF TC action item to move the now unspecified OOo-specific document settings into ODF, even though the proposal was added to the TC agenda back in 2005.
What’s missing from this whole discussion is the need for interoperability profiles, with a defined superset profile and defined subset profiles.
Anything outside of the profiles has to be non-conformant or you simply continue the anti-competitve interoperability nightmares the big vendors have for decades inflicted on office productivity software users.
ODF advocates who criticize OOXML on interoperability grounds are throwing rocks from inside a glass house. It’s the proverbial pot calling the kettle black.
“ODF interoperability” is an utter myth. For supporting documentation and links, see http://www.universal-interop-council.org/?q=node/1
Hi Marbux,
I dived into this extensions topic a bit in my interoperability talk at the OpenOffice.org 2007 conference. My recommendation was that the ODF standard define “conformance” as well as “strict conformance”. Strict conformance means that the implementations use only the functionality described in the standard, with no extensions allowed. An application could then run in a strictly conforming mode, perhaps triggered by a UI setting.
You could also have application profiles to subset functionality further, but I think adding a strict conformance mode is the more direct approach to your concern. Application profiles are more for creating a canonical feature subset for a particular purpose. So, ODF Mobile Profile for mobile devices. But even that could have conforming and strictly conforming modes.
But note that there is a blurry line between vendor extensions and user extensions, especially when we get to the level of semantic tagging and integration of business data. Do we want to forbid a user from structuring their data so it integrates well with an internal business process because it makes their document less portable? No,I think the user should have that choice, which means that the applications and the standards need to support that capability.
In any case, you shouldn’t get too excited about the order of action items processing. We don’t do everything in a simple linear order. Some stuff gets taken up immediately, other stuff lingers. Whether the feature was added yesterday, or whether it was added back in 2005, it really doesn’t matter. It is all standardized at once when we approve ODF 1.2.
Regarding the conformance bit…
I believe, ideally, ‘conformance’ or ‘loose conformance’ should only be given to those applications whose extensions are not critical to the document in question. That is, if you can load *any* output of a ‘loosely conformant’ program into a ‘strictly conformant’ program, you should be able to read and access all of the content. The formatting can be bad, but the content should all be there.
Note that this also means that a ‘strictly conformant’ program should not do anything negative in response to extensions; extensions should simply be ignored (although they should also be retained, and shown in ‘view source’ mode.)
Note that in the above, I do not use ‘should’ in the standards sense of should; I believe that the standards should have ‘MUST’ where I have should.
Regarding the direction of ODF and OOXML harmonization: Harmonization should happen in *both* directions. As far as we can tell, ODF is more malleable, so our efforts are probably best directed there. However, in an ideal world, both sides would sit down at the table, and work out a series of changes to both of their formats that would, in the end, result in the two standards being identical. (Actually, in an *ideal* world, this would never have happened, because ODF came first, and MS was on the ODF committee before MS started OOXML.)
Marbux:
First, a disclaimer. I work for IBM. I do not represent IBM. That said, here’s what I think is going on.
‘Nirvana’ for IBM would be a position where they could sell a solution to a government. It might be to the revenue-raising arm.
The IRS would deploy a tax return to the ‘general public’, as an ODF document. Joe Q Public would fill it in, and return it. The IRS would accept the return, zap it up to their IBM mainframe, process it for the immediate commercial purpose, and archive it for evermore or as may be required by local law.
Nowhere in that is there a suggestion that lack of interoperability would favour the solution vendor.
Parts of this are in place already; http://symphony.lotus.com/ can be downloaded at no charge from IBM’s web site. Apart from the proposition that Symphony carries the IBM brand name onto the user’s screen, why should IBM care whether a consumer uses that application or something else that also conforms with the same standard ? It doesn’t affect IBM’s revenue either way.
Now, we understand that other vendors do have different business models, and may well have commercial interests in not interoperating so well; principally, I suppose, vendors who sell products which are used by consumers.
But for vendors who sell products to large businesses and large governments, ‘standards all the way’. Anything else is a side effect.
Chris Ward said:
Parts of this are in place already; http://symphony.lotus.com/ can be downloaded at no charge from IBM’s web site. Apart from the proposition that Symphony carries the IBM brand name onto the user’s screen, why should IBM care whether a consumer uses that application or something else that also conforms with the same standard ?
Well, it would be great if it was as easy as that. But the fact is that it does matter what application you use. The output isn’t the same if you use OO.org and Lotus Symphony.
I have Lotus Symphony Beta 4 and OO.org 2.3 on my computer and ran some tests with the presentation-tool in both applications. I created a presentation with a title slide, one slide with a table (in OO I had to use a spreadsheet object since OO doesn’t support tables in presentations), one slide with an animated draw object and one slide with an animated text-box. I also used one of the standard slide transitions. I saved both presentations in the standard ODP file format.
Ok, here’s what happened when I opened the Lotus presentation in OO:
The text formatting and colours were preserved. The table was converted to an invisible OLE-object. I had to double click on it to edit it as a spread sheet in OO. I had to manually resize the object to try to resemble the table, I had to reformat the text and justification, and had to manually set the cell background to none so the slide background would be visible.
The draw object looked the same in OO but the animation was gone. No sign of it at all. The same happened to the text box. It looked the same but no animation.
The slide transition was preserved but the effect was interpreted differently in OO.
Ok, so far but not so good.
Then I opened the OO presentation in Lotus. All formatting and colours seemed to be preserved. The spreadsheet object was also preserved and behaved the same way in Lotus as in OO. The draw object looked the same, and the animation was preserved. Good! But: The text box looked fine in normal view but in slide show view it was gone. No sign of it at all. The slide transitions worked well though…
So, you say it doesn’t matter what application someone use. I say it does. It matters a lot.
And please explain this to me: Sun and IBM invests lots of time and money to create the ODF standard. And then they spend more money creating one application each that use the same ODF standard. And even then you can’t get it right? Can you blame me for telling my customers to stick with Microsoft Office for at bit longer?
Funny, but why didn’t you push for this during the ODF development? Why now?
According to the controversial writings of Gary Edwards Sun was actively hostile to any attempts to harmonize ODF with Office, that they actively fought against anything that could be considered “office compatible”. What makes you think they’ll allow it now?
@Nobody,
Remember, during the development of ODF (2002-2005) there was no OOXML specification, not even in Ecma, and there was no publicly available binary format documentation for the legacy formats. So what exactly were we supposed to harmonize with?
As for Gary’s conspiracy theories, I’ll just note that Sun has produced a real, working ODF Plugin for MS Office whereas, Mr. Edwards for all his talk about interoperability has failed to produce a working version of his daVinci plugin. So I ask you, who is against Office compatibility: the company that delivers a plugin, or the man who just talks about it?
@Fredrik,
It is beta software. Expect some bugs. The first beta release of Lotus Symphony was just a few months ago and we have already released 3 beta updates. I use it on a daily basis and use to exchange documents with people at other companies using OpenOffice without problems. If you mail me your specific document, I can pass it on to the Dev team to look at.
I get the feeling from reading some of these comments, that I was right when I said last year that this whole file format kerfuffle was actually an attempt to define what an office suite is.
That said, it’s obvious why Microsoft won’t tolerate any movement towards harmonizing the MS Office specification and the ODF standard. It takes the initiative away from Microsoft, and forces it to behave in a manner quite opposite to “business as usual”.
But the fact that even Microsoft didn’t make any opposition to the standardization of ODF says this: there wasn’t anything they could say. The Office Suite is now one of the best-defined software packages now. Microsoft is now caught in a trap of its own making.
So perhaps what the ODF standardization effort should be looking at is including a set of optional “unique to MS Office” extensions, similar to what OO.org does with a decade’s worth of .DOC, that makes OO.org a much better tool for recovering old .DOC than anything Microsoft currently has on offer.
Microsoft really doesn’t have much to offer in terms of standard harmonization, and there’s nothing to say they won’t treat their current “standard” in future as a minor inconvenience.
About Open Office interoperability with MS binary formats:
This morning, MS Word corrupted a document on which I was working. When trying to re-open it, MS Word went in an infinite loop. The work of several days were lost (I had just erased the security copies I’m used to keep to protect against such MS Word behaviour)…
In a desperate try, I opened the document in OOo Writer, saved it again in .doc format, and tried to open the new copy with MS Word.
Result : MS Word happily accepted to work again with the document. To my big surprise, NO formatting was lost ! I just had to delete some strange styles that were not visible before (and which apparently were causing the infinite loop in MS Word).
So much for the “non-interoperability” claims of Open Office !