You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@corinthia.apache.org by "Dennis E. Hamilton" <de...@acm.org> on 2015/08/24 23:23:45 UTC

[STATUS] Corinthia Home for ODF Interoperability Assessment

I was asked recently what the status of this work is now.

As I may have remarked often enough already, what appealed to me about Corinthia was the project scope item on determining the degree to which ODF, OOXML, and perhaps other formats, are supported in various implementations.  The ability to assess interoperable use of these formats with concrete assessment methods appeals to me.  I thought it was great that Corinthia would feature it.

My starting from the top and working down approach to this has been sketched at 
<https://cwiki.apache.org/confluence/display/Corinthia/ODF>, especially under the topic "ODF Conformance/Compliance Assurance."

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 and the volume will exceed what Peter saw as appropriate when I asked for advice about this.

My conclusion is that this effort does not fit what the intention for the scope item of Corinthia.  Instead, I will develop it outside of any specific implementation project (although it should be useful to any of them).

My original plan was to have enough prepared in 12 months to have enough where 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 the 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 personal project for this time period, so it will be late Summer 2016 before I expect there to be enough to be chewed on.

It will be available to Corinthia the same as any other project using ODF.  It will not be developed as part of Corinthia.

 - Dennis

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
Sent: Sunday, June 21, 2015 09:04
To: dev@corinthia.incubator.apache.org
Subject: RE: [DISCUSS] Corinthia Home for ODF Interoperability Assessment

I'm already doing a GitHub to prototype some of this.  After some experiments, I will see what works best as a home for the full development.  

I'm uncertain where the best place for the combination of materials and their documentation might be.

 - Dennis

-----Original Message-----
From: jan i [mailto:jani@apache.org] 
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

I too would prefer to have such documentation outside our source repo.

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.

rgds
jan i

On Tuesday, June 16, 2015, Dennis E. Hamilton <de...@acm.org>
wrote:

> Thanks Peter,
>
> Your questions and comments have led me to rethink this a little.
>
>  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 will
> 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 housing
> the materials.  I think I'll check to see how HTML renders on web access to
> a GitHub repository.)
>
>  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 having
> 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, and
> 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.
>
> I am going to ask around Apache about this.  Maybe some other places.


>  - Dennis
>
> -----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
>
> > On 16 Jun 2015, at 3:11 am, Dennis E. Hamilton <dennis.hamilton@acm.org
> <javascript:;>> wrote:
> >
> > 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."
> >
> > 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 test
> suites but are not intended to be the same as ad hoc tests created to
> exercising particular Corinthia and DocFormats functions.  Rather they are
> addressed to the standards and any profiling of processors, with DocFormats
> being only one.
>
> [ ... ]
>
> What sort of data volume do you think these are likely to consume? I’m
> 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’s only a
> few Mb or so, I’d say put them in the main repository, otherwise it might
> be more appropriate to store these in a separate repository. Do you know if
> Infra supports multiple repositories per project?
>
> > MY HESITATION
> >
> > 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 to
> make it work with a SubVersion repository because one can use the fact that
> the SVN is part of a web site and can be navigated with a browser.  One can
> even put HTML pages in an SVN repository and use (relative) links to
> cross-reference among the material.
> >
> > That is an extremely valuable way to do what I have in mind.
> >
> > Is this possible with the Corinthia Git repository?
>
> 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:
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-corinthia.git
>
> And to reference a specific file:
>
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-corinthia.git;a=blob_plain;f=DocFormats/CMakeLists.txt;hb=377421ecf076e553beedc075e2baef65a3e7e3b0
>
> 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 instead
> of incubator-corinthia.
>
> 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’m not sure how important
> URL stability is to you for this particular use case; if it’s not critical
> then we should be ok with either of these options.
>
> Regarding the way in which the HTML structure on the website is done, this
> would not have an impact, as the files could simply be placed in a separate
> directory and be linked to from the main page. There’s nothing special or
> abnormal that would need to be done here.
>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org <javascript:;>
>
> 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)
>
>
>

-- 
Sent from My iPad, sorry for any misspellings.


RE: [STATUS] Corinthia Home for ODF Interoperability Assessment

Posted by "Dennis E. Hamilton" <de...@acm.org>.
I need to clarify something.

In the report below, I provided an update about my ODF Interoperability Assessment work.  I have now initiated that work as a private, non-ASF activity.  I moved the intended destination for the work, not myself.

I did not leave.  I would have plainly said so if I had.  I have no need to be circumspect about it. 

I am still here.

 - Dennis  

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
Sent: Monday, August 24, 2015 14:24
To: dev@corinthia.incubator.apache.org
Subject: [STATUS] Corinthia Home for ODF Interoperability Assessment

I was asked recently what the status of this work is now.

As I may have remarked often enough already, what appealed to me about Corinthia was the project scope item on determining the degree to which ODF, OOXML, and perhaps other formats, are supported in various implementations.  The ability to assess interoperable use of these formats with concrete assessment methods appeals to me.  I thought it was great that Corinthia would feature it.

My starting from the top and working down approach to this has been sketched at 
<https://cwiki.apache.org/confluence/display/Corinthia/ODF>, especially under the topic "ODF Conformance/Compliance Assurance."

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 and the volume will exceed what Peter saw as appropriate when I asked for advice about this.

My conclusion is that this effort does not fit what the intention for the scope item of Corinthia.  Instead, I will develop it outside of any specific implementation project (although it should be useful to any of them).

My original plan was to have enough prepared in 12 months to have enough where 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 the 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 personal project for this time period, so it will be late Summer 2016 before I expect there to be enough to be chewed on.

