[
https://issues.apache.org/jira/browse/COR-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282668#comment-14282668
]
Dennis E. Hamilton commented on COR-11:
---------------------------------------
The coin dropped on what I think is awkward about my understanding of what is
happening (which I would like very much to be corrected about).
Using the previous stages, here is what appears to be involved.
In stage 2, there is a conversion, Vodt(d1) -> Hd1 from a document file, d1, to
an HTML file, Hd1. This file reflects the document that is perceived as
carried by d1 and also details of some kind about restraints and about features
that are not being reflected but need to be retained in some fashion. So there
are markers and annotation of some sort in the Hd1.
In stage 5, there is an editing process, Eodt(d1, DHd1) -> d2. Note that this
is a full editor. We did view already, but now we have an editing process that
basically has a persistent document-file format taken in, along with however
the Hd1 edits are expressed, to make a derived persistent document file of that
(or possibly another) format.
There's also the case of making a fresh document. I don't know if there is
some sort of selection about what the intended document is up front, via an
initial HTML template or what, but we end up with a Codt(DHd0) -> d1 or
perhaps Eodt(template, DHd0) -> d1.
So to have the persistent-form end-to-end process work, there are a variety of
invariants that have to be sustained or there will be mystery defects and
breakage (and the kind of "some features may be lost" warnings) that make users
crazy.
My provisional take-aways:
1. Orchestration requires constraints that the stages have to honor in order
for the complete tool-chain to provide a reliable result with expected fidelity.
2. There are three important cases, one of which is in effect an editor of the
persistent document-file format anyhow. It isn't rendering a view and
apparently not coupled interactively to a renderer. That means there is a lot
of common code and also redundant use of that code in the round-trip from
document-file to HTML editing to document-file.
3. There is a lot to be done in getting the modularization right.
4. We need to understand and clearly-stipulate the scale limitations of this
approach, if I have understood it in its essential form.
5. We haven't considered distributed/collaborative real-time messing with
documents at all, as far as I can tell. I don't expect that. But an approach
to finer grain-modularity of interactions might anticipate some fundamental
provisions that would enable extending into that area. Maybe we just need to
be clear with ourselves about that.
> 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)
