Hello everyone, Quick note in passing. I fail to see how thr discussion on xml standards implementations is of any interest to our users. May I (respectfully) suggest that interested parties bring this conversation to our discuss list?
Thank you, Charles. On 11 août 2014 10:40:00 CEST, Owen Genat <[email protected]> wrote: >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 -- Envoyé de mon téléphone avec Kaiten Mail. Excusez la brièveté. -- 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
