corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject RE: [CONF] Corinthia > ODF
Date Thu, 12 Mar 2015 16:39:32 GMT
The TL;DR on Gabriela's questions:

 1. I am not confident that the Corinthia model can be built out to achieve
    rich inter-convertibility.  That has to be determined quickly by seeing
    how to build out the ability to even to take HTML5 edits into the same
    format begun with and find out where any practical difficulties become
    barriers.

 2. I think we are doing experimental design and we don't know when or whether
    significant redesign might be required and I don't think there is enough
    information right now to predict that.  So the experiments must advance
    quickly.

 3. I think we presume too much about what it means to own your own documents.
    I'm for it, but it can't mean users have to learn how to maintain and
    port their own word-processing software, which is all that FOSS promises.
    Unfortunately, you get what you pay for, and maybe not even then.
    
Those are my concerns.  I am certain you will find quite different concerns and expressions
of faith from others here.

More below,

 - Dennis

 -- replying inline to --
From: Gabriela Gibson [mailto:gabriela.gibson@gmail.com] 
Sent: Thursday, March 12, 2015 02:38
To: dev@corinthia.incubator.apache.org; dennis.hamilton@acm.org
Subject: Re: [CONF] Corinthia > ODF

On Thu, Mar 12, 2015 at 2:37 AM, Dennis E. Hamilton <dennis.hamilton@acm.org
> wrote:

> Replying to both Gabriela and Jan comments farther below,
>
>  1. The TL;DR: Even though there are people still using StarOffice on a
> Sun Workstation, I don't think these are a significant component of likely
> Corinthia users.  Our use of an intermediary is not likely to get us to
> universal interconvertibility.
>
> (Peter: this also addresses your point :)

I'm not saying we should actually do this (now).

The question really is:  Can we plan now for this to be possible, at a
later time?  And, can we get this possibility cheaply, en passant?

That is, is there an elegant way in which to set up the architecture of
this code, so that someone can easily add inter-convertibility later on?

<orcmid>
   I think even inter-convertibility in the same format is a challenge with
   a model that is actually (1) a conversion from ODF to HTML5 (and whatever 
   CSS and JS libraries that might be needed to make a fit) and (2) taking
   an *edited* HTML5 of that form and using it to figure out how to patch
   the ODF document in (1) to reflect the differences between the differences
   between the edited HTML5 and the original HTML produced from the ODF.

   It appears to be an article of faith that one can achieve high-fidelity
   interchange in this manner.  I think that has to be tested by rapid
   development to determine where that may break down.
 
   I am reminded that the idea behind the HTML DOM was the possibility of
   exposing other formats through the same DOM.  I have not explored that
   but it would seem to be a better way to get to (2).  Perhaps any HTML5
   DOM is too limited, I don't know.

   I suspect the limitation on inter-convertibility via an HTML5 intermediary
   is going to be arise in constraints on (1) the conversion of X to HTML5
   (with CSS, JS, and some sort of tagging) and (2) the conversion of HTML5
   (with all of that) to Y.  I am certain there is an intersection where X to Y
   works but it is very difficult to know how far one can get in handling rich
   document formats and how easy that will be for any given legacy format, many
   of which are not well-documented and legacy processors may be hard to find
   and test with.

   I think the only way we will learn whatever the boundaries are and how
   difficult things may become as we go to preserve feature richness is to
   try it.  And if a wall is hit, figure out how to remedy things and then 
   go through the problem of dealing with Corinthia's own legacy.
</orcmid>

Also, say Corinthia gets to be (woo!) 20.  We're (say) at ODF 6.0.  Given
the entire reason for ODF is the users' data freedom (that is you own your
data and not some company and their fancy format), does it not behoove us
not to allow versions of ODF own the users data?

<orcmid>
   I am not sure I understand that.  The problem with office-productivity
   formats is users do not own their documents, some software owns their
   documents and without appropriately capable software, those documents
   are not preserved.  I am talking about the thousands of users who 
   download ODF-based software every week and have no idea what the files
   look like and certainly have no way to deal with the software, however
   it is developed or supported.  For them, the promise of FOSS is not 
   meaningful because they are not equipped to read the code, let alone
   modify it or port it.  For these users, if their needs are satisfied
   otherwise, the only difference between using, say Microsoft Office or
   WordPerfect is price and the problem of end-of-life of the software they
   need to have available.
     I agree about who should own the user's documents.  But it is not 
   exactly a format issue in the case of these document formats.
</orcmid>



Likewise, if possible, we should not limit tomorrows' committers either by
our design decision today.

<orcmid>
   I am not certain how one can be certain of this.  I expect that we are 
   limiting committers, but while the project is small it may be able to
   make changes and do the necessary rework.  From things Peter says about
   what he wants in the future, it strikes me that rework will be inevitable.

   My sense is that Corinthia is at the code first to figure out a design
   stage of development.  For me, it is very awkward to see how to scale out
   with very many committers at this point, when the design is an evolving
   experiment.  I am certain that is not the way it is in the head of Peter
   and Jan, but that is how it is for me as an observer.

   The only way I know of is to experiment quickly and have some sort of
   continuous delivery that allows us to explore and catch limitations 
   quickly.  That's not easy to arrange and I have no brilliant ideas about
   how to do that here.
</orcmid>

If it's a PITA, then it of course should not be attempted, but ... if we
can lunch for free, then please pass the ketchup! ;-)

Also, what Dennis wrote below makes me think that much future pain can be
avoided if we can pull such a design structure off.

Question for Dennis:  Where do you think ODF will be in 20 years time?

<orcmid>
   I do not know where ODF will be in 20 years.  At the moment, I
   would be surprised if there is ever an ODF 2.0 (and will it provide
   upward compatibility with older versions).  The current effort is to
   get to ODF 1.3 and, except for a new treatment of change-tracking 
   that is expected to replace/obsolete what is there now (and whatever 
   those upward compatibility issues will be), I think it 
   will be a maintenance release.  

   A bigger question will be what the situation will be with regard to
   Software that is ODF-supporting.  When the implementers are not able
   to absorb upgrades to ODF, I think that will determine the practical
   limit on ODF development.

   I have not been on the ODF Technical Committee since 2012, so I have
   no insider knowledge about this, although I do scan the mailing lists
   from time to time, and I still contribute suggestions and analysis
   on parts that interest me.
</orcmid>

G


 2. It is necessary to support input of all versions that are known
> especially because if a document says it is in ODF 1.2, that does not mean
> it uses any features that are not in ODF 1.1, and if it is one of the
> breaking cases, that can be handled if there is enough information about
> the intended level of ODF.  (But an ODF 1.2 implementation might still be
> implementing an ODF 1.1 interpretation.).
>      For output, if it is not possible to indicate the actual level of
> features employed, it is usually necessary to identify outputs as ODF 1.2.
>
> 3. IMPORTANT EXCEPTION: If the DocFilter implementations for ODF input and
> ODF updating do not preserve any features used above a given ODF level,
> that level should be indicated as the output level.  (I.e., if ODF
> 1.2-unique features are not even supported, don't call the output ODF 1.2,
> no matter what the input is claimed to be.)
>
> This might well be a significant part of spiral development and
> progressive integration of an ODF-support roadmap.
>
>  - Dennis
>
> -----Original Message-----
> From: Gabriela Gibson [mailto:gabriela.gibson@gmail.com]
> Sent: Wednesday, March 11, 2015 16:43
> To: dev@corinthia.incubator.apache.org
> Cc: dennis.hamilton@acm.org
> Subject: Re: [CONF] Corinthia > ODF
>
> On Wed, Mar 11, 2015 at 11:02 PM, jan i <jani@apache.org> wrote:
>
> [ ... ]
> > In my opinion, we must be able to  read all versions, but only write the
> > newest.
> >
> > This is a bit devil's advocate tale, but, it's a true story:
>
> [ ... ]
>
> So, there will be occasions where people will want to be able to use a
> legacy program, because it makes life easier for them, or perhaps, an old
> machine is all they can afford, or they simply don't want to enter upgrade
> hell.  When ODF 6.0 comes round (and it probably will, eventually) there
> will be lots of people wanting/needing this kind of functionality.
>
> Also, Hackernews had an interesting discussion today:
> https://news.ycombinator.com/item?id=9185356  --- maybe not quite
> applicable to our situation here, but pretty similar.
>
> I think it's worthwhile to consider to make it bidirectional by basic
> design.
>
> G
>
>
>


-- 
Visit my Coding Diary: http://gabriela-gibson.blogspot.com/


Mime
View raw message