← Prev in month ← Prev in thread
Next in thread → Next in month →

Re: [office-collab] Additional use case for change tracking (MCT Solution)

From
Svante Schubert <>
Date
2012-06-28T19:27:33+00:00
ID
Thread
Re: [office-collab] Additional use case for change tracking (MCT Solution)
Here the MCT representations of the two cases that Patrick proposed.
    

    Please excuse the delay, I had been working on an MCT prototype
    based on the Apache (Incubating) ODF Toolkit and had been distracted
    from this task.

    

    CASE 1

    1. Original saved by 1st author

      <text:p>This is the original
      paragraph, created with change tracking on so seen as an added
      paragraph.</text:p>

    

    2. 2nd author changes text:

    <text:p>This is the second version of the paragraph, created with change tracking on so seen as a modifed
      paragraph.</text:p>

    

    <text:p>This is the original paragraph, created with change tracking on so seen as a paragraph.</text:p>

    

      

          // FILEPATH "./content.xml"

          // DESCRIPTION:  The following is part of a content.xml file,
          similar abbreviated as Robin did before

        

      <xmlns:text="urn:oasis:names:tc:opendocument:xmlns:text:1.0"
xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0">

              <!-- ... -->

              <office:text >

                  <text:p>This is
            the second version of the
            paragraph, created with change tracking on so seen as a
            modifed paragraph.</text:p>

              </office:text>

              <!-- ... -->

          

          

        // FILEPATH "./meta.xml"

          // DESCRIPTION:  Store all metadata of changes
          in the metadata file. 

          

        <office:document-meta office:version="1.3" 

             
          xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0" 

             
          xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0"
          

              xmlns:dc="http://purl.org/dc/elements/1.1/">

              <office:meta>

                 
<meta:generator>ODFApp/1.0$Win32/123m1$Build-007</meta:generator>

                  <meta:creation-date>20120618T145700+0100</meta:creation-date>

                <meta:initial-creator xml:id="User1">1st
          author</meta:initial-creator>

                <dc:creator xml:id="User2">2nd
          author</dc:creator>

                <dc:date>20120618T145922+0100</dc:date><!--
          time of change the ODF XML is related to -->

                  <dc:language>en-US</dc:language>

                 
          <meta:editing-cycles>2</meta:editing-cycles>

            <office:meta>

        </office:document-meta>

          

           

        // FILEPATH "./changes/undo.xml"

          // DESCRIPTION:  Undo change operations are being stored in
          this file. The directory is useful for keeping changed binary
          data

        

          <undo
          xmlns="http://docs.oasis-open.org/ns/office/1.3/merge/ct#"
          meta-file="../meta.xml">

            <add
          type="text" time="23s" 
          by="User1"
          s="/1/1">This is the original paragraph, created with
            change tracking on so seen as an added
            paragraph.</add>

              <del type="text" time="1m58s" 
        by="User2"
        s="/1/12" e="/1/20"/>

            <add type="text" time="2m01s" 
        by="User2"
        s="/1/12">second
            version of the</add>

            <del type="text" time="2m17s" 
        by="User2" s="/1/89"
        e="/1/96"
        />

            <add type="text"
        time="2m22s" 
        by="User2" s="/1/89">modified</add>

         </undo>

        

      

          The creation time is of the time, when the empty document is
          being loaded. All following editing operations are relative to
          this origin time.

          The various users/editors are written in the meta.xml and
          referenced by the undo.xml file.

    The start and end parameter of each operation is relative to state
    of the content.xml just before the operations occurs.

    

    The problem of (real-time) collaboration is similar to the problem
    of the shell game (or thimblerig). In a shell game you have one
    marble under several shells and you have to take track of the shell
    with the marble.

    In collaboration others are changing the content and someone has to
    take track of the own changes.

    This magic of the solution is enabled by operations and their
    relative references, but is happening during run-time and is hidden
    from the specification. It is called Operational Transformation (OT)
    [1][2][3].

    Basically OT is about adapting the existing operations to compensate
    the influence of other users. For instance, incrementing the
    reference, if a component was inserted before. For example, if you
    work on the third paragraph and someone is inserting a new second
    parameter, you still want to work on the same paragraph, but it is
    no longer the third, but the forth..

    

    PS: The second example will be answered tomorrow, I will have to
    focus on the soccer game.. 

    

    [1] http://en.wikipedia.org/wiki/Operational_transformation

    [2] http://www.heise.de/developer/artikel/Synchronisationsalgorithmen-verstehen-1562877.html?artikelseite=1
    (German - e.g. use Chrome browser context menu to translate)

    [3] http://www.codecommit.com/blog/java/understanding-and-applying-operational-transformation
← Prev in month ← Prev in thread
Next in thread → Next in month →