Re: [office-collab] "Changes" to the XML file

[Svante Schubert <svante.schubert@gmail.com>]

I fully agree on your observation, Patrick.

In addition what helped me to understand the complexity of
change-tracking was the scenario of a user, who loads a document and
saves it write away after only a single atomic change to the document.
Change-tracking have to provide the information to the serialized
document to undo that exact atomic change (or any stack of those atomic
changes).

While the previous approach of file formats had been to explicitly
describe the XML before and after the change, our approach is to
describe an atomic change of the document state by an operation as
placeholder. The change of the document state is similar to the
difference of the XML being saved before and after the atomic change.
Our ODF specification would define the operation by that XML change, so
the operation can used as abbreviation of the XML change to represent
the change information of the XML (or to be precise as we want to undo
the change, to store the inverse operation).

The operation is like a delta XML and together with the XML (before or
after) can be mapped to the XML (after or before). It is nothing more
than an abbreviation of the XML change of two documents or the similar
state change of the document. It should be remembered some Operations
can be compressed to a single one, like multiple insertion of sibling
characters is equal to the insertion of the similar text.

While the priority of the SC is on change-tracking the design comes from
the real-time collaboration, where operations of changes are being
exchanged among the office applications, it usually helps to map a CT
use case in the context of real-time collaboration. For instance, the
support of different feature sets:
In theory it is possible to have a real-time collaboration between a
full featured ODF office and a text only application as Vi. Both might
be working on the ODF specification.
The Vi could emulate paragraphs by line breaks, so that every line in
the VI would be mapped to a paragraph within the spec. Here some FAQ I
could think of:

Q: What is required to allow the interoperability of such different
applications.
A: The agreement on a common set of known elements, in our case the
<text:p>.

Q: What if the VI saves the document as ODF?
A: If the VI saves the document back to the original document (our ODF
specification), no data is lost as the paragraphs can be accuracy be
mapped to the existing one. If the VI saves its current model into a
completely new ODF file, all none text and paragraph information from
the document are lost.

Q:  What if the VI user wants to add a paragraph between two unknown
components? Like there are two paragraphs and in between those
paragraphs there are two tables, unknown to the VI?
A: As long as the tables are not shown in the VI, there is no way to add
a paragraph between those.

Meet you soon in our today's call..
Svante


On 19.12.2012 22:19, Patrick Durusau wrote:
> Greetings!
>
> I have been replaying the conversations about "changes" to the ODF XML
> file.
>
> While I know we need to speak about "changes" to the XML file in order
> to know what to specify, in a very real sense, there are *never any
> changes* to the XML file.
>
> That is to say that an application loads the XML file into its custom
> memory model and if the user inserts a paragraph after the "second"
> paragraph and before the "third" paragraph.
>
> <text:p>p1</text:p>
> <text:p>p2</text:p>
>                <--------------Insertion point for <text:p>new p</text:p>
> <text:p>p3</text:p>
>
> But that diagram is misleading because the application has no XML to
> track at that point.
>
> It has:
>
> In memory:
>
> p1
> p2
> insertion point for new P
> p3
>
> It only has its own in memory structures and the method it has chosen
> to track changes to those structures.
>
> When the XML file become relevant is when the application serializes
> the in memory structures out to an XML file and records the changes to
> it using ODF change tracking.
>
> That is to say that the reading/consuming application loads the XML
> file into its memory structures and change tracking for those
> structures. The application then becomes responsible for any changes
> that impact the # of a component or its place in the document flow.
>
> This is the simple XML change tracking case.
>
> Serialize all the changes that have been tracked as part of the file
> package for reassembly by the reading application.
>
> All of the changing of numbers, etc., occur in the application and it
> is responsible for putting any accepted change where it should go. All
> we are responsible for it giving it the information necessary to start
> tracking that change when the file is loaded.
>
> *****************
>
> The more complicated case is the one where less than the entire file
> is being interchanged.
>
> But I know there are systems which have successfully tracked and
> interchanged changes with less than whole file updates so I am
> confident a solution can be devised for that case as well.
>
> Hope everyone is looking forward to a great holiday season!
>
> Patrick
>
>
>