Alex Brown has a write up on interoperability. A good write up. It starts with a general description of application interoperability and progressively narrow it down to document format.
He concentrated on what Microsoft can or cannot do but neglected to say what others have to do to make it happen. They can help, or throw a spanner into Microsoft’s hard work. That is the only major criticism I can level at him, i.e., an apparent failure to mention interoperability is mainly a two way street. If the other party does not want it, there is just so much one can do before hitting a brick wall. More on this later.
One other minor thing I disagree is the characterization that ODF 1.0, ODF 1.1 and ODF 1.2 are different standards. The latter two are evolution of ODF 1.0 in OASIS. The saying that OASIS ODF and ISO ODF is different is fair enough, I will accept it. I wanted to launch into a tirade of how little difference between the OASIS ODF and ISO ODF is compared to ECMA OOXML and ISO OOXML when I first read it but when I cool down I decided the correct thing is to accept them as different for one important reason: OASIS ODF had moved on to 1.1 and major vendors are supporting, or plans to support 1.1 which is definitely different from ISO ODF.
I believe this line of attack is also a bit unfair. Microsoft definitely is cooking Microsoft HomeBrew OOXML version 1.x. Since this is done in private, the same way most proprietary standards are, we cannot point the finger specifically to a ISO/ECMA OOXML 1.x in the making. To point the same finger at a new version of ODF (version 1.2) in the making as a “new” standard simply because it is done in the open is unfair. If I am critical, the existence of a maintenance regime means SC34 is brewing ISO OOXML version 1.x
[When I wrote the last paragraph I realize one potential significant difference between ODF and OOXML in terms of the maintenance region is emerging: ODF evolution is going to be done in OASIS, bar a successful snatch by SC34 of ISO to bring it “in house”. This already means ODF 1.1 is not an ISO sanction version and the same can be said for other ODF versions, unless it is brought back into ISO. With OOXML, since SC34 is said to be in charge of maintenance, it can claim it is ISO sanctioned all the way through. This can open up a lot of FUD. In real life, I do not think there is going to be much different coz we can still rely on the professionalism of JTC1 committee to not put unnecessary hurdle if OASIS come back for ISO backing for new ODF versions]
Back to interoperability. As I had said, it is a two way street. However, in the past and in the present, they seems to be one way street. Before ODF, Microsoft does not want to cooperate. It unilaterally published its own format and let others scrambled to interoperate with it. After Massachusetts deliver the shock to this way of working, and as this debate become more and more interesting, we see a shift in balance-of-power where now it is the ODF vendor camp that refuses to support ISO OOXML [I don’t count one-way conversion, i.e., OOXML to ODF but not vice-versa as interoperable]. The claim of “interoperability” is hollow, from a document format point of view, if only one application, i.e., Microsoft Office can read/write both OOXML and ODF natively [caveat: This had not happened yet]. Did Microsoft know this? Yes, at least a year ago. Why else would they stipulate in the contract with Novell that Novell has a deadline to deliver OOXML write ability in OpenOffice.org and deliver it in their SuSE product?
Astute reader will realize that when I discussed interoperability above, I focused on application, not file format. From a user view point, there is no difference between application level interoperability and file format interoperability. From a technical view point, there are. Being a file format expert, Brown would naturally prefer to see interoperability at the file format level. It has its merits, chief among them, you have a formal, one-to-one mapping from one format to another. I, however, is not sure this is needed. The fact that both represents the same thing at different level of details means we can never achieve one-to-one mapping. Best way to give maximum chances of a document looking the same is not to cross boundary (OS, application, file format) if possible, once you cross it, be prepare for some incompatibility.
Moreover, from a user point of view, it is the asthetic that counts and asthetic is delivered by application mainly, not document format. If the application I use is only capable of positioning my table to an accuracy of 1 cm I am bound to find that my document look different in that application and also being saved differently. I rather leave file format conversion to the application.