It will be available to Corinthia the same as any other project using ODF.  It will not be developed as part of Corinthia.

 - Dennis

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
Sent: Sunday, June 21, 2015 09:04
To: dev@corinthia.incubator.apache.org
Subject: RE: [DISCUSS] Corinthia Home for ODF Interoperability Assessment

I'm already doing a GitHub to prototype some of this.  After some experiments, I will see what works best as a home for the full development.  

I'm uncertain where the best place for the combination of materials and their documentation might be.

 - Dennis

-----Original Message-----
From: jan i [mailto:jani@apache.org] 
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

I too would prefer to have such documentation outside our source repo.

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.

rgds
jan i
[ ... ]


Re: [STATUS] Corinthia Home for ODF Interoperability Assessment

Posted by Dave Fisher <da...@comcast.net>.
Hi Dennis,

I am only somewhat surprised that you don't mention Apache OpenOffice in this 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 OpenOffice 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 contribute wherever you choose.

Regards,
Dave

Sent from my iPhone

> On Aug 24, 2015, at 2:23 PM, Dennis E. Hamilton <de...@acm.org> wrote:
> 
> I was asked recently what the status of this work is now.
> 
> As I may have remarked often enough already, what appealed to me about Corinthia was the project scope item on determining the degree to which ODF, OOXML, and perhaps other formats, are supported in various implementations.  The ability to assess interoperable use of these formats with concrete assessment methods appeals to me.  I thought it was great that Corinthia would feature it.
> 
> My starting from the top and working down approach to this has been sketched at 
> <https://cwiki.apache.org/confluence/display/Corinthia/ODF>, especially under the topic "ODF Conformance/Compliance Assurance."
> 
> 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 and the volume will exceed what Peter saw as appropriate when I asked for advice about this.
> 
> My conclusion is that this effort does not fit what the intention for the scope item of Corinthia.  Instead, I will develop it outside of any specific implementation project (although it should be useful to any of them).
> 
> My original plan was to have enough prepared in 12 months to have enough where 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 the 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 personal project for this time period, so it will be late Summer 2016 before I expect there to be enough to be chewed on.
> 
> It will be available to Corinthia the same as any other project using ODF.  It will not be developed as part of Corinthia.
> 
> - Dennis
> 
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
> Sent: Sunday, June 21, 2015 09:04
> To: dev@corinthia.incubator.apache.org
> Subject: RE: [DISCUSS] Corinthia Home for ODF Interoperability Assessment
> 
> I'm already doing a GitHub to prototype some of this.  After some experiments, I will see what works best as a home for the full development.  
> 
> I'm uncertain where the best place for the combination of materials and their documentation might be.
> 
> - Dennis
> 
> -----Original Message-----
> From: jan i [mailto:jani@apache.org] 
> 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
> 
> I too would prefer to have such documentation outside our source repo.
> 
> 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.
> 
> rgds
> jan i
> 
> On Tuesday, June 16, 2015, Dennis E. Hamilton <de...@acm.org>
> wrote:
> 
>> Thanks Peter,
>> 
>> Your questions and comments have led me to rethink this a little.
>> 
>> 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 will
>> 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 housing
>> the materials.  I think I'll check to see how HTML renders on web access to
>> a GitHub repository.)
>> 
>> 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 having
>> 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, and
>> 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.
>> 
>> I am going to ask around Apache about this.  Maybe some other places.
> 
> 
>> - Dennis
>> 
>> -----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
>> 
>>>> On 16 Jun 2015, at 3:11 am, Dennis E. Hamilton <dennis.hamilton@acm.org
>>> <javascript:;>> wrote:
>>> 
>>> 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."
>>> 
>>> 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 test
>> suites but are not intended to be the same as ad hoc tests created to
>> exercising particular Corinthia and DocFormats functions.  Rather they are
>> addressed to the standards and any profiling of processors, with DocFormats
>> being only one.
>> 
>> [ ... ]
>> 
>> What sort of data volume do you think these are likely to consume? I’m
>> 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’s only a
>> few Mb or so, I’d say put them in the main repository, otherwise it might
>> be more appropriate to store these in a separate repository. Do you know if
>> Infra supports multiple repositories per project?
>> 
>>> MY HESITATION
>>> 
>>> 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 to
>> make it work with a SubVersion repository because one can use the fact that
>> the SVN is part of a web site and can be navigated with a browser.  One can
>> even put HTML pages in an SVN repository and use (relative) links to
>> cross-reference among the material.
>>> 
>>> That is an extremely valuable way to do what I have in mind.
>>> 
>>> Is this possible with the Corinthia Git repository?
>> 
>> 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:
>> 
>> https://git-wip-us.apache.org/repos/asf?p=incubator-corinthia.git
>> 
>> And to reference a specific file:
>> 
>> 
>> https://git-wip-us.apache.org/repos/asf?p=incubator-corinthia.git;a=blob_plain;f=DocFormats/CMakeLists.txt;hb=377421ecf076e553beedc075e2baef65a3e7e3b0
>> 
>> 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 instead
>> of incubator-corinthia.
>> 
>> 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’m not sure how important
>> URL stability is to you for this particular use case; if it’s not critical
>> then we should be ok with either of these options.
>> 
>> Regarding the way in which the HTML structure on the website is done, this
>> would not have an impact, as the files could simply be placed in a separate
>> directory and be linked to from the main page. There’s nothing special or
>> abnormal that would need to be done here.
>> 
>> —
>> Dr Peter M. Kelly
>> pmkelly@apache.org <javascript:;>
>> 
>> 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)
> 
> -- 
> Sent from My iPad, sorry for any misspellings.
>