Linked by Thom Holwerda on Fri 25th Jan 2008 21:31 UTC, submitted by WillM
Microsoft "For years, the poster child of the anti-open source movement was Microsoft, with its proprietary software model. In recent years, however, the company has changed its views, starting an open source software lab to work on interoperability issues. It's even become a purveyor of its own open source-approved licenses. What do these efforts mean? For Sam Ramji, Microsoft's director of open source technology strategy, they indicate the company is 'open' for business."
Permalink for comment 298191
To read all comments associated with this story, please click here.
RE[5]: Interoperability issues
by Jemm on Tue 29th Jan 2008 07:15 UTC in reply to "RE[4]: Interoperability issues"
Member since:

The sad fact is Microsoft is focused around "internal program notations" as a file format - thus OOXML and 6000+ pages of incomplete documentation.

Yes, more or less it can be called memory dumb or data that's serialized into XML. People also often forget that the 6000+ pages includes documentation for three products + common parts like packaging, DrawingML etc. That makes less than 2000 pages/product, which sounds quite realistic for that complex products. When line-spacing is halved, there are even less pages ;)

Also, if you leave some "maybe nobody needs these" -parts out, like say spreadsheet formulas (10 pages in original ODF spec vs. 384 pages in openxml spec), then you of course save many extra pages ;)

I think it is better that there is extra information available than too little. Btw for those complaining the documentation is incomplete; now the obscure "AutoSpaceLikeWord95" etc parts are fully documented (but deprecated as they will be phased out):

"Compatibility Settings - AutoSpaceLikeWord95

There has also been a lot of interest in the Compatibility Settings that include the famous “AutoSpaceLikeWord95” or “truncateFontHeightsLikeWP6”. Ecma worked to provide in this batch the full information necessary to implement all compatibility settings without any dependency on any product. This documentation is provided for the completeness of the spec, but these features should not be used when creating new documents. I’ll discuss the compatibility settings in more detail in my next post."

Fact is, people will support it, implement, and then add new features that don't break the implementation so that others can also be successful at reading the same file even if they don't support the extras.

Ok, I had always thought that ODF aims for full fidelity between products, but if the goal is just to be able to open the same document on different products, then it is easier to achieve. One can't really trust that the document will look exactly the same on all products, but I guess that's what PDF is for.

Even Microsoft will be able to add that level of support for ODF to Office easily (ODF was standardized too late for Office 2007 of which development had already started after O2003).

I'm quite sure Microsoft will officially support importing and exporting of ODF in the next version of their Office as ODF really isn't that big a threat to them technically. Microsoft is more worried that governments etc will choose ODF only because it is ISO (and OOXML is not).

Microsoft, however, likely has no plans of doing that with OOXML - they already implement a number of things in Office 2007 that break its against the spec. So even if you implement the spec as written (all 6000+ pages of it) you still won't be compatible with MS Office.

Sure they will update the Office to support the standard once it gets finalized after comments and updates. With patches and translators current products and Open XML documents can be moved to support the finalized spec, just like .doc files are converted now.

Open XML doesn't require to support all the features in the spec before you can create 100% compatible files. If 100% transferability can't be expected from the ODF, why it should be always expected from OOXML?

Full specs are for those that really want to support all the possible features or some segment specific to their needs. If I wanted to make a tool that reads/writes simple MS Office documents, it wouldn't be much harder than it would be for ODF.

So, one can ignore parts of the Open XML specs that they don't need and still make compatible documents. Just like in ODF the vendor specific extras can be ignored as long as the baseline requirements are met.

Comparatively, implement the 700+ (749?) pages of ODF and you'll be compatible with all ODF implementations. ;-)

As it just turned out in this thread, ODF won't be 100% transferable between products - just the lowest common denominator due to vendor-specific extras.

Also, one still needs to learn and implement completely the referenced standard formats, like SVG and build support for them from the start, since they are extended (see my another post). Already made third-party components won't help, unless sources are available.

After this thread I'm even more convinced it is better there are two formats as they really are for different needs. Combining them would be much bigger mess than asking other party which format they prefer (ooxml, odf, pdf, xps).

I just wish there wasn't so much FUD and hatred between the camps ;) If some co-operation required me to send ODF-documents, I'd just download some translator for the Office - no problem.

Reply Parent Score: 1