Response to"ACME 376" has been strong, as we had hoped.
We have fielded some very useful questions at the OpenDocument Foundation as well as quite a few sample documents from enquiring customers. Let me address this one immediately...
How does the plugin cope with features from MS Office that are represented in the legacy .doc files that OpenOffice.org, for example, cannot handle?
This is a question about document format compatibility with different appliations. If viewed from a more holistic point of view, it's a quesiton about system interoperability around a document format.
Yes, there are features in MS Office applications which are represented in the .doc format which OpenOffice.org does not duplicate. (And it is reasonable to assume that there will always be some form of feature mis-match between applications. Life isn't perfect.)
In short, the da Vinci ODF Plugin for MS Office loads into your Office | Windows installation (precisely as you have seen it can in your testing work with "ACME 376"). da Vinci intercepts the in-memory representation of a (working or outputted file), sends it through the da Vinci ODF conversion engine and tags the elements in the file that OpenOffice.org does not recognize with a special tag. Such a tag preserves the information so that the file can go back from ODF to its original format back in the Microsoft application where all the data will have been preserved & where it will be recognized there. This is what we call a "high-fidelity round-trip".
One day, when applications are ODF-Certified through an automated system (which we have yet to develop), high-fidelity round-tripping will be the standard practise and will work successfully for infinite round-trips across any & all Certified systems. Meantime, round-tripping needs to be minimized because standardization around a single format is so immature.
(Please keep in mind that da Vinci files that are generated/originated in ODF cannot be viewed in the current OpenOffice.org v2.0 [which is compliant with ODF spec v1.0] because da Vinci is designed to work with ODF specification v1.2, which is due to be represented in a version of OpenOffice.org later this year.)
I hope this general example indicates how the Plugin is faithful to the FORMAT of the original document, that the incompatibility is with the APPLICATION. It is the very best and all a format can do until the application is designed to deal successfully with specific features. (Unrecognized elements will iteratively be recognized as application development moves forward. If your organization has specific features or elements requiring mapping into OpenOffice.org, then the OpenDocument Foundation can engage with you to write an effective spec to have the work done if the OOo team is not responsive.)
As you know, feature mis-match is a problem that arrises when working with legacy files which is not a real-world problem when files are generated/originated in the ODF format in MS Office or OpenOffice.org. The example above permits us to say "perfect fidelity" because the integrity is total at the format level -- if an application cannot read an element that's represented properly in the format, that's the application's fault.
If applications are not made to be compatible, then in this open source world it is incumbent on the customer to make sure the work is being done to satisfy the requirement. This is why the ODF Tool Kit is critical and needs to be funded too.
FYI, on the ODF-compliant server-side, the OpenDocument Foundation is also working on the ODF InfoSet API & SDK which is targeted to businesses seeking to integrate da Vinci-quality ODF capabilities into web applications, for example, in the office 2.0, the messaging and the CMS areas. Are you listening Google, Zoho, JotSpot, Alfresco, Zimbra & Lotus Notes?
da Vinci as you know was made to address the requirements of Massachusetts ITD.
This is a generalized response to a question that deserves a detailed explanation using real-world examples. We'll be in the best position to have a productive discussion of document compatibility and system interoperability with you if you send us sample documents that represent compatibility issues for you.