Mailing-List: contact dev-help@corinthia.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@corinthia.incubator.apache.org
Date: Mon, 19 Jan 2015 05:25:34 +0000 (UTC)
From: "Dennis E. Hamilton (JIRA)" <jira@apache.org>
To: dev@corinthia.incubator.apache.org
Message-ID: <JIRA.12762945.1419015956000.113444.1421645134474@Atlassian.JIRA>
In-Reply-To: <JIRA.12762945.1419015956000@Atlassian.JIRA>
References: <JIRA.12762945.1419015956000@Atlassian.JIRA>
 <JIRA.12762945.1419015956111@arcas>
Subject: [jira] [Comment Edited] (COR-11) Make interface between docformat
 and webkit (prepare for e.g. Qt).
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/COR-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282146#comment-14282146 ] 

Dennis E. Hamilton edited comment on COR-11 at 1/19/15 5:25 AM:
----------------------------------------------------------------

I've been thinking about this some more, and want to understand the dataflow.

It looks like this to me, using ODF as the persistent format being maintained for my example.

   1. There is the ODF of a document, d1, to be worked on.
   2. There is a process that abstracts the ODF to some model, whether explicitly or as a procedural consequence, and that process delivers Hd1, an HTML that somehow captures the essence of the ODF document.  d1 is now set aside.
   3. The user is presented with a rendition of Hd1 in some form and can view some level of document that is faithful to what d1 is.  That is, there is some sort of restraint that would prevent manipulations of Hd1 that can't be reflected back onto d1.
   4. The modified file, DHd1 is another HTML (or a change-set on Hd1) that reflects the changes.  This process 3-4 does not have access to d1 directly and it tends to be general purpose, so it is even not particular to ODF, yet presumably there are some constraints present to ensure that it doesn't depart from what ODF can accomodate via the next stage.
   5. With editing completed, d1 is again instantiated in some manner where the DHd1 can be lined up with it and a new Dd1 produced that is an ODF document that is d1 with the DHd1 changes reflected in it.

Is this a fair characterization of the transformation process that is enabled between a d1 and the ultimate Dd1?

I think one can accomplish such a structure.  I'm not certain the moving parts are all in the right places, but the composition of transformations should be supportable.  

The seams seem awkwardly-placed, but that is just me.  The moving parts can be held together by how a session is operated and how DHd1 and d1 are able to be synchronized.  

A complication would appear to be when the user wants to edit (or even just view) an ODF document, d1, but end up with a d2 which is an OOXML document.  So in this mix we have the prospect of starting with an empty target and taking an DHd1 and making d2.  

Does this picture permit unconstrainted HTML introduced the same as DHd1? That is, there need be no prescribed document format other than HTML involved in the origin of the document to be manipulated and/or stored in a particular persistent format.  I find it hard to put this in the same back-path as getting from DHd1 and d1 to an ODF d2.  It looks like we're looking at different processes, perhaps sharing modular components underneath, but operating rather different cases?

Is that expected too?


was (Author: orcmid):
I've been thinking about this some more, and want to understand the dataflow.

It looks like this to me, using ODF as the persistent format being maintained for my example.

   1. There is the ODF of a document, d1, to be worked on.
   2. There is a process that abstracts the ODF to some model, whether explicitly or as a procedural consequence, and that process delivers Hd1, an HTML that somehow captures the essence of the ODF document.  d1 is now set aside.
   3. The user is presented with a rendition of Hd1 in some form and can view some level of document that is faithful to what d1 is.  That is, there is some sort of restraint that would prevent manipulations of Hd1 from being reflected back onto d1.
   4. The modified file, DHd1 is another HTML (or a change-set on Hd1) that reflects the changes.  This process 3-4 does not have access to d1 directly and it tends to be general purpose, so it is even not particular to ODF, yet presumably there are some constraints present to ensure that it doesn't depart from what ODF can accomodate via the next stage.
   5. With editing completed, d1 is again instantiated in some manner where the DHd1 can be lined up with it and a new Dd1 produced that is an ODF document that is d1 with the DHd1 changes reflected in it.

Is this a fair characterization of the transformation process that is enabled between a d1 and the ultimate Dd1?

I think one can accomplish such a structure.  I'm not certain the moving parts are all in the right places, but the composition of transformations should be supportable.  

The seams seem awkwardly-placed, but that is just me.  The moving parts can be held together by how a session is operated and how DHd1 and d1 are able to be synchronized.  

A complication would appear to be when the user wants to edit (or even just view) an ODF document, d1, but end up with a d2 which is an OOXML document.  So in this mix we have the prospect of starting with an empty target and taking an DHd1 and making d2.  

Does this picture permit unconstrainted HTML introduced the same as DHd1? That is, there need be no prescribed document format other than HTML involved in the origin of the document to be manipulated and/or stored in a particular persistent format.  I find it hard to put this in the same back-path as getting from DHd1 and d1 to an ODF d2.  It looks like we're looking at different processes, perhaps sharing modular components underneath, but operating rather different cases?

Is that expected too?

> Make interface between docformat and webkit (prepare for e.g. Qt).
> ------------------------------------------------------------------
>
>                 Key: COR-11
>                 URL: https://issues.apache.org/jira/browse/COR-11
>             Project: Corinthia
>          Issue Type: New Feature
>          Components: DocFormats - API
>         Environment: source
>            Reporter: jan iversen
>            Priority: Blocker
>             Fix For: 0.5
>
>
> We need a API to the library


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)