Mailing-List: contact dev-help@corinthia.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@corinthia.incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <006c01d08357$649b30f0$2dd192d0$@acm.org>
References: <006c01d08357$649b30f0$2dd192d0$@acm.org>
Date: Thu, 30 Apr 2015 21:34:34 +0200
Message-ID: 
 <CAK2iWdQvj1CRREk_ABKqeGJ25hMYj5PiWqmPzQHW=5Hb9FJHiQ@mail.gmail.com>
Subject: Re: ODF conformance/compliance testing (was RE: ODF mapping)
From: jan i <jani@apache.org>
To: "dev@corinthia.incubator.apache.org" <dev@corinthia.incubator.apache.org>,
	Dennis Hamilton <dennis.hamilton@acm.org>
Content-Type: multipart/alternative; boundary=001a11c285a8743e2b0514f62f23

--001a11c285a8743e2b0514f62f23
Content-Type: text/plain; charset=UTF-8

On 30 April 2015 at 17:07, Dennis E. Hamilton <dennis.hamilton@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 ***
>
>

--001a11c285a8743e2b0514f62f23--