![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}
+1
Hi 
I didn't mean that Italo was wrong, just that it was possibly a bit geeky
(and that wasn't a disadvantage because he put it so well).
Where MS might be updating their doc, xls etc formats at least they have
hopefully stopped doing different versions for different versions of their
program. It is Rtf that they have stopped developing. The newer DocX,
XlsX etc seem to be very different.
For anyone interested in reading up about the ISO definitions this link
might help;
http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
If you scroll to the very bottom of the page you see 4 different papers
about OOXML (carefully named Office Open XML to avoid any confusion with
the pre-existing Open Document Format). The OOXML standard has been
through 3 revisions and those 4 documents amount to 6,764 pages = lets say
over 6.5k. Apparently first put through in 2012. Apparently documents can
fully comply with the format even if they contain chunks/blobs that do not
conform!
If you scroll back up by 1 page then the ODF (Open Document Format) is
about half-way down. It's under 800 pages and has been an ISO since 2006.
Apparently it was complete enough first time and has never needed to be
revised. Documents must completely comply in order to be considered as
complying at all.
Regards from
Tom
Hi
+1
Also a big thanks to everyone else who helps or has helped, especially
those who seldom get any recognition.
Regards from
Tom
In ISO/IEC 29500 there is only one transitional definition, while
Microsoft has produced three different transitional versions (two
without definition, i.e. Transitional 2010 and Transitional 2013) within
the same pseudo-standard. Transitional, by the way, is not defined as a
standard format (because it is incompatible with the Gregorian Calendar,
and because it includes proprietary blobs not released within the
"covenant not to sue").
OOXML Strict is a standard, but it is supported properly only by
LibreOffice (which means that the reference implementation is not
available, and in any case the free reference implementation is missing).
So, no free reference implementation, no standard (unless you see
lock-in as a feature of a standard document format).
No.
I meant that MSO 2013 is completely, utterly, and absolutely
incompatible with MSO 2013.
Likewise, MSO 2010 is completely, utterly, and absolutely incompatible
with MSO 2010.
Likewise, MSO 2007 is completely, utterly, and absolutely incompatible
with MSO 2007.
jonathon
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.
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.
italovignoli wrote
The Transitional and Strict formats are both defined in ISO/IEC 29500.
In ISO/IEC 29500 there is only one transitional definition, while
Microsoft has produced three different transitional versions (two
without definition, i.e. Transitional 2010 and Transitional 2013) within
the same pseudo-standard.
I could have been clearer. I was indicating that the Transitional form is
defined in the indicated specification, rather than ONLY in the indicated
specification. As I indicated in my prior response this form is defined in
all three editions of the OOXML specification (both ECMA and ISO/IEC). It is
unreasonable to expect an earlier version of any product to write out
documents compliant with the latest version of a specification, until the
product has been patched to do so. LO is identical in this manner e.g.,
legacy documents written out non-compliantly using LO v3.x may cause
problems in future versions of LO. Reports of this nature come up on
Bugzilla. Some cases are easily fixable, some are less easily fixed.
italovignoli wrote
Transitional, by the way, is not defined as a standard format (because it
is incompatible with the Gregorian Calendar, and because it includes
proprietary blobs not released within the "covenant not to sue"). OOXML
Strict is a standard ...
We are agreed that Transitional is a virtually unimplementable form of the
OOXML specification. Both Transitional and Strict are however now enshrined
in ISO/IEC so we have to live with this in the same way we are still living
with the original Lotus 1-2-3 leap year date error that Microsoft inherited.
TDF / LO have decided (freely) to implement support for ISO/IEC 29500
compliant documents so the burden is now on us all to assist as best we can.
I say all this with full respect Italo.
Hopefully the next versions of MSO will use the Strict form by default, so
the transition away from the interrim form can begin in earnest. I am always
grateful of the terrific work being done by the developers in this area and
assist as I can in the forums and with bug reports.
Charles-H. Schulz wrote
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?
Duly noted. I posted my last response before seeing this message, so
apologies if appears I am ignoring you. I am not. Future discussions of this
topic I will post to the indicated list.
Hi.
I found this very useful thanks.
steve.