Example on change-tracking compromise

Dear SC,

    

    Following, you will find an introduction to the design principles of
    the change-tracking (CT) compromise and examples covering the three
    use-cases (UC4-6 ) discussed on last OASIS sub-committee (SC) call.

    UC 4: Overlapping Style Changes
    "This example is similar to UC 1. The word bold-italic is italicized
    and all the words containing bold are made bold."

     Definition of change:
    

    
        
        

          
            
Starting markup:

            
<text:p>Normal

                    normal bold bold bold-italic bold bold normal
                    normal.</text:p>

          
          
            
Ending markup:

            
<text:p>Normal

                    normal <text:span style="bold">bold bold <text:span style="bold-italic">bold-italic</text:span> bold bold</text:span> normal normal.</text:p>

          
        

      
    
    

     Content of "undo.xml":
    <changes>

        <style s="1/15" e="1/46" type="bold-off"/>

        <style s="1/25" e="1/36" type="italic-off"/>

    </changes>

    Description of undo.xml (repeated from previous mail):

    
    The RelaxNG schema and explanation of all XML nodes of the
    "undo.xml" file (the resulting XML change) will be in a new part of
    our ODF specification.

    The attributes s (start) and e (end) identify components. In case
    there is only the attribute "s", it is a single component. In case
    both attributes "s" & "e" are used, it is a selection of
    multiple components within the component tree (ordered as in XML).

    The numbers represent the location of component in the document
    component tree. Even a single character are taken as a component. 

    XML based counting starts with 1. For example, the access of the
    12th character within the 3rd paragraph of a text document is shown
    as "3/12". An insertion at this position would place the new
    component in front of the selected (e.g. 12th character).

    (Note: I am uncertain yet if a preceding label specifying the type
    of component is helpful, e.g. "p3/c12" for 3rd paragraph/12th
    character. The prefix would be redundant, but is more human readable
    and might simplify the mapping into internal models, different to
    the ODF. The label would provide immediately the information without
    need to look-up in the "content.xml").

    The sequence of the change-events is chronological. But
    change-events might be grouped by further <changes> elements,
    even creating a tree hierarchy.

    For instance the changes of a document (e.g. our specification) can
    be sorted by an ODF errata version, which is separated by ISO
    national body issues, separated by issue numbers.

    

    NOTE: Assuming the paragraph of the example is the first component
    in the document

    UC 5: List Edit and Convert to Paragraphs
    "This example is similar to the example “Paragraph / list item
    merging” in the ECT proposal supplement 1. A list item text is
    edited and the list is converted to regular paragraphs."

     Definition of change:
    
      
        
             
            

              
                
                  

                    
Line 1

                  

                  

                    
Line 2

                  

                  

                    
Line 3

                  

                
              
              
                
Line 1

                
Line 2 added

                
Line 3

              
            

          
        
      
    
    

    
        
        

          
            
Starting markup:

            
<text:list>

            
<text:list-item>

            
<text:p>Line

                  1</text:p>

            
</text:list-item>

            
<text:list-item>

            
<text:p>Line

                  2</text:p>

            
</text:list-item>

            
<text:list-item>

            
<text:p>Line

                  3</text:p>

            
</text:list-item>

            
</text:list>

          
          
            
Ending markup:

            
<text:p>Line

                  1</text:p>

            
<text:p>Line 2 added</text:p>

            
<text:p>Line

                  3</text:p>

            

            

          
        

      
    
    

     Content of "undo.xml":
    <changes>

        <list s="1/1">

            <indent item="3"/>

            <indent item="2"/>

            <indent item="1"/>

        </list>

        <delete s="1/1/2/7" e="1/1/2/13" /> 

    </changes>

    Description of undo.xml
    (see description of first use case)
     NOTES:
    
      
Assuming the list of the example is the first component in the
        document

      
Nested within a component there are events relevant to the
        component (e.g. for tables insert-row) and the access is
        relative to the component root ando no longer to the document
        tree. (Especially helpful to address a row, column, cells or
        cell-range address within a table).

      
As every new event is based on a component tree existing when
        the event started, the opposite order of indent events would
        result in an invalid state. Implementors feed-back to change
        this behavior.

      

    
    UC 6: Text Frame Modifications
    
"This example is similar to the
      example “Table cell merge – multiple” in the ECT proposal
      supplement 1. The text box is moved, text edited, resized and
      moved."

    

     Definition of change:
    

     Starting markup: 
    
<draw:frame … svg:x="1.0in" svg:y="1.0in" svg:width="1.0in" draw:z-index="0">

        <draw:text-box fo:min-height="0.3in">    

                  <text:p>Text box</text:p>

              /draw:text-box>

          </draw:frame>
    Ending markup:
    
<draw:frame … svg:x="2.0in" svg:y="2.0in" svg:width="1.5in" draw:z-index="0">

        <draw:text-box fo:min-height="0.3in">

                  <text:p>Text modified box</text:p>

              </draw:text-box>

          </draw:frame> 

    

     Content of "undo.xml":
    <changes>

        <box s="1/1">

            <seize w="1.0in"/>

            <position x="1.0in" y="1.0in"/>

        </box>

        <delete s="1/1/6">modified <delete> 

    </changes>

    Description of undo.xml
    (see description of first use case)

     NOTE:
    
      
Assuming the text box of the example is the first component in
        the document 

      
It is interesting for later Operational Transformation (OT)
        that the above insert event 

        <delete s="1/1/6">modified <insert> 

        has the same result as

        <delete s="1/1/5"> modified<insert> 

        Future will tell if ODF application might ease OT

    
    Next Steps
    What is missing is the ODF XML change description of the events,
    that should be moved to the ODF spec.

    The next step from my point of view would be to provide a prototype
    definition of an event using a complicate example as insert- or
    moveColumn.

    The initial scope of coverage could be identical to the scope given
    by the ECT proposal.

    

    Regards,

    Svante