OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-collab message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office-collab] Immutable Change Tracking


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Svante,

I'm sorry you are missing the call today because I think the XPath /
no XML model at run time is an important issue to discuss. Perhaps we
can get started today and over time iron it out.

I say that because your right, no ODF application is required to have
an XML model.

ODF applications can have any internal model they care to have, but,
they are required to *read* ODF XML and to *write* ODF XML from their
purely internal representations.

That is to say that the XML file format of ODF *is* the abstraction
layer that enables many ODF applications to have varying internal models
.

So, my choice of XPath was very intentional because it too is an
abstract representation of the change, against the abstraction that
the ODF application has already read into its internal structure.

The same process of reading the ODF document would be applied to
reading the change into the internal representation of the ODF
application.

Likewise, when an ODF application serializes changes, however it
stores them internally, it serializes them against the immutable XML
ODF file which it read when it loaded the file.

The abstraction of XPath to "logical identities" maybe how many ODF
applications choose to go from the XPath representation to their
internal model but that's an application's choice and I would prefer
that we not dictate to applications their abstractions.

Using XML for both the file format and changes allows ODF to remain
above the choices made by ODF applications.

Hope everyone is having a great day!

Patrick




On 01/13/2016 06:55 AM, Svante Schubert wrote:
> 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" <patrick@durusau.net 
> <mailto:patrick@durusau.net>> wrote:
> 
> 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
> 
> 
> ---------------------------------------------------------------------
>
> 
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
>
> 
- -- 
Patrick Durusau
patrick@durusau.net
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

iQIcBAEBAgAGBQJWlmzmAAoJEFPGsgi3Mgyc8hwQAMUehF9iQ/HKW5Xzl62UsZD6
U2FFKpoc8lFaMKAC/l9I91Y6Q9j6o5383+aEkkWBXj+ff4K05KbEsxVsw+Kjd7v3
VLEmDFpeTiq8ZvPfc3Hr80ETxgNOt9zXxXAiBaTpuAfJqqoQiiau4iPKy62e52mf
+mnbSvefg1sU52YxL+AI8Ahla3DN4FJKzC7ogTK9PXu2Je75Zz+eWoiYbw1mHe6H
Ko3pujPy4RmCJSirnovi+ag2IktaI23lqJr7zQKX9HaU0psNxtWlO4vlcVKci3+a
C/GqgBjmZ6hY60wtoZyIUmFvRsNwd/Tp06iZeV/MfjFq+g7lAXGfh/7IhKl+2fUN
ITjTOVprdqMimyPRp94/9DmkEZHcD9ZDL/mnHkiQrBSWNO2JbXmq4CwNPk769NCd
ci0rrVPvZHCgj88tq42e4dEwxpodw2u1kw3F7UiXcaXyIDuwdXVAhKnH1cfvtdLy
f2DI9xPuggWldNlQfzggOfVktmwiZs7+FWnMrqA4WQLU/hjYWXF4YYyz91kbKU4x
WtZOvfSkcn4ZIsxCAzWVarelwwbisDCBOOxN7wGztyn49AHcyBBjTsZ7G/HhQVQJ
RTG90KAL2G+2uWznwrCjA8mqIsXigN0gpufT3bl+t73vjvR30nqvEYcsB2xR1AvR
dNMvzvjzWSAjsUUSmMDC
=0Whb
-----END PGP SIGNATURE-----


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]