An ODF Implementor's View on Change Tracking

Hi, 

    

    I am new to the SC mailing list as an active member.

    But instead of commenting right away on one of our current
    proposals, I would try to share some experience gained by working on
    collaboration for Oracle's Cloud Office.

    

    Dependencies of Change-Tracking

    The implementor of a new modern ODF office suite, which supports
    change-tracking, will recognize several office functionalities that
    work very closely together:

    
      
Versioning

      

      
Change tracking

      

      
Undo/redo 

      

      
Collaboration with other users

      

    
    There is a relationship between the items above. Roughly said: One
    item bundles multiple items listed directly below. More precisely:

    
      
One version contains several changes by one or more users

      

      
One change contains one or more undo/redo changes of one ODF
        component by a single user. Removing information undesired by
        the common user (e.g. it is irrelevant in what order the text of
        a paragraph has been added)

        NOTE: The ODF component is described in the presentation I
        mentioned earlier on the TC mailing list [1].

      

      
One undo/redo action might be a wired change event to other
        ODF clients

        (again there is usually a compression of information as text
        changed by undo/redo is in general not altered on character
        basis, but on larger granularity, e.g. words are undone/redone)
        

      

    
     Potential Change-Tracking Requirement

    From the above, our SC is currently focusing on serializing changes
    and postponed the run-time collaboration feature, as change-tracking
    is most important to our users. On the other hand when selecting the
    best change-tracking proposal we should as well have an eye on its
    interoperability with the upcoming collaboration feature otherwise
    we are loosing great potential for ODF applications:

    For example, imagine full interoperability between change-tracking
    and collaboration. In this case it would be to map the
    change-tracking changes to a queue of collaboration events and vice
    versa. A user might than be able to apply document changes to other
    documents and save collaboration directly as standardized changes.
    The example above is a feature that can be taken as potential
    requirement for any change-tracking proposal.

    

     Potential Change-Tracking Feature

    The following example shows a potential change-tracking feature that
    is only enabled when doing a certain kind of collaboration.

    Let me therefore take you a step further to common collaboration
    design to show you how collaboration features might influence the
    serialization of change-tracking. 

    User conflicts caused during collaboration are elegantly solved by
    the Operational Transformation (OT) approach [2] (OT is currently
    being used by Google's Web Office).

    Some explaining words on Operational Transformation (OT). The OT
    approach maps the editing of a document to event calls. In OT theory
    even a complete document might be mapped to a queue of event calls,
    creating the document by events starting from scratch.

    In OT the event is called operation and the transformation (the T
    from OT) occurs when an operation has to be adapted as a different
    operation happened earlier influencing it.

    For example, there is a table operation to insert a column at
    position 3, but someone else has already inserted a column at
    position 2, the table operation therefore has to be transformed to
    insert the table at position 4 instead of 3, as the original
    document was changed earlier.

    

    Now the nice side-effect: this transformation can not only be used
    for collaboration, but as well to move an operation (or a grouped
    set of operations) in the time-line of the queue.

    

    Let me give a real-world example to show the potential:

    Imagine you have to work on a version for the ODF specification.

    Editing directly on the ODF specification, changing what is required
    from a task in our OASIS bug-tracker and grouping those changes to
    be related to this certain bug task.

    When all changes for the version are completed, they are embraced to
    a new document version. 

    Now imagine the case where the deadline for the version arrives, but
    some issue is again under discussion. It was decided that the
    changes of that issue should not be part of that version, but still
    not be deleted as later still required. As the changes are only
    operations in a time-ordered queue they can be moved to the end of
    the queue, applying operational transformation when necessary.
    Moving the undesired change out of the version range.

    

    To summarize:

    Implementors do not care much about the implementation detail of the
    serialization of ODF change-tracking to ODF XML. But implementors do
    care very much to be able to map every single change to operations
    as used in collaboration to allow innovative ODF implementations.

    

    Best regards,

    Svante

    

    [1] http://lists.oasis-open.org/archives/office/201107/msg00026.html

    [2] http://www.waveprotocol.org/whitepapers/operational-transform

    

    
-- 

      
      
      
      
      
      
      

        Svante
              Schubert
              | ODF Standardization

              Phone: +49 40 23646 965

            Oracle Office
              GBU

      
ORACLE
              Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097
              Hamburg

              Hauptverwaltung: Riesstr. 25,
              D-80992 München

              Registergericht: Amtsgericht München, HRA
              95603

              

              Komplementärin: ORACLE Deutschland Verwaltung
              B.V.

              Rijnzathe 6, 3454PV De Meern, Niederlande

              Handelsregister
              der Handelskammer Midden-Niederlande, Nr. 30143697

              Geschäftsführer:
              Jürgen Kunz, Marcel van de Molen, Alexander van der Ven 
      

      
        
          

            
              

            
            
              
Oracle is
                      committed to developing practices and products
                      that help protect the environment