OSNews

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."

http://blogs.msdn.com/brian_jones/archive/2007/12/21/500-national-b...



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).



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.



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.