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
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.