The immutable change-tracking is indeed very useful for the scenario of commenting and editing a signed document. In this scenario the XML can not be changed, as otherwise the sign would be broken.
Every comment/edit would be saved aside the signed content XML and might be signed again for each author, ensuring the validity of the complete content.
That the changes will in the future refer to the position of change into the content instead of embedding it as prior we agree on. XPath is just a possible choice of implementation for referencing. From my observation Patrick's ideas are not based on XPath, he just took it as example. I rather would avoid XPath as ODF application do not require to have an XML model representation at run time, in contrary to the file model related DOM run-time API of browsers.
In addition ODF XML has no normalized representation, which make XML references more difficult.
Therefore the abstraction from XML to logical identities, which are known to users and referencing to those will be easier to handle by general run-time model related to ODF and works well for applications without ODF XML awareness even at run-time.
I have experienced this in my work on a browser based office with Open-XChange in the past years.
For example, the reference of the 3rd character within the 2nd paragraph might be written as /2/3 which can be seen as a simplification of XPath and was handled by the browser office I have been working with as simple integer array, making things easy for the office at run-time.
Kind regards,
Svante
On Jan 8, 2016 9:58 PM, "Patrick Durusau" <> wrote:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Greetings!
I have been following discussions of immutable data structures, mostly
in Clojure for several years and it recently occurred to me that if
the starting state of an ODF document were immutable and changes are
expressed against that immutable state, then many of the problems and
issues that have bedeviled the change tracking TC simply disappear.
First, since we have an immutable starting state, then changes
expressed against that state, for example in XPath (there are ways to
default large parts of path statements), represent changes that can be
accepted or rejected when producing either a visual, print and/or new
version of the document.
A "new" version of the document has a new starting state for change
tracking and therefore does not reflect the change history of the
previous version of the document.
A visual or print version of the document would have, expressed as an
XPath as well, list of changes that were accepted for that particular
visual or print version. Which would mean you could create another
visual or print version with different changes reflected. Which would
be a separate XPath statement. Enabling you to go back through
versions and/or any changes.
Second, an immutable starting state and expressions of changes as
XPath statements means we can detect when there are conflicting
changes, without those changes ever stepping on other changes.
For example, assume that we have three paragraphs in the starting
state of the document and I delete text:paragraph #2. Since that is
recorded as an XPath statement and the original state of the document
does not change, you can record changes to text:paragraph #2 without
fear of your changes being lost. And you can continue to edit the rest
of the paragraphs in the document because to you they have (and do
have) the original paragraph numbering.
Moreover, if you want to express changes on changes, which are
themselves stored in an XML document structure, unlike present
applications you can make changes to changes, which while immutable,
can have changes specified that point into those changes.
Third, and this reaches into the future collaboration sphere of
activity, having immutable documents and changes expressed as XPaths,
will enable the detection of when branches occur that impact the
visual, print or new version, enabling the author to make choices
about which branch in the document to accept for that particular version
.
Moreover, immutable change tracking will enable classic collaboration
around a server but also enable collaboration with specified others or
within specified groups, such as an authoring group in a highly secure
environment.
Permissions could also determine what changes could be seen by
particular users and where they could suggest changes.
I realize this is in stark contrast to the minimal document by default
architecture of present change tracking in ODF. That was a good design
decision some twenty years ago, facing unreliable networks and a stand
alone orientation to document authoring.
But twenty years ago isn't where we are in 2016. There are
"collaborative" environments already, although I'm not impressed with
their capabilities when compared to applications based on ODF.
What I am proposing isn't that different from Svante's original
proposal except that I propose to solve the problem of coordination
between systems by making documents and the changes to be applied to
them immutable. Ultimately, serious conflicts must be solved by an
author's choice and what I have proposed here will give every author
exactly that choice.
On the up side, having immutable change tracking the enables
applications to have traditional collaboration hubs (think of servers
with big targets painted on them), to have collaboration between
individual clients at no extra effort, save for receiving the changes,
and to have group change tracking for highly secure environments.
Oh, I know Svante hasn't pushed this very hard but having immutable
change tracking will also enable a variety of platforms to all work on
the same ODF document. I may be editing in a desktop application while
Svante is editing on a smartphone, which doesn't support styles or svg
graphics. All that means is that Svante won't be submitting changes
for what his platform doesn't support. He can submit changes for text
without any difficulty.
Lest that get lost in all my verbage, the "text" is what we say it is
when we "accept" changes for the production of a visual, print or new
edition. Others may choose differently, as may we at some later point
in time. To capture a particular version, create a new edition with no
change history. Then it becomes a frozen artifact in time.
I suspect this will be of interest to a number of security conscious
entities, just for the varieties of collaboration alone. Add in the
other capabilities and I think it could be the next jump in
collaborative word processing.
Hope everyone is at the start of a great weekend!
Patrick
- --
Patrick Durusau
Technical Advisory Board, OASIS (TAB)
OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor 13250-5 (Topic Maps)
Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJWkCMJAAoJEFPGsgi3MgycXaUQANCSZZxva/nL6igv6J8vxzY1
Sb3+3WU+fLToiZ7b0qZn+Lq2VkzjZl/kMZ7gKII8TQ6qgSKaUIPdH/2gF2w897Fe
fKsluI0n/smqpKwck7M3MrFGBvp+N1eqbgqdpJHOjdOCwKn9Pa5rZ5A3PARxbs8J
S9h5/teLQu4TxVIGwwyOpS5W99DrnN6H3CiVM+b1tftplg/d9zih/jslW9wtmHGK
ypTCcsNpefLTir9vwgZGBbVoh5VlKBrswrZuLl/Nzv+NlOlCx1pnKqhIcz0L7M0F
4TYpJor90S0oepQLQwzeJ7ZcnLkCvN1CY95RIozLl4h+9PI2twmf+q2N0vE3pgi2
3GoIlMGYlS4eR2SCUQC00gZSD3K1/M58+57/ykfvg3vd85ybTxIREl5R1m/B/euk
8yjLL/doHTYWk6SdZ2PqexDmqf+10jiZ2fBkE0bAIp1MjznAmHxbEyNdXPjYYcHj
rh4jB3fR9abE2VXwOtO8ji5p14cVQJX1XUMs9N46FjmKwB0LAEdjdHto/bfPOM2l
+qv97x3UNFiGTUy14R4rYrlRXQNUQFgYFT7S6FXIkMPH202vkPjSzRlFNQ0kGKeR
YasJslsS2fYuwnO25BgbOms0ewiJJZ8s6VDKsV1r8MHzg0Ah6h5SCWX0za8Xuke4
jNKwwl9FS3zuN3Z73NN4
=R4zb
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
