I think the observation was that ODF was not designed with interoperability with Microsoft in mind. In fact, that case was officially excluded, although the work on OpenFormula in ODF 1.2 was designed to accommodate Excel and had participation of Microsoft experts.
The folklore about all of this does not account for improvements that have happened over time. For example, it is no longer the case that Office does not support what is called strict OOXML, after using transitional originally and also still supporting it (but not as the default output as far as I can tell). That there were migration steps was certainly an important legacy consideration for that product. Although not involving such a large user base, the same applied with regard to the Star Office formats supported as legacy in OpenOffice and ensuring that legacy prospect in the design of ODF too. (The ODF project was originally named the OpenOffice project, with the change made at the last minute for ODF 1.0.) It is a misunderstanding to assume that there is some "strict" ODF conformance requirement. That is factually not the case, nor does anything in the specification require some clear conformance for interoperability. I daresay that *no* implementation supports the full features and details of ODF, and there is no requirement that *any* implementation do so. In addition, there is extensive under-specification of some features (e.g., nothing about macro languages [;<), with many implementation-defined and implementation-specific holes. What worked for a time was using OpenOffice's support, whatever it is, as what others attempted to match in regard to supporting ODF in an interoperable (with OpenOffice) manner. That is no longer a workable guide as OpenOffice and LibreOffice extensions and feature differences increase in support of the ODF format. And OpenOffice does not participate in the work toward ODF 1.3 at OASIS, although that may not matter in the long run. ODF may simply become whatever LibreOffice does, just proving that any open-format standard can become a silo. The legacy Microsoft Office formats are documented and those documents are freely available and are used. That extends to RTF as well. Meanwhile, there are many undocumented uses of ODF, including of binary formats inside ODF documents. It really is a matter of "choose your poison." - Dennis PS: The ODF specification is not tight enough for what many seem to automatically presume. For a technical analysis of that, I have a free-to-download technical paper that walks through how it goes, with the failures of change-tracking as a case study: <http://nfoworks.org/rct/>. Click on the title "Tracked Changes" for the free PDF. Sections 1-2 should make the situation clear enough. > -----Original Message----- > From: Hagar Delest [mailto:hagar.del...@laposte.net] > Sent: Sunday, October 2, 2016 12:57 > To: dev@openoffice.apache.org > Subject: Re: <DKIM> In regards to Open Office > > Le 02/10/2016 à 19:29, Xen a écrit : > > Jörg was only mentioning that the ODF format was also designed without > compatibility in mind, and that it is an equal situation. > > I think that ODF was designed to be a fully open standard to give the > users back the property of their own data. This was to give users an > alternative to the proprietary formats like .doc, .xls, ... > The problem was that legacy file formats (.doc, .xls, ...) could not > allow intercompatibility between software. Hence the need of an open > standard. > > By design, there should not be any compatibility aspect in an open > format : if the file format is fully documented, then each software > should respect that format and then the compatibility with other > applications will be achieved. > > But [MS Office] OOXML is not what we could label a real open format. > There are parts that still refer to proprietary bits. Therefore, the > situation is not that equal. And for the strict OOXML flavor, MS Office > doesn't use it as its default format, it was only a mean to get the > OOXML approved by ISO I think (and we all remember the conditions in > which it has been done). > > Hagar > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
