The precise situation is as follows: Office 2007 (SP2 I think) through Office 2013 *all* accept and produce OOXML Transitional. This is also true of the compatibility pack that provides OOXML support in Office 2003. These products also have compatibility modes that will preserve compatibility (unless changed at user option) of edited documents that originated from down-level versions. The OOXML format has this kind of support available as part of special compatibility and extension provisions. (There are similar provisions in the Office 97-2000 format and RTF, but the technique is more refined in OOXML.)
Office 2010 and Office 2013 *also* accept OOXML Strict. These are the first versions that can accept Strict. They are the first versions produced after Strict was fully specified. (There was a major change in Strict at the ISO level and I don't know how that has been smoothed over between Office 2010 and 2013.) Office 2013 is the first version that can *produce* OOXML Strict. The default is still OOXML Transitional. One has to specifically request Strict in the Save As dialog, at least on my installation of Office 2013 Preview. I don't know when the default will ever flip over and I haven't checked for configuration options that change the default preference. This is all done to smooth the readiness and preparation for migration to Strict. It was not Microsoft's idea to create such a hard line in the sand. It came from the ISO/IEC committee that is maintaining the OOXML specification and from the ballot resolution meeting that had OOXML approved as an International Standard. The Transitional OOXML support in Office 2007 and back to Office 2003 (by compatibility pack) was all done based on the original ECMA standard, which had no Strict separation. What is being done to smooth the transition makes perfect sense to me. Presumably the people who want to use strict understand that there is no down-level compatibility, and strict will not happen by accidental default. This consideration of migration and up-/down-level preservation would be an useful lesson for actions taken on the ODF TC and in OpenOffice-legacy implementations that provide breaking changes to default behavior. There are more of those on their way. The sudden change of Save As Password to use different encryption methods not known down-level was just a first taste. Breaking changes with regard to SVG compatibility will be more noticeable. And the new change-tracking that may emerge in ODF 1.3 will go farther still. - Dennis -----Original Message----- From: webmaster-Kracked_P_P [mailto:webmas...@krackedpress.com] Sent: Tuesday, February 05, 2013 06:57 To: users@global.libreoffice.org Subject: Re: [libreoffice-users] Re: Re: LibreOffice 4.0 Many months ago, there was a notification that MSO2013 changed their XML formatting from a "loose" to a "strict" version of the format. I do not remember the exact wording but they stated that MSO2010 may not read MSO2013 files correctly. So that makes 3 releases of MSO on Windows that are not compatible with MS's own XML based formats. EVERY time they release a new version, since 2007, they require the user to buy the new version to be compatible. They there is the big hike in buying their office suite, since renting will give MS more income from the same user. You get a lower up-front cost but a higher total cost when you rent MSO. All this incompatibility is just a scheme to increase their income. [ ... ] -- For unsubscribe instructions e-mail to: users+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted