Mailing-List: contact dev-help@corinthia.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@corinthia.incubator.apache.org
From: Dave Fisher <dave2wave@comcast.net>
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Subject: Re: [STATUS] Corinthia Home for ODF Interoperability Assessment
Message-Id: <9D416FCB-AFFB-4626-955E-C6B2CBF93FA6@comcast.net>
Date: Mon, 24 Aug 2015 14:43:13 -0700
References: <00ce01d0deb3$29813430$7c839c90$@acm.org>
In-Reply-To: <00ce01d0deb3$29813430$7c839c90$@acm.org>
To: "dev@corinthia.incubator.apache.org" <dev@corinthia.incubator.apache.org>

Hi Dennis,

I am only somewhat surprised that you don't mention Apache OpenOffice in thi=
s context. To me the biggest problem with that project was in not working on=
 predictable one to one conversion between ODF and OOXML. Without that then O=
penOffice will have trouble entering the institutional market. Or, Munich.

Best of luck. Your knowledge in this area is very deep and you have much to c=
ontribute wherever you choose.

Regards,
Dave

Sent from my iPhone

> On Aug 24, 2015, at 2:23 PM, Dennis E. Hamilton <dennis.hamilton@acm.org> w=
rote:
>=20
> I was asked recently what the status of this work is now.
>=20
> As I may have remarked often enough already, what appealed to me about Cor=
inthia was the project scope item on determining the degree to which ODF, OO=
XML, and perhaps other formats, are supported in various implementations.  T=
he ability to assess interoperable use of these formats with concrete assess=
ment methods appeals to me.  I thought it was great that Corinthia would fea=
ture it.
>=20
> My starting from the top and working down approach to this has been sketch=
ed at=20
> <https://cwiki.apache.org/confluence/display/Corinthia/ODF>, especially un=
der the topic "ODF Conformance/Compliance Assurance."
>=20
> I have been working on this off-project in order to determine the scope of=
 the material.  My current estimate is that there will be extensive tests an=
d the volume will exceed what Peter saw as appropriate when I asked for advi=
ce about this.
>=20
> My conclusion is that this effort does not fit what the intention for the s=
cope item of Corinthia.  Instead, I will develop it outside of any specific i=
mplementation project (although it should be useful to any of them).
>=20
> My original plan was to have enough prepared in 12 months to have enough w=
here others could use it and also contribute more to it.  That was assuming a=
 start in March when a technical paper of mine became available.  I moved th=
e start to June, here, and now the best I can hope for is 12 months from now=
.  Other activities and life have intervened.  However, this is my key perso=
nal project for this time period, so it will be late Summer 2016 before I ex=
pect there to be enough to be chewed on.
>=20
> It will be available to Corinthia the same as any other project using ODF.=
  It will not be developed as part of Corinthia.
>=20
> - Dennis
>=20
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]=20
> Sent: Sunday, June 21, 2015 09:04
> To: dev@corinthia.incubator.apache.org
> Subject: RE: [DISCUSS] Corinthia Home for ODF Interoperability Assessment
>=20
> I'm already doing a GitHub to prototype some of this.  After some experime=
nts, I will see what works best as a home for the full development. =20
>=20
> I'm uncertain where the best place for the combination of materials and th=
eir documentation might be.
>=20
> - Dennis
>=20
> -----Original Message-----
> From: jan i [mailto:jani@apache.org]=20
> Sent: Sunday, June 21, 2015 08:14
> To: dev@corinthia.incubator.apache.org; dennis.hamilton@acm.org
> Subject: Re: [DISCUSS] Corinthia Home for ODF Interoperability Assessment
>=20
> I too would prefer to have such documentation outside our source repo.
>=20
> If we need another git repo or svn repo, it is just a question of filing a=

> jira, and we get it,
> so no need to make temporary repos.
>=20
> rgds
> jan i
>=20
> On Tuesday, June 16, 2015, Dennis E. Hamilton <dennis.hamilton@acm.org>
> wrote:
>=20
>> Thanks Peter,
>>=20
>> Your questions and comments have led me to rethink this a little.
>>=20
>> 1. For temporary purposes, I am going to create a GitHub project that
>> carries some specimen and exemplary materials for a startup Document
>> Interop Assessment project.  This is an easier place to demonstrate my
>> thinking and also not clutter up the Corinthia repo with material that wi=
ll
>> go dead and should not clutter up the history.  (For various reasons, I
>> would much rather have this be in an SVN repository because of how
>> repository-level versioning is handled automatically and how HTTP access
>> into SVN works well. I also have to satisfy myself about using Markdown
>> instead of HTML, since that creates more dependencies on any server housi=
ng
>> the materials.  I think I'll check to see how HTML renders on web access t=
o
>> a GitHub repository.)
>>=20
>> 2. The Interop Assessment material is not really something that is
>> produced in releases.  There might be companion utilities that have
>> releasable source code and convenience binaries.  However the Interop
>> Assessment material could become quite extensive and it makes no sense to=

