[
https://issues.apache.org/jira/browse/COR-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282681#comment-14282681
]
Dennis E. Hamilton commented on COR-35:
---------------------------------------
Ah! I commented more on COR-11 and now I see a big answer to my question is
here in COR-35. I hadn't read this closely enough. OK, my cautions about
orchestration of constraints across get(), put(), and create() apply. My
concerns about modularity and re-use also apply.
I can believe that it is awkward to basically do another get() internal to
put() and then use the differences to figure out how to patch the original S
from V' to make S'. I assume the interface to put() can be such that a
different approach could be used underneath?
I don't have any sense for the trade-off here and how it might hurt as
documents scale up. Is there any experience about that yet?
> Have put operation accept changes, not updated view
> ---------------------------------------------------
>
> Key: COR-35
> URL: https://issues.apache.org/jira/browse/COR-35
> Project: Corinthia
> Issue Type: Improvement
> Components: DocFormats - API
> Reporter: Peter Kelly
> Assignee: Peter Kelly
>
> The three canonical operations for bidirectional transformations are:
> get(S) -> V
> put(S,V') -> S
> create(V) -> S
> where S is a "source", or "concrete" document (in our case a "third party"
> file format like .docx, .odt, or .md) and V is a "view", or "abstract"
> document (in our case, HTML). In the notation I've used, V is the original
> view created from the file, and V' is a modified version of the view obtained
> from the editor.
> The current implementation of put, at least in the Word filter (which is the
> only one that implements it so far) does what effectively amounts to a
> reconstruction of the original V produced during the get, combined with a
> comparison of that V with V' (the edited version). This comparison is,
> however, done in a rather ad-hoc and poorly-defined manner, and is something
> that would need to be replicated by every other filter.
> Essentially, the put operation has two jobs: 1) determine the set of changes
> that were made to the view - that is, D = diff(V,V'), and 2) apply those
> changes to the source document - that is, patch(S,D). The patch operation
> uses changes expressed in terms of the view's data model (HTML) to figure out
> how it must update the concrete representation.
> To simplify filter implementation, we can separate out these two tasks, so
> that only the latter has to be performed by the put operation in each filter.
> This requires a diff algorithm that works on HTML files, and a ways of
> representing the changes to the file. Once these exist, implementation of a
> patch algorithm will be relatively straightforward - it just consists of
> taking the original document V and executing the operations in sequence to
> produce S'. Thus, the relationship between the functions are as follows,
> assuming V is the original view, V' is the modified view produced by the
> editor, and D is the diff, or rather a sequence of change operations which
> mutate the DOM tree.
> diff(V,V') -> D
> patch(V,D) -> V'
> A line-by-line or similar linear diff is insufficient, as it does not take
> into account the tree structure of the document. Whereas a line-by-line diff
> consists of a set of insert/delete operations that work on a list/array, we
> need an algorithm that produces a set of operations that work on a tree.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
