OpenDocument - Adv Document Collab SC

  • 1.  "Changes" to the XML file

    Posted 12-19-2012 21:20
    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 -- Patrick Durusau patrick@durusau.net Technical Advisory Board, OASIS (TAB) Former Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau


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

    Posted 01-16-2013 13:10
    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 > > >