Date: prev next · Thread: first prev next last
2014 Archives by date, by thread · List index

I found this very useful thanks.

On 11/08/14 8:51 pm, Charles-H. Schulz wrote:
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,


On 11 août 2014 10:40:00 CEST, Owen Genat <> wrote:
TomD wrote
The OOXML standard has been through 3 revisions [...] Apparently
first put
through in 2012. [...] ODF (Open Document Format) [...] has been an
since 2006. Apparently it was complete enough first time and has
needed to be revised.
This is inaccurate and not a good reflection of what the versions
in the linked ISO/IEC list mean. These are the specified editions, and
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
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
- 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
to do with being "complete enough first time". The two main reasons why
OOXML specification is so large are: a) it contains a lot of XML
and as OOXML is an element rather than attribute-based specification,
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
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
(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.
ISO/IEC 26300.
[4] For example, in order to provide an open and free equivalent to
Linking and Embedding (OLE), which is currently specified in OASIS ODF
by reference to "Inside OLE" by Kraig Brockschmidt, Microsoft Press,

TomD wrote
Apparently documents can fully comply with the [OOXML] format even if
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
there is a Transitional version i.e., to allow end users to transition
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
implemented parts of the various ODF versions differently, so too do
various versions of MSO implement the various versions of both the MS
and OOXML formats differently. Unfortunately there is no getting away
this reality, especially when all the patch releases and hot fixes for
products are taken into account - the number of possible product
becomes very high over time. The developers in each camp are likely
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
made use of, and a greater number of legacy versions of a product
this becomes more challenging over time (as should be expected).

TomD wrote
Documents must completely comply in order to be considered as
complying at
I generally understand what you mean (a document either complies or it
not), however this is an implementation, rather than specification,
and is not so simple. A document produced by product A containing the
character "a" may comply, while a more complex document, also produced
product A may be non-compliant. In this case the product is
although it CAN produce compliant documents. The degree of compliance
of a
document written out by an implementation is often not determined until
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
and rarely reached. Even LO does not fully comply with ODF v1.2 e.g.,
like this are not that uncommon:

Bugs can also creep in (in some future release), producing
documents, and remaining undiscovered until some time later. Catering
these sorts of real-world problems can sometimes be a dilemma. All
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
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:
Sent from the Users mailing list archive at

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.