← Prev in month ← Prev in thread

Use Case - H.1 Formula and Number Modification Example - MCT - 1. Draft

From
Svante Schubert <>
Date
2012-02-21T22:29:02+00:00
ID
Thread
Use Case - H.1 Formula and Number Modification Example - MCT - 1. Draft
As Robin stated before the H.1 spreadsheet example is explained
    verbose via 'before change' and 'after change' ODF documents, which
    you can find in the following zip 

    http://www.oasis-open.org/apps/org/workgroup/office-collab/download.php/40800/use-cases.zip

    

    The interesting change occurs within the content.xml: 

    State A - before:

    
    <table:table-row table:style-name="ro1">

        <table:table-cell office:value-type="float"
    office:value="2010">

            <text:p>2010</text:p>

        </table:table-cell>

        <table:table-cell office:value-type="float" office:value="10000">

            <text:p>10000</text:p>

        </table:table-cell>

        <table:table-cell table:formula="of:=0.15*[.B4]"
    office:value-type="float" office:value="1500">

            <text:p>1500</text:p>

        </table:table-cell>

    </table:table-row>

    

    State B - after:

    
    <table:table-row table:style-name="ro1">

        <table:table-cell office:value-type="float"
    office:value="2010">

            <text:p>2010</text:p>

        </table:table-cell>

        <table:table-cell office:value-type="float" office:value="11000">

            <text:p>11000</text:p>

        </table:table-cell>

        <table:table-cell table:formula="of:=0.2*[.B4]"
    office:value-type="float" office:value="2200">

            <text:p>2200</text:p>

        </table:table-cell>

    </table:table-row>

    

    On the first glance it seems the document has changed at five
    different places. At a closer look - with some ODF back-ground -
    only two changes are identified, because the following ODF relations
    create dependencies of changes:

    
      
The cell's @office:value attribute (see [1])
        is always reflected by the cell's paragraph content. 

      
Changing a cell's formula (@table:formula attribute, see [2])
        changes as well the cell's @office:value - if existent - and the
        cell's paragraph content

      

      
Changing a cell's content (text of child paragraph), which is
        referenced by another cell's formula results in general in a
        change of the @office:value and the paragraph text of the cell
        with the formula.

      

    
    
By the above dependencies the XML changes are mapped into
      basically two state changes, which can be mapped to two operations
      to be serialized using Merge-Enabled Change Tracking (MCT):

    

    
      
The change of cell value [.B4]

      
The change of the formula of cell [.C4] and the resulting cell
        value & paragraph text change

      

    
    Two comments on the operations to be created:

    
      
Tables are extraordinary ODF components. Tables are like two
        dimensional data arrays within the document tree. A world for
        its own. They got an own reference scheme (see [3][4])
        that should be reused by operations.

      
The at the beginning listed dependent changes due to ODF
        relations are like a set of operations being executed as a
        transition. Therefore a <transaction> element was added to
        MCT to represent the atomic change.

      
Instead to use two operations of delete and addition of the
        similar text sequence, the replace function has been added.

      
A properties of a component is in general named as the local
        name of the XML attribute (if unambiguous)

      

      
Properties of components are exchanged in total versus the
        text content of paragraphs, as properties will never be merged.

      
The component before the cell reference in the path /1/[.B4]
        have to be a table. If there is an URI or sheet locater in the
        reference, it have to be resolved to the table, otherwise OT
        will not work. 

      

    
    Changes from A to B (over A'):

    
    Only for demonstrating the changes, not required for change-tracking
    to undo the changes:

    <changes>

        <transaction>

            <replace s="/1/[.B4]/@value" value="11000"/>

            <replace s="/1/[.B4]/1/2">1</replace>

            <replace s="/1/[.C4]/@value" value="1650"/>

            <replace s="/1/[.C4]/1"
    s="/1/[.C4]/3">165</replace>

        </transaction>

        <transaction>

            <replace s="/1/[.C4]/@formula" value="of:=0.2*[.B4]"/>

            <replace s="/1/[.C4]/@value" value="2200"/>

            <replace s="/1/[.C4]/1"
    e="/1/[.C4]/3">220</replace>

        </transaction>

    </changes>

    State A' - intermediate:
    The intermediate after the first transaction is assumed to be 

    

    <table:table-row table:style-name="ro1">

        <table:table-cell office:value-type="float"
    office:value="2010">

            <text:p>2010</text:p>

        </table:table-cell>

        <table:table-cell office:value-type="float" office:value="11000">

            <text:p>11000</text:p>

        </table:table-cell>

        <table:table-cell table:formula="of:=0.15*[.B4]"
    office:value-type="float" office:value="1650">

            <text:p>1650</text:p>

        </table:table-cell>

    </table:table-row>

    

    Changes from B to A (over A'):
    The following are the operations necessary to undo the changes to be
    serialized in the undo.xml file:

    <changes>

        <transaction>

            <replace s="/1/[.C4]/@formula"
    value="of:=0.15*[.B4]"/>

            <replace s="/1/[.C4]/@value" value="1650"/>

            <replace s="/1/[.C4]/1"
    s="/1/[.C4]/3">165</replace>

        </transaction>

        <transaction>

            <replace s="/1/[.B4]/@value" value="10000"/>

            <replace s="/1/[.B4]/1/2">0</replace>

            <replace s="/1/[.C4]/@value" value="1500"/>

            <replace s="/1/[.C4]/1"
    e="/1/[.C4]/3">150</replace>

        </transaction>

    </changes>

    

    If we could assume that the ODF application is able to interpret
    formula and is aware how to map an @office:value to a paragraph
    text, again a lot of boilerplate could be removed:

    

    Redo.xml:
    
The redo.xml file is only for demonstration purpose and would
      only be saved using the history feature saving the document to the
      original state A and still able to go to the future state B.

    

    <changes>

        <replace s="/1/[.B4]/@value" value="11000"/>

        <replace s="/1/[.C4]/@formula" value="of:=0.2*[.B4]"/>

    </changes>

    

    

    Finally the MCT solution for change-tracking this example would be
    the file below:

    Undo.xml:
    <changes>

        <replace s="/1/[.C4]/@formula" value="of:=0.15*[.B4]"/>

        <replace s="/1/[.B4]/@value" value="10000"/>

    </changes>

    

    In the end only the essential operations would remain.

    

    - Svante

    

    [1]
    http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#attribute-office_value

    [2]
    http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#attribute-table_formula

    [3] http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part2.html#Reference

    [4] http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part2.html#References
← Prev in month ← Prev in thread