corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject ODF conformance/compliance testing (was RE: ODF mapping)
Date Thu, 30 Apr 2015 15:07:34 GMT
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 <>:

    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    +1-206-779-9430  PGP F96E 89FF D456 628A
    X.509 certs used and requested for signed e-mail


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

View raw message