[
https://issues.apache.org/jira/browse/COR-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Kelly updated COR-35:
---------------------------
Description:
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.
> 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)
