What’s distinctive about the goals of OOXML? Primarily, to have full fidelity with pre-existing binary documents created in Microsoft Office. “What people want is to make sure that their billions of important documents can be saved in a format where they don’t lose any information. As a design goal, we said that those formats have to represent all the information that enables high-fidelity migration from the binary formats”, says Paoli. He mentions work with institutions including the British Library and the US Library of Congress, concerned to preserve the information in their electronic archive.
I asked Paoli if such users could get equally good fidelity by converting their documents to ODF. “Absolutely not,” he says. “I am very clear on that. Those two formats are done for different reasons.”
What can go wrong? Paoli gives as an example the myriad ways borders can be drawn round tables in Microsoft Office and all its legacy versions. “There are 100 ways to draw the lines around a table,” he says. “The Open XML format has them all, but ODF which has not been designed for backward compatibility, does not have them. It’s really the tip of the iceberg. So if someone translates a binary document with a table to ODF, you will lose the framing details. That is just a very small example.”
Gary Edwards (343)
marbux (24)
Jesper Lund Stocholm (9)
mazyar hedayat (4)
The bottom line for Microsoft has not changed. MOOXML exists because of the need for an XML file format compatible with the legacy of existing MSOffic ebinary documents. He claims that ODF is not compatible, and offers the "page borders" issue as an example.
Page borders? What's that got to do with the ODF file format? These are application specific, application bound proprietary graphics that can not be ported to any other application - like OpenOffice. The reason has nothign whatsoever to do with ODF and everything to do with the fact that the page border library is bound to MSOffice and not available to other applications like OpenOffice.
So here is an application specific feature tha tJean Paoli claims can not be expressed in ODF, but can in MOOXML. But when are running the da Vinci ODF plugin in MSWord, there is no problem whatsoever in capturing the page borders in ODF!!!!!!!!!!!!!!!!!!!!!!!!!!! No problem!!!!!!!!!!
The problem is opening up that same da Vinci MSWord document in OpenOffice. That's where the page borders are dropped. The issue is based entirely on the fact that OpenOffice is unable to render these MSWord specific graphics bound to an MSOffice only library.
If however we take that same page border loaded da Vinci MSWord document, and send it half way across the world to another MSWord desktop running da Vinci, the da Vinci plugin easily loads the ODF document into MSWord where it is perfectly rendered, page borders and all!!!!!!!!
Now i will admit that this is one very difficult issue to understand. If not for da Vinci, we would have to take Microsoft's word that they can't capture those sacred page borders in ODF so therefore they must invent their own XML: MOOXML.
But hey, this is Microsoft. Who in their right mind would take them at their word?
The problem is that one first has to invent an "internal" ODF plugin for MSOffice to prove that Microsoft has it wrong (okay, i'm being kind here :) And inventing such an internal plugin is one daunting and difficult task. See, the only way an ODF plugin can work "internally" would be to be able to convert perfectly between MSOffice in-memory-binary-representations and ODF.
This involves the perfect fidelity conversion of those infamous billions fo binary documents to ODF.
Since Microsoft fully understands and owns the complete blueprint for those billions of binary documents, they can perfect the conversion to MOOXML. But without this secret knowledge, it's near impossible for anyone to match this feat; as in converting those same documents to ODF XML.
This isn't the time or place to explain how da Vinci does it, but it does. The larger point here is that Microsoft intentionally confuses ODF the XML file format with OpenOffice the office suit application. They take a binary MSWOrd document with page borders, and import it into OpenOffice using the OOo reverse engineering conversion filters. Then they save the document as "ODF". And of course it's a mess. The page borders are no where to be found.
Is this an OpenOffice problem? Or a problem for ODF?
Without da Vinci one would have to say it's probably a little of both. The truth however is that this is entirely a OpenOffice problem. The truth is that ODF can handle ANYTHING MSOffice has to throw at it.
We know this because we see what da Vinci can do.
To most people it makes sense that applications with different features would of course need different file formats able to capture those features. Especially advanced features.
But that's only true if the fiel format in question lacks the needed flexibiltiy. Maybe MOOXML does lack that kind of extendable flexibility. But it's not true of ODF!!!!!
An incredibly extensible and flexible model was built into ODF exactly for the purposes of being able to handle anything MSOffice documents could throw at ODF. And while it's true that by nature, XML is rigid, hard coded, with a strictly structured and inflexible hierachy, ODF was designed for near infinite flexiblity. It's all there, but it's not something Mcirsoft wants anyone to know about or understand.
~ge~