[libreoffice-users] Re: What version?

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: users+unsubscribe@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