corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <>
Subject Re: [CONF] Corinthia > ODF
Date Thu, 12 Mar 2015 16:56:21 GMT
On 12 March 2015 at 17:39, Dennis E. Hamilton <>

> 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.
+1 I too am not sure, and also not convinced it should be a high priority

I sure hope the HTML5 is independent of whatever ODF version or document
type is uses as input. The idea of the HTML5 is that it provides a common
data model for all document types/versions, and the filters take care of
the conversions.

>  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.
+1, spending too much time designing the perfect solution, will most likely
not work. Once we have something, I believe refactoring is a small problem,
but not having anything at all is a big problem.

>  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.
I agree with this.

> Those are my concerns.  I am certain you will find quite different
> concerns and expressions of faith from others here.
and they are very valid concerns. Let get started and then in 1-2 years
when we have done everything else, we can return and refine the filters.

We have so many things we want to do, so let us get the big lines done

jan i.

> More below,
>  - Dennis
>  -- replying inline to --
> From: Gabriela Gibson []
> Sent: Thursday, March 12, 2015 02:38
> To:;
> Subject: Re: [CONF] Corinthia > ODF
> On Thu, Mar 12, 2015 at 2:37 AM, Dennis E. Hamilton <
> > 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 []
> > Sent: Wednesday, March 11, 2015 16:43
> > To:
> > Cc:
> > Subject: Re: [CONF] Corinthia > ODF
> >
> > On Wed, Mar 11, 2015 at 11:02 PM, jan i <> 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:
> >  --- 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:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message