In the original proposal for Apache Corinthia as an Incubator project, and on
the web site, there is this text in the statement of Goals
<http://corinthia.incubator.apache.org/learnmore.html>:
Many office document programs claim to read/write to the
ISO open standards for office documents, OpenDocument
Format (ODF) and Office Open XML (OOXML), but do not
document which parts are left unimplemented. Furthermore,
the standards have a large number of "implementation defined"
parts, making real-world congruence chancy. The Corinthia
project wants to put this unacknowledged aspect into the open
and provide "compliance sheets" for document formats, as known
from industry computer protocols.
Corinthia aims at generating a large set of test documents,
which can be used to verify the "compliance sheets". The code
can work as test case for other applications (or entities
tendering for OOXML/ODF based systems) as well.
I think that is very important. In fact, it is the sole reason that I chose to
become an initial committer and, thereafter, part of the Podling Project
Management Committee. And, if this is not a product of this project, I will
eventually leave.
I propose to offer a structure for achieving what that stated goal is in a
tangible, transparent, and reusable/re-purposable form. It is not a task I can
complete on my own, but I would rather establish it here, where participation
of others is welcome and straightforward, than on web pages and repositories
operated by myself.
I propose to start with ODF because it is the ISO specification that I know the
best, having been on editing teams and also producing errata for the
progression of alignment between OASIS and ISO versions of the specifications.
-- Dennis E. Hamilton
[email protected]
[email protected] +1-206-779-9430
https://keybase.io/orcmid PGP F96E 89FF D456 628A
X.509 certs used and requested for signed e-mail
MORE THOUGHTS AND SOME REALITY CHECKING
At ISO there is an ODF maintenance working group but the working agreement
between OASIS and ISO/IEC JTC1 has maintenance performed at OASIS. In the case
of OOXML, maintenance is actually performed at ISO/IEC JTC1 and ECMA basically
mirrors the resulting ISO/IEC JTC1 Corrigenda, Addenda, and new integrated
versions. There is far more active maintenance on OOXML than on ODF.
It is also important to point out that, as far as I know, the *only*
implementations of OOXML and ODF that are profiled in the manner proposed here
are those for Microsoft Office. There are deficiencies (and Microsoft welcomes
comments and corrections), but whatever those deficiencies are, these are the
only in-the-world efforts to demonstrate conformance and account for
deviations. So any contribution in this regard from Corinthia is likely to be
quite welcome to Microsoft and might even elicit contributions from the
relevant experts on the Office team.
Of course, I cannot speak for Microsoft in any manner and I have no knowledge
of what they might actually do. I am simply pointing out their willingness to
have such information (since it is important to regulatory authorities,
although regulators have never required the same accountability from others as
far as I know, even though that may change in the EU at some point) and that
there is an intersection of interests with Microsoft Office here.
We can also, in the case of OOXML, explore the differences between strict and
transitional and how Microsoft's initial support for transitional has migrated
to finally having, in Office 2013, the option of producing strict OOXML and in
Office 2010 the ability to consume either strict or transitional. Most of the
pissing about this from the ODF camp is simply political posturing and
incredible blindness to what Microsoft has to do to support billions of
existing documents and the software that operates with them.
I also believe a structure of this kind will be instrumental in the
qualification of document conformance and processor compliance of LibreOffice
and Apache OpenOffice (and Microsoft Office) in settings where civil
authorities wish to establish OpenDocument format as an open and
freely-supported format for their important editable documents and for the
interchange of documents with their constituencies. At the moment, many
adoption schemes fail when the interoperability realities and total cost of
adoption come to the surface. This is, of course, blamed on Microsoft
marketing success, without any attention to the larger interoperability
short-comings of the offered ODF implementations. Such denial is neither
useful nor productive, however righteous one is about it.
*** end ***