>> have there be some sort of overall release cadence.
>>    I need to think what would be an appropriate place to house this that
>> is not tied to the release cadence of some project.
>>    (I also think this is a matter for Corinthia itwself, in that there
>> are multiple components in what is a kind of suite of materials and havin=
g
>> an overall release of the code base might be a little peculiar.  It seems=

>> to be the wrong level for versioning of stuff.)
>>    Perhaps it is better to think of this as a kind of library project,
>> where a big part of the library is a collection of data, documentation, a=
nd
>> instructions as well as a variety of (small?) utilities.  Maybe code that=

>> is developed for generic treatment of the material and assessment of
>> documents, conduct of tests, etc., is more appropriate for something like=

>> Apache Commons.  Then there are all the cases and their data.
>>=20
>> I am going to ask around Apache about this.  Maybe some other places.
>=20
>=20
>> - Dennis
>>=20
>> -----Original Message-----
>> From: Peter Kelly [mailto:pmkelly@apache.org <javascript:;>]
>> Sent: Monday, June 15, 2015 21:52
>> To: dev@corinthia.incubator.apache.org <javascript:;>
>> Subject: Re: [DISCUSS] Corinthia Home for ODF Interoperability Assessment=

>>=20
>>>> On 16 Jun 2015, at 3:11 am, Dennis E. Hamilton <dennis.hamilton@acm.org=

>>> <javascript:;>> wrote:
>>>=20
>>> I want to start building specimen documents that fit the model of
>> interoperability assessment that is sketched (sketchily) at
>>> <https://cwiki.apache.org/confluence/display/Corinthia/ODF> under the
>> "ODF Conformance/Compliance Assurance helix."
>>>=20
>>> My thought is to create a branch having a folder, "InteropAssess" with
>> subfolder "ODF" to start a subtree of folders that develop specimens that=

>> demonstrate particular aspects of ODF documents.  These can be used as te=
st
>> suites but are not intended to be the same as ad hoc tests created to
>> exercising particular Corinthia and DocFormats functions.  Rather they ar=
e
>> addressed to the standards and any profiling of processors, with DocForma=
ts
>> being only one.
>>=20
>> [ ... ]
>>=20
>> What sort of data volume do you think these are likely to consume? I=E2=80=
=99m
>> just thinking about repository size and keeping it manageable (to allow
>> people to quickly clone the repo if they want to build it). If it=E2=80=99=
s only a
>> few Mb or so, I=E2=80=99d say put them in the main repository, otherwise i=
t might
>> be more appropriate to store these in a separate repository. Do you know i=
f
>> Infra supports multiple repositories per project?
>>=20
>>> MY HESITATION
>>>=20
>>> I don't quite like putting these in a Git repository because it is
>> important and useful to cross-reference among the materials and I am not
>> clear how that can happen in a non-web repository system.  I do know how t=
o
>> make it work with a SubVersion repository because one can use the fact th=
at
>> the SVN is part of a web site and can be navigated with a browser.  One c=
an
>> even put HTML pages in an SVN repository and use (relative) links to
>> cross-reference among the material.
>>>=20
>>> That is an extremely valuable way to do what I have in mind.
>>>=20
>>> Is this possible with the Corinthia Git repository?
>>=20
>> Yes - though with the caveat that it depends on there being a particular
>> server that contains a clone of the repository. For Corinthia, you can
>> access the files here:
>>=20
>> https://git-wip-us.apache.org/repos/asf?p=3Dincubator-corinthia.git
>>=20
>> And to reference a specific file:
>>=20
>>=20
>> https://git-wip-us.apache.org/repos/asf?p=3Dincubator-corinthia.git;a=3Db=
lob_plain;f=3DDocFormats/CMakeLists.txt;hb=3D377421ecf076e553beedc075e2baef6=
5a3e7e3b0
>>=20
>> The main problem is that these URLs are not necessarily stable;
>> git-wip-us.apache.org will presumably become git-us.apache.org at some
>> point, and upon graduation our repository will be called corinthia instea=
d
>> of incubator-corinthia.
>>=20
>> Another options - since our website is just static files, we could
>> alternatively host the files there (while still storing the documents in
>> the repository, and having a script which copies up the files to the site=
.
>> However this still has the problem of URL stability -
>> http://corinthia.incubator.apache.org would become
>> http://incubator.apache.org upon graduation. I=E2=80=99m not sure how imp=
ortant
>> URL stability is to you for this particular use case; if it=E2=80=99s not=
 critical
>> then we should be ok with either of these options.
>>=20
>> Regarding the way in which the HTML structure on the website is done, thi=
s
>> would not have an impact, as the files could simply be placed in a separa=
te
>> directory and be linked to from the main page. There=E2=80=99s nothing sp=
ecial or
>> abnormal that would need to be done here.
>>=20
>> =E2=80=94
>> Dr Peter M. Kelly
>> pmkelly@apache.org <javascript:;>
>>=20
>> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key=
>
>> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>=20
> --=20
> Sent from My iPad, sorry for any misspellings.
>=20