[
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)
