TomD wrote > The OOXML standard has been through 3 revisions [...] Apparently first put > through in 2012. [...] ODF (Open Document Format) [...] has been an ISO > since 2006. Apparently it was complete enough first time and has never > needed to be revised.
This is inaccurate and not a good reflection of what the versions displayed in the linked ISO/IEC list mean. These are the specified editions, and years of publication for each edition, for OOXML: - 1st Ed., ECMA-376:2006 - 2nd Ed., ISO/IEC 29500:2008 and ECMA-376:2008 [1] - 3rd Ed., ISO/IEC 29500:2012 These are the specified editions, and years of publication for each edition, for ODF: - 1st Ed., ISO/IEC 26300:2006 ODF v1.0 and OASIS ODF v1.0 2nd Ed. (2006) [2] - amendment, OASIS ODF v1.1 (2007) and ISO/IEC 26300:2006/Amd 1:2012 ODF v1.1 - 2nd Ed., OASIS ODF v1.2 (2011) yet to be approved by ISO/IEC [3] As the ODF specification grows and becomes more complex[4], it will be revised in similar manner to the OOXML specification. I say this as a staunch advocate of ODF. It is a simple fact of the process that has nothing to do with being "complete enough first time". The two main reasons why the OOXML specification is so large are: a) it contains a lot of XML examples and as OOXML is an element rather than attribute-based specification, it requires more lines for each XML example; b) it describes a file format catering for a great many legacy scenarios and objects and is essentially a large, and complex file format. In 20 years time ODF will also likely be more complex, although hopefully never as difficult to comprehend. [1] These two specifications were supposed to be identical, but there was at least one difference that has since been addressed. [2] OASIS ODF v1.0 1st Ed., was specified in 2005, but the amended 2nd Ed., (ISO/IEC version) is the commonly accepted one. [3] When ODF v1.2 is accepted by ISO/IEC it will likely be the 2nd Ed. of ISO/IEC 26300. [4] For example, in order to provide an open and free equivalent to Object Linking and Embedding (OLE), which is currently specified in OASIS ODF v1.2 by reference to "Inside OLE" by Kraig Brockschmidt, Microsoft Press, 1995. TomD wrote > Apparently documents can fully comply with the [OOXML] format even if they > contain chunks/blobs that do not conform! It is not clear what you mean here by "do not conform". Under the Transitional version of OOXML in the editions listed above, there is provision for legacy (MS Binary file format) compatible blobs. This is why there is a Transitional version i.e., to allow end users to transition to the Strict format. These blobs are supposed to be stripped out (replaced) in OOXML Strict. This is also why ISO/IEC 29500:2012 Strict is the form of OOXML that third parties can more freely implement. In the same manner that the various versions of OOo / AOO / LO have probably implemented parts of the various ODF versions differently, so too do the various versions of MSO implement the various versions of both the MS Binary and OOXML formats differently. Unfortunately there is no getting away from this reality, especially when all the patch releases and hot fixes for products are taken into account - the number of possible product versions becomes very high over time. The developers in each camp are likely trying to do their best to ensure comformance, but as file formats become more complex, more people work on the code base, more real-world use cases are made use of, and a greater number of legacy versions of a product exist, this becomes more challenging over time (as should be expected). TomD wrote > Documents must completely comply in order to be considered as complying at > all. I generally understand what you mean (a document either complies or it does not), however this is an implementation, rather than specification, issue and is not so simple. A document produced by product A containing the character "a" may comply, while a more complex document, also produced by product A may be non-compliant. In this case the product is non-compliant, although it CAN produce compliant documents. The degree of compliance of a document written out by an implementation is often not determined until a particular real world use-case is encountered. This is why we have bugtrackers and software is patched in an ongoing manner. To re-iterate, compliance is a perennial struggle. In terms of an implementation of a specification it is generally asymtotically approached and rarely reached. Even LO does not fully comply with ODF v1.2 e.g., bugs like this are not that uncommon: https://bugs.freedesktop.org/show_bug.cgi?id=50950 Bugs can also creep in (in some future release), producing non-compliant documents, and remaining undiscovered until some time later. Catering for these sorts of real-world problems can sometimes be a dilemma. All office suites are in the same situation in this respect. Compliance is difficult to achieve and maintain. Again, I do not state all this as any sort of advocate for either Microsoft or OOXML (I am far from either), but merely to paint a clearer picture. ----- Best wishes, Owen. -- View this message in context: http://nabble.documentfoundation.org/What-version-tp4118061p4118561.html Sent from the Users mailing list archive at Nabble.com. -- To unsubscribe e-mail to: [email protected] 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
