ODF conformance/compliance testing (was RE: ODF mapping)

["Dennis E. Hamilton" <de...@acm.org>]

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
    orcmid@apache.org
    dennis.hamilton@acm.org    +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 ***

Re: ODF conformance/compliance testing (was RE: ODF mapping)

[jan i <ja...@apache.org>]

On 30 April 2015 at 17:07, Dennis E. Hamilton <de...@acm.org>
wrote:

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

You are right this is important, and just happens to be part of what I put
into the projects.

We have one VALS student, who are going to work on a small part of this
from mid-june (I wrote about it earlier). The aim is to establish a
Question sheet,
where all featured are divided into "standard", "optional" and
"implementation defined". The idea is that a vendor can use this sheet to
specify how the implementation actually work. Once the sheet is finished,
then we need test documents to show each line in the sheet.

If you want to help the student it would help us all.

>
> 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.
>
any input is welcome.

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

rgds
jan i.

>
>
>  -- Dennis E. Hamilton
>     orcmid@apache.org
>     dennis.hamilton@acm.org    +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 ***
>
>