OpenDocument - Adv Document Collab SC

  • 1.  CT and Spreadsheet tables

    Posted 04-07-2011 12:18




    Hi all,

    thinking about CT in spreadsheet tables, I was wondering about how
    this is supposed to be handled by the generic proposal and whether
    the current way to track changes is compatible with Excel.

    Although the generic proposal is able to handle any possible kind of
    changes, spreadsheets with many formulas and dependencies are
    somewhat problematic. Let's have a look at the following example:

    ----------------------------
    4711                                            
    ----------------------------
    42         =SUM(A1:A2)
    ----------------------------

    Then we

    1. Insert a row
    2. Insert a column
    3. Change 4711 to 4712

    The result is

    ---------------------------------
    4712                                              
    ---------------------------------
                                                                   
    ---------------------------------
    42                 =SUM(A1:A3)
    ---------------------------------


    The result in the current implementation is this (I omitted some
    style information):

                      <table:tracked-changes>
                            <table:insertion table:id= ct1 table:type= row
    table:position= 1 table:table= 0 />
                            <table:insertion table:id= ct2
    table:type= column table:position= 1 table:table= 0 />
                            <table:cell-content-change table:id= ct3 >
                                  <table:cell-address table:column= 0
    table:row= 0 table:table= 0 />
                                  <table:previous>
                                        <table:change-track-table-cell
    office:value-type= float office:value= 4711 />
                                  </table:previous>
                            </table:cell-content-change>
                      </table:tracked-changes>
                      <table:table>
                            <table:table-column/>
                           <table:table-column
    table:number-columns-repeated= 2 />
                            <table:table-row>
                                  <table:table-cell office:value-type= float
    office:value= 4712 >
                                        <text:p>4712</text:p>
                                  </table:table-cell>
                                  <table:table-cell
    table:number-columns-repeated= 2 />
                            </table:table-row>
                            <table:table-row>
                                  <table:table-cell
    table:number-columns-repeated= 3 />
                            </table:table-row>
                            <table:table-row>
                                  <table:table-cell office:value-type= float
    office:value= 42 >
                                        <text:p>42</text:p>
                                  </table:table-cell>
                                  <table:table-cell/>
                                  <table:table-cell
    table:formula= of:=SUM([.A1:.A3]) office:value-type= float
    office:value= 4754 >
                                        <text:p>4754</text:p>
                                  </table:table-cell>
                            </table:table-row>
                      </table:table>

    Please note that there is no CT markup in the table xml code.
    There's only a high-level description of what has happened
    table:tracked-changes section. This results in a lean xml code, on
    the other hand you need to know some application logic in order to
    undo the changes, i.e. the office:value in C3 has to be adjusted if
    you revert the third change.

    Expressing this example using the generic ct proposal, the xml would
    look (somewhat) like this:

                      <table:table>
                            <table:table-column
    ac:change002= ct2,remove,table:number-columns-repeated,2 />
                            <table:table-column
    delta:insertion-type= insert-with-content
    delta:insertion-change-idref= ct2
    table:number-columns-repeated= 2 />
                            <table:table-row>
                                  <table:table-cell office:value-type= float
    ac:change003= ct3,modify,office:value,4711 office:value= 4712 >
                                        <delta:removed-content
    delta:removal-change-idref= ct3 >                
                                        <text:p>4711</text:p>
                                        </delta:removed-content>
                                        <text:p
    delta:insertion-type= insert-with-content
    delta:insertion-change-idref= ct3 >4712</text:p>
                                  </table:table-cell>
                                  <table:table-cell
    delta:insertion-type= insert-with-content
    delta:insertion-change-idref= ct2 />
                                  <table:table-cell/>
                            </table:table-row>
                            <table:table-row
    delta:insertion-type= insert-with-content
    delta:insertion-change-idref= ct1 >
                                  <table:table-cell
    ac:change002= ct2,modify,table:number-columns-repeated,2
    table:number-columns-repeated= 3 />
                            </table:table-row>
                            <table:table-row>
                                  <table:table-cell office:value-type= float
    office:value= 42 >
                                        <text:p>42</text:p>
                                  </table:table-cell>
                                  <table:table-cell
    delta:insertion-type= insert-with-content
    delta:insertion-change-idref= ct2 />
                                  <table:table-cell
    table:formula= of:=SUM([.A1:.A3])
    ac:change001= ct1,modify,table:formula,'of:=SUM([.A1:.A2])'
    office:value-type= float
                                                                                                         
                                                                     
    ac:change003= ct3,modify,office:value,4753 office:value= 4754 >
                                        <delta:removed-content
    delta:removal-change-idref= ct3 >                
                                        <text:p>4753</text:p>
                                        </delta:removed-content>
                                        <text:p
    delta:insertion-type= insert-with-content
    delta:insertion-change-idref= ct3 >4754</text:p>
                                  </table:table-cell>
                            </table:table-row>
                      </table:table>

    Any further changes made to the cell contents of A1 adds one
    attribute to A1 *and* to all depending cells, in this case C3. So in
    case of a large table with lots of dependencies this results in a
    bloated xml file (for 256 x 256 cells each depending on a single
    cell this means that each value change of this cell results in ~ 2MB
    of CT code only for the ac:change attributes). So from this point of
    view the current approach seems to be more efficient.

    Any opinions?

    Regards,

    Frank

    --

    Frank Meies Software Developer
    Phone: +49 49 23646 500

    Oracle OFFICE GBU

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

    ORACLE Deutschland B.V. & Co. KG
    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







  • 2.  Re: [office-collab] CT and Spreadsheet tables

    Posted 04-07-2011 19:10
    Frank, The issue here is the knock-on effect on calculated values. The simple solution is not to record calculated values in tracked changes... there is an argument to say they should not be in the interchange format at all because they are redundant... but that is a separate issue! But your point is a good one and would need to be resolved. A possible solution is that the specification identifies derived values and these could be ignored for CT purposes, as indeed they are in the current solution. This does not seem to be a difficult rule to define or to implement. Regards, Robin Frank Meies wrote: 4D9DAB6D.1080602@oracle.com type= cite > Hi all, thinking about CT in spreadsheet tables, I was wondering about how this is supposed to be handled by the generic proposal and whether the current way to track changes is compatible with Excel. Although the generic proposal is able to handle any possible kind of changes, spreadsheets with many formulas and dependencies are somewhat problematic. Let's have a look at the following example: ---------------------------- 4711                                             ---------------------------- 42         =SUM(A1:A2) ---------------------------- Then we 1. Insert a row 2. Insert a column 3. Change 4711 to 4712 The result is --------------------------------- 4712                                               ---------------------------------                                                                 --------------------------------- 42                 =SUM(A1:A3) --------------------------------- The result in the current implementation is this (I omitted some style information):                   <table:tracked-changes>                         <table:insertion table:id= ct1 table:type= row table:position= 1 table:table= 0 />                         <table:insertion table:id= ct2 table:type= column table:position= 1 table:table= 0 />                         <table:cell-content-change table:id= ct3 >                               <table:cell-address table:column= 0 table:row= 0 table:table= 0 />                               <table:previous>                                     <table:change-track-table-cell office:value-type= float office:value= 4711 />                               </table:previous>                         </table:cell-content-change>                   </table:tracked-changes>                   <table:table>                         <table:table-column/>                        <table:table-column table:number-columns-repeated= 2 />                         <table:table-row>                               <table:table-cell office:value-type= float office:value= 4712 >                                     <text:p>4712</text:p>                               </table:table-cell>                               <table:table-cell table:number-columns-repeated= 2 />                         </table:table-row>                         <table:table-row>                               <table:table-cell table:number-columns-repeated= 3 />                         </table:table-row>                         <table:table-row>                               <table:table-cell office:value-type= float office:value= 42 >                                     <text:p>42</text:p>                               </table:table-cell>                               <table:table-cell/>                               <table:table-cell table:formula= of:=SUM([.A1:.A3]) office:value-type= float office:value= 4754 >                                     <text:p>4754</text:p>                               </table:table-cell>                         </table:table-row>                   </table:table> Please note that there is no CT markup in the table xml code. There's only a high-level description of what has happened table:tracked-changes section. This results in a lean xml code, on the other hand you need to know some application logic in order to undo the changes, i.e. the office:value in C3 has to be adjusted if you revert the third change. Expressing this example using the generic ct proposal, the xml would look (somewhat) like this:                   <table:table>                         <table:table-column ac:change002= ct2,remove,table:number-columns-repeated,2 />                         <table:table-column delta:insertion-type= insert-with-content delta:insertion-change-idref= ct2 table:number-columns-repeated= 2 />                         <table:table-row>                               <table:table-cell office:value-type= float ac:change003= ct3,modify,office:value,4711 office:value= 4712 >                                     <delta:removed-content delta:removal-change-idref= ct3 >                                                     <text:p>4711</text:p>                                     </delta:removed-content>                                     <text:p delta:insertion-type= insert-with-content delta:insertion-change-idref= ct3 >4712</text:p>                               </table:table-cell>                               <table:table-cell delta:insertion-type= insert-with-content delta:insertion-change-idref= ct2 />                               <table:table-cell/>                         </table:table-row>                         <table:table-row delta:insertion-type= insert-with-content delta:insertion-change-idref= ct1 >                               <table:table-cell ac:change002= ct2,modify,table:number-columns-repeated,2 table:number-columns-repeated= 3 />                         </table:table-row>                         <table:table-row>                               <table:table-cell office:value-type= float office:value= 42 >                                     <text:p>42</text:p>                               </table:table-cell>                               <table:table-cell delta:insertion-type= insert-with-content delta:insertion-change-idref= ct2 />                               <table:table-cell table:formula= of:=SUM([.A1:.A3]) ac:change001= ct1,modify,table:formula,'of:=SUM([.A1:.A2])' office:value-type= float                                                                                                                                                                         ac:change003= ct3,modify,office:value,4753 office:value= 4754 >                                     <delta:removed-content delta:removal-change-idref= ct3 >                                                     <text:p>4753</text:p>                                     </delta:removed-content>                                     <text:p delta:insertion-type= insert-with-content delta:insertion-change-idref= ct3 >4754</text:p>                               </table:table-cell>                         </table:table-row>                   </table:table> Any further changes made to the cell contents of A1 adds one attribute to A1 *and* to all depending cells, in this case C3. So in case of a large table with lots of dependencies this results in a bloated xml file (for 256 x 256 cells each depending on a single cell this means that each value change of this cell results in ~ 2MB of CT code only for the ac:change attributes). So from this point of view the current approach seems to be more efficient. Any opinions? Regards, Frank -- Frank Meies Software Developer Phone: +49 49 23646 500 Oracle OFFICE GBU ORACLE Deutschland B.V. & Co. KG Nagelsweg 55 20097 Hamburg ORACLE Deutschland B.V. & Co. KG 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 -- -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd Change control for XML T: +44 1684 592 144 E: robin.lafontaine@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK


  • 3.  Re: [office-collab] CT and Spreadsheet tables

    Posted 04-08-2011 05:55




    Hi,

    On 07.04.2011 21:01, Robin LaFontaine wrote:
    4D9E0A22.3000903@deltaxml.com type= cite >


    Frank,

    The issue here is the knock-on effect on calculated values. The
    simple
    solution is not to record calculated values in tracked changes...
    It is not only an effect on calculated values. These indeed may be
    omitted in the recorded cells.

    If you insert a row or column into a speadsheet, office applications
    update the formulas in the cells so that they still refer to the
    original ones. For instance, if you have a formula referencing B1
    and insert a column as first column, then that reference becomes C1
    because columns B becomes column C. In the worst case, all formulas
    are adapted.

    But maybe this could also be resolved by omitting the formulas in
    the recalculated cells.

    Best regards

    Michael
    4D9E0A22.3000903@deltaxml.com type= cite >
    there
    is an argument to say they should not be in the interchange format
    at
    all because they are redundant... but that is a separate issue!

    But your point is a good one and would need to be resolved. A
    possible
    solution is that the specification identifies derived values and
    these
    could be ignored for CT purposes, as indeed they are in the
    current
    solution. This does not seem to be a difficult rule to define or
    to
    implement.

    Regards,
    Robin

    Frank Meies wrote:
    4D9DAB6D.1080602@oracle.com type= cite >

    Hi all,

    thinking about CT in spreadsheet tables, I was wondering about
    how this
    is supposed to be handled by the generic proposal and whether
    the
    current way to track changes is compatible with Excel.

    Although the generic proposal is able to handle any possible
    kind of
    changes, spreadsheets with many formulas and dependencies are
    somewhat
    problematic. Let's have a look at the following example:

    ----------------------------
    4711                                            
    ----------------------------
    42         =SUM(A1:A2)
    ----------------------------

    Then we

    1. Insert a row
    2. Insert a column
    3. Change 4711 to 4712

    The result is

    ---------------------------------
    4712                                              
    ---------------------------------
                                                                   
    ---------------------------------
    42                 =SUM(A1:A3)
    ---------------------------------


    The result in the current implementation is this (I omitted some
    style
    information):

                      <table:tracked-changes>
                            <table:insertion table:id= ct1
    table:type= row
    table:position= 1 table:table= 0 />
                            <table:insertion table:id= ct2
    table:type= column
    table:position= 1 table:table= 0 />
                            <table:cell-content-change table:id= ct3 >
                                  <table:cell-address table:column= 0
    table:row= 0 table:table= 0 />
                                  <table:previous>
                                        <table:change-track-table-cell
    office:value-type= float office:value= 4711 />
                                  </table:previous>
                            </table:cell-content-change>
                      </table:tracked-changes>
                      <table:table>
                            <table:table-column/>
                           <table:table-column
    table:number-columns-repeated= 2 />
                            <table:table-row>
                                  <table:table-cell
    office:value-type= float
    office:value= 4712 >
                                        <text:p>4712</text:p>
                                  </table:table-cell>
                                  <table:table-cell
    table:number-columns-repeated= 2 />
                            </table:table-row>
                            <table:table-row>
                                  <table:table-cell
    table:number-columns-repeated= 3 />
                            </table:table-row>
                            <table:table-row>
                                  <table:table-cell
    office:value-type= float
    office:value= 42 >
                                        <text:p>42</text:p>
                                  </table:table-cell>
                                  <table:table-cell/>
                                  <table:table-cell
    table:formula= of:=SUM([.A1:.A3]) office:value-type= float
    office:value= 4754 >
                                        <text:p>4754</text:p>
                                  </table:table-cell>
                            </table:table-row>
                      </table:table>

    Please note that there is no CT markup in the table xml code.
    There's
    only a high-level description of what has happened
    table:tracked-changes section. This results in a lean xml code,
    on the
    other hand you need to know some application logic in order to
    undo the
    changes, i.e. the office:value in C3 has to be adjusted if you
    revert
    the third change.

    Expressing this example using the generic ct proposal, the xml
    would
    look (somewhat) like this:

                      <table:table>
                            <table:table-column
    ac:change002= ct2,remove,table:number-columns-repeated,2 />
                            <table:table-column
    delta:insertion-type= insert-with-content
    delta:insertion-change-idref= ct2
    table:number-columns-repeated= 2 />
                            <table:table-row>
                                  <table:table-cell
    office:value-type= float
    ac:change003= ct3,modify,office:value,4711
    office:value= 4712 >
                                        <delta:removed-content
    delta:removal-change-idref= ct3 >                
                                        <text:p>4711</text:p>
                                        </delta:removed-content>
                                        <text:p
    delta:insertion-type= insert-with-content
    delta:insertion-change-idref= ct3 >4712</text:p>
                                  </table:table-cell>
                                  <table:table-cell
    delta:insertion-type= insert-with-content
    delta:insertion-change-idref= ct2 />
                                  <table:table-cell/>
                            </table:table-row>
                            <table:table-row
    delta:insertion-type= insert-with-content
    delta:insertion-change-idref= ct1 >
                                  <table:table-cell
    ac:change002= ct2,modify,table:number-columns-repeated,2
    table:number-columns-repeated= 3 />
                            </table:table-row>
                            <table:table-row>
                                  <table:table-cell
    office:value-type= float
    office:value= 42 >
                                        <text:p>42</text:p>
                                  </table:table-cell>
                                  <table:table-cell
    delta:insertion-type= insert-with-content
    delta:insertion-change-idref= ct2 />
                                  <table:table-cell
    table:formula= of:=SUM([.A1:.A3])
    ac:change001= ct1,modify,table:formula,'of:=SUM([.A1:.A2])'
    office:value-type= float
                                                                                                   
               
                                                               
    ac:change003= ct3,modify,office:value,4753
    office:value= 4754 >
                                        <delta:removed-content
    delta:removal-change-idref= ct3 >                
                                        <text:p>4753</text:p>
                                        </delta:removed-content>
                                        <text:p
    delta:insertion-type= insert-with-content
    delta:insertion-change-idref= ct3 >4754</text:p>
                                  </table:table-cell>
                            </table:table-row>
                      </table:table>

    Any further changes made to the cell contents of A1 adds one
    attribute
    to A1 *and* to all depending cells, in this case C3. So in case
    of a
    large table with lots of dependencies this results in a bloated
    xml
    file (for 256 x 256 cells each depending on a single cell this
    means
    that each value change of this cell results in ~ 2MB of CT code
    only
    for the ac:change attributes). So from this point of view the
    current
    approach seems to be more efficient.

    Any opinions?

    Regards,

    Frank

    --

    Frank
    Meies Software Developer
    Phone: +49
    49 23646 500
    Oracle OFFICE GBU

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

    ORACLE
    Deutschland B.V. & Co. KG
    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




    --
    -- -----------------------------------------------------------------
    Robin La Fontaine, Director, DeltaXML Ltd Change control for XML
    T: +44 1684 592 144 E: robin.lafontaine@deltaxml.com
    http://www.deltaxml.com
    Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK



    --

    Michael Brauer Oracle Office Development
    Phone: +49 40 23646 500


    Oracle Office Global Business Unit

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

    ORACLE Deutschland B.V. & Co. KG
    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







  • 4.  Re: [office-collab] CT and Spreadsheet tables

    Posted 04-08-2011 12:51
    Michael Brauer <michael.brauer@oracle.com> wrote on 04/08/2011 01:54:33 AM: > > If you insert a row or column into a speadsheet, office applications > update the formulas in the cells so that they still refer to the > original ones. For instance, if you have a formula referencing B1 > and insert a column as first column, then that reference becomes C1 > because columns B becomes column C. In the worst case, all formulas > are adapted. > > But maybe this could also be resolved by omitting the formulas in > the recalculated cells. > Another solution would be for ODF to allow the use of R1C1 cell address notation. That is out of scope for this SC, but if the TC adopted R1C1 notation, then insertions like this would leave most cell addresses unchanged. See: http://smurfonspreadsheets.wordpress.com/2007/11/12/r1c1-notation/ This might be a general topic for ODF 1.3 -- are there things we can do to enable more efficient storage of large tables, especially now that we see million-row spreadsheet documents. -Rob


  • 5.  Re: [office-collab] CT and Spreadsheet tables

    Posted 04-08-2011 12:57
    Michael, Yes, you are correct - I should not work late on a train home! The change tracking will certainly be a lot shorter if formulae are omitted in recalculated cells, but this will put a burden both on the specification and on the application. For example, the specification would need to say exactly how a row insertion is handled in terms of the modification to all the formulae (on all the worksheets) , and   all applications would need to implement this. It could be a challenge to specify how that is done, and to test it. There is some similarity also with a global change where a simple editing operation results in a lot of changes throughout the document. But in this case it certainly seems sensible to record all the individual changes. There are some choices to be made here. In my own experience of data exchange formats, it is usually dangerous to provide shorthand ways of doing things, and being explicit and detailed is usually worth the cost of extra storage space. It may not look so nice, but it keeps the specification simpler and avoids ambiguity. Regards, Robin On 08/04/2011 06:54, Michael Brauer wrote: 4D9EA319.5030504@oracle.com type= cite > Hi, On 07.04.2011 21:01, Robin LaFontaine wrote: 4D9E0A22.3000903@deltaxml.com type= cite > Frank, The issue here is the knock-on effect on calculated values. The simple solution is not to record calculated values in tracked changes... It is not only an effect on calculated values. These indeed may be omitted in the recorded cells. If you insert a row or column into a speadsheet, office applications update the formulas in the cells so that they still refer to the original ones. For instance, if you have a formula referencing B1 and insert a column as first column, then that reference becomes C1 because columns B becomes column C. In the worst case, all formulas are adapted. But maybe this could also be resolved by omitting the formulas in the recalculated cells. Best regards Michael 4D9E0A22.3000903@deltaxml.com type= cite > there is an argument to say they should not be in the interchange format at all because they are redundant... but that is a separate issue! But your point is a good one and would need to be resolved. A possible solution is that the specification identifies derived values and these could be ignored for CT purposes, as indeed they are in the current solution. This does not seem to be a difficult rule to define or to implement. Regards, Robin Frank Meies wrote: 4D9DAB6D.1080602@oracle.com type= cite > Hi all, thinking about CT in spreadsheet tables, I was wondering about how this is supposed to be handled by the generic proposal and whether the current way to track changes is compatible with Excel. Although the generic proposal is able to handle any possible kind of changes, spreadsheets with many formulas and dependencies are somewhat problematic. Let's have a look at the following example: ---------------------------- 4711                                             ---------------------------- 42         =SUM(A1:A2) ---------------------------- Then we 1. Insert a row 2. Insert a column 3. Change 4711 to 4712 The result is --------------------------------- 4712                                               ---------------------------------                                                                 --------------------------------- 42                 =SUM(A1:A3) --------------------------------- The result in the current implementation is this (I omitted some style information):                   <table:tracked-changes>                         <table:insertion table:id= ct1 table:type= row table:position= 1 table:table= 0 />                         <table:insertion table:id= ct2 table:type= column table:position= 1 table:table= 0 />                         <table:cell-content-change table:id= ct3 >                               <table:cell-address table:column= 0 table:row= 0 table:table= 0 />                               <table:previous>                                     <table:change-track-table-cell office:value-type= float office:value= 4711 />                               </table:previous>                         </table:cell-content-change>                   </table:tracked-changes>                   <table:table>                         <table:table-column/>                        <table:table-column table:number-columns-repeated= 2 />                         <table:table-row>                               <table:table-cell office:value-type= float office:value= 4712 >                                     <text:p>4712</text:p>                               </table:table-cell>                               <table:table-cell table:number-columns-repeated= 2 />                         </table:table-row>                         <table:table-row>                               <table:table-cell table:number-columns-repeated= 3 />                         </table:table-row>                         <table:table-row>                               <table:table-cell office:value-type= float office:value= 42 >                                     <text:p>42</text:p>                               </table:table-cell>                               <table:table-cell/>                               <table:table-cell table:formula= of:=SUM([.A1:.A3]) office:value-type= float office:value= 4754 >                                     <text:p>4754</text:p>                               </table:table-cell>                         </table:table-row>                   </table:table> Please note that there is no CT markup in the table xml code. There's only a high-level description of what has happened table:tracked-changes section. This results in a lean xml code, on the other hand you need to know some application logic in order to undo the changes, i.e. the office:value in C3 has to be adjusted if you revert the third change. Expressing this example using the generic ct proposal, the xml would look (somewhat) like this:                   <table:table>                         <table:table-column ac:change002= ct2,remove,table:number-columns-repeated,2 />                         <table:table-column delta:insertion-type= insert-with-content delta:insertion-change-idref= ct2 table:number-columns-repeated= 2 />                         <table:table-row>                               <table:table-cell office:value-type= float ac:change003= ct3,modify,office:value,4711 office:value= 4712 >                                     <delta:removed-content delta:removal-change-idref= ct3 >                                                     <text:p>4711</text:p>                                     </delta:removed-content>                                     <text:p delta:insertion-type= insert-with-content delta:insertion-change-idref= ct3 >4712</text:p>                               </table:table-cell>                               <table:table-cell delta:insertion-type= insert-with-content delta:insertion-change-idref= ct2 />                               <table:table-cell/>                         </table:table-row>                         <table:table-row delta:insertion-type= insert-with-content delta:insertion-change-idref= ct1 >                               <table:table-cell ac:change002= ct2,modify,table:number-columns-repeated,2 table:number-columns-repeated= 3 />                         </table:table-row>                         <table:table-row>                               <table:table-cell office:value-type= float office:value= 42 >                                     <text:p>42</text:p>                               </table:table-cell>                               <table:table-cell delta:insertion-type= insert-with-content delta:insertion-change-idref= ct2 />                               <table:table-cell table:formula= of:=SUM([.A1:.A3]) ac:change001= ct1,modify,table:formula,'of:=SUM([.A1:.A2])' office:value-type= float                                                                                                                                                                         ac:change003= ct3,modify,office:value,4753 office:value= 4754 >                                     <delta:removed-content delta:removal-change-idref= ct3 >                                                     <text:p>4753</text:p>                                     </delta:removed-content>                                     <text:p delta:insertion-type= insert-with-content delta:insertion-change-idref= ct3 >4754</text:p>                               </table:table-cell>                         </table:table-row>                   </table:table> Any further changes made to the cell contents of A1 adds one attribute to A1 *and* to all depending cells, in this case C3. So in case of a large table with lots of dependencies this results in a bloated xml file (for 256 x 256 cells each depending on a single cell this means that each value change of this cell results in ~ 2MB of CT code only for the ac:change attributes). So from this point of view the current approach seems to be more efficient. Any opinions? Regards, Frank -- Frank Meies Software Developer Phone: +49 49 23646 500 Oracle OFFICE GBU ORACLE Deutschland B.V. & Co. KG Nagelsweg 55 20097 Hamburg ORACLE Deutschland B.V. & Co. KG 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 -- -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd Change control for XML T: +44 1684 592 144 E: robin.lafontaine@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK -- Michael Brauer Oracle Office Development Phone: +49 40 23646 500 Oracle Office Global Business Unit ORACLE Deutschland B.V. & Co. KG Nagelsweg 55 20097 Hamburg ORACLE Deutschland B.V. & Co. KG 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 -- -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd Change control for XML T: +44 1684 592 144 E: robin.lafontaine@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK


  • 6.  Re: [office-collab] CT and Spreadsheet tables

    Posted 04-11-2011 11:00
    Hi Robin, On 08.04.2011 14:57, Robin LaFontaine wrote: 4D9F0627.70506@deltaxml.com type= cite > Michael, Yes, you are correct - I should not work late on a train home! The change tracking will certainly be a lot shorter if formulae are omitted in recalculated cells, but this will put a burden both on the specification and on the application. For example, the specification would need to say exactly how a row insertion is handled in terms of the modification to all the formulae (on all the worksheets) , and   all applications would need to implement this. It could be a challenge to specify how that is done, and to test it. There is some similarity also with a global change where a simple editing operation results in a lot of changes throughout the document. But in this case it certainly seems sensible to record all the individual changes. There are some choices to be made here. In my own experience of data exchange formats, it is usually dangerous to provide shorthand ways of doing things, and being explicit and detailed is usually worth the cost of extra storage space. It may not look so nice, but it keeps the specification simpler and avoids ambiguity. Well, it is not only the cost of extra storage. It is also the cost of processing the additional data. You need to process it during zip/unzip operations and during parsing/writing documents at least. Another interesting question is what information the application that stores change tracking has at hands at the time a document is saved. If an application just adapts the formulas and throws the old ones away (since it knows how to re-calculate them, and since keeping them may consume too much memory), then storing the old attribute values actually may be very expensive. So, in this case it may be worth to research how difficult it actually would be for an application to calculate the old formula values. And if the effort is reasonable, I would consider the option to omit the formulas. Best regards Michael 4D9F0627.70506@deltaxml.com type= cite > Regards, Robin On 08/04/2011 06:54, Michael Brauer wrote: 4D9EA319.5030504@oracle.com type= cite > Hi, On 07.04.2011 21:01, Robin LaFontaine wrote: 4D9E0A22.3000903@deltaxml.com type= cite > Frank, The issue here is the knock-on effect on calculated values. The simple solution is not to record calculated values in tracked changes... It is not only an effect on calculated values. These indeed may be omitted in the recorded cells. If you insert a row or column into a speadsheet, office applications update the formulas in the cells so that they still refer to the original ones. For instance, if you have a formula referencing B1 and insert a column as first column, then that reference becomes C1 because columns B becomes column C. In the worst case, all formulas are adapted. But maybe this could also be resolved by omitting the formulas in the recalculated cells. Best regards Michael 4D9E0A22.3000903@deltaxml.com type= cite > there is an argument to say they should not be in the interchange format at all because they are redundant... but that is a separate issue! But your point is a good one and would need to be resolved. A possible solution is that the specification identifies derived values and these could be ignored for CT purposes, as indeed they are in the current solution. This does not seem to be a difficult rule to define or to implement. Regards, Robin Frank Meies wrote: 4D9DAB6D.1080602@oracle.com type= cite > Hi all, thinking about CT in spreadsheet tables, I was wondering about how this is supposed to be handled by the generic proposal and whether the current way to track changes is compatible with Excel. Although the generic proposal is able to handle any possible kind of changes, spreadsheets with many formulas and dependencies are somewhat problematic. Let's have a look at the following example: ---------------------------- 4711                                             ---------------------------- 42         =SUM(A1:A2) ---------------------------- Then we 1. Insert a row 2. Insert a column 3. Change 4711 to 4712 The result is --------------------------------- 4712                                               ---------------------------------                                                                 --------------------------------- 42                 =SUM(A1:A3) --------------------------------- The result in the current implementation is this (I omitted some style information):                   <table:tracked-changes>                         <table:insertion table:id= ct1 table:type= row table:position= 1 table:table= 0 />                         <table:insertion table:id= ct2 table:type= column table:position= 1 table:table= 0 />                         <table:cell-content-change table:id= ct3 >                               <table:cell-address table:column= 0 table:row= 0 table:table= 0 />                               <table:previous>                                     <table:change-track-table-cell office:value-type= float office:value= 4711 />                               </table:previous>                         </table:cell-content-change>                   </table:tracked-changes>                   <table:table>                         <table:table-column/>                        <table:table-column table:number-columns-repeated= 2 />                         <table:table-row>                               <table:table-cell office:value-type= float office:value= 4712 >                                     <text:p>4712</text:p>                               </table:table-cell>                               <table:table-cell table:number-columns-repeated= 2 />                         </table:table-row>                         <table:table-row>                               <table:table-cell table:number-columns-repeated= 3 />                         </table:table-row>                         <table:table-row>                               <table:table-cell office:value-type= float office:value= 42 >                                     <text:p>42</text:p>                               </table:table-cell>                               <table:table-cell/>                               <table:table-cell table:formula= of:=SUM([.A1:.A3]) office:value-type= float office:value= 4754 >                                     <text:p>4754</text:p>                               </table:table-cell>                         </table:table-row>                   </table:table> Please note that there is no CT markup in the table xml code. There's only a high-level description of what has happened table:tracked-changes section. This results in a lean xml code, on the other hand you need to know some application logic in order to undo the changes, i.e. the office:value in C3 has to be adjusted if you revert the third change. Expressing this example using the generic ct proposal, the xml would look (somewhat) like this:                   <table:table>                         <table:table-column ac:change002= ct2,remove,table:number-columns-repeated,2 />                         <table:table-column delta:insertion-type= insert-with-content delta:insertion-change-idref= ct2 table:number-columns-repeated= 2 />                         <table:table-row>                               <table:table-cell office:value-type= float ac:change003= ct3,modify,office:value,4711 office:value= 4712 >                                     <delta:removed-content delta:removal-change-idref= ct3 >                                                     <text:p>4711</text:p>                                     </delta:removed-content>                                     <text:p delta:insertion-type= insert-with-content delta:insertion-change-idref= ct3 >4712</text:p>                               </table:table-cell>                               <table:table-cell delta:insertion-type= insert-with-content delta:insertion-change-idref= ct2 />                               <table:table-cell/>                         </table:table-row>                         <table:table-row delta:insertion-type= insert-with-content delta:insertion-change-idref= ct1 >                               <table:table-cell ac:change002= ct2,modify,table:number-columns-repeated,2 table:number-columns-repeated= 3 />                         </table:table-row>                         <table:table-row>                               <table:table-cell office:value-type= float office:value= 42 >                                     <text:p>42</text:p>                               </table:table-cell>                               <table:table-cell delta:insertion-type= insert-with-content delta:insertion-change-idref= ct2 />                               <table:table-cell table:formula= of:=SUM([.A1:.A3]) ac:change001= ct1,modify,table:formula,'of:=SUM([.A1:.A2])' office:value-type= float                                                                                                                                                                         ac:change003= ct3,modify,office:value,4753 office:value= 4754 >                                     <delta:removed-content delta:removal-change-idref= ct3 >                                                     <text:p>4753</text:p>                                     </delta:removed-content>                                     <text:p delta:insertion-type= insert-with-content delta:insertion-change-idref= ct3 >4754</text:p>                               </table:table-cell>                         </table:table-row>                   </table:table> Any further changes made to the cell contents of A1 adds one attribute to A1 *and* to all depending cells, in this case C3. So in case of a large table with lots of dependencies this results in a bloated xml file (for 256 x 256 cells each depending on a single cell this means that each value change of this cell results in ~ 2MB of CT code only for the ac:change attributes). So from this point of view the current approach seems to be more efficient. Any opinions? Regards, Frank -- Frank Meies Software Developer Phone: +49 49 23646 500 Oracle OFFICE GBU ORACLE Deutschland B.V. & Co. KG Nagelsweg 55 20097 Hamburg ORACLE Deutschland B.V. & Co. KG 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 -- -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd Change control for XML T: +44 1684 592 144 E: robin.lafontaine@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK -- Michael Brauer Oracle Office Development Phone: +49 40 23646 500 Oracle Office Global Business Unit ORACLE Deutschland B.V. & Co. KG Nagelsweg 55 20097 Hamburg ORACLE Deutschland B.V. & Co. KG 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 -- -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd Change control for XML T: +44 1684 592 144 E: robin.lafontaine@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK -- Michael Brauer Oracle Office Development Phone: +49 40 23646 500 Oracle Office Global Business Unit ORACLE Deutschland B.V. & Co. KG Nagelsweg 55 20097 Hamburg ORACLE Deutschland B.V. & Co. KG 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


  • 7.  Re: [office-collab] CT and Spreadsheet tables

    Posted 04-07-2011 20:51
    Frank, The issue here is the knock-on effect on calculated values. Is there any need to record calculated values in tracked changes? But your point is a good one and would need to be resolved. A possible solution is that the specification identifies derived values and these could be ignored for CT purposes, as indeed they are in the current solution. This does not seem to be a difficult rule to define or to implement. Regards, Robin Frank Meies wrote: 4D9DAB6D.1080602@oracle.com type= cite > Hi all, thinking about CT in spreadsheet tables, I was wondering about how this is supposed to be handled by the generic proposal and whether the current way to track changes is compatible with Excel. Although the generic proposal is able to handle any possible kind of changes, spreadsheets with many formulas and dependencies are somewhat problematic. Let's have a look at the following example: ---------------------------- 4711                                             ---------------------------- 42         =SUM(A1:A2) ---------------------------- Then we 1. Insert a row 2. Insert a column 3. Change 4711 to 4712 The result is --------------------------------- 4712                                               ---------------------------------                                                                 --------------------------------- 42                 =SUM(A1:A3) --------------------------------- The result in the current implementation is this (I omitted some style information):                   <table:tracked-changes>                         <table:insertion table:id= ct1 table:type= row table:position= 1 table:table= 0 />                         <table:insertion table:id= ct2 table:type= column table:position= 1 table:table= 0 />                         <table:cell-content-change table:id= ct3 >                               <table:cell-address table:column= 0 table:row= 0 table:table= 0 />                               <table:previous>                                     <table:change-track-table-cell office:value-type= float office:value= 4711 />                               </table:previous>                         </table:cell-content-change>                   </table:tracked-changes>                   <table:table>                         <table:table-column/>                        <table:table-column table:number-columns-repeated= 2 />                         <table:table-row>                               <table:table-cell office:value-type= float office:value= 4712 >                                     <text:p>4712</text:p>                               </table:table-cell>                               <table:table-cell table:number-columns-repeated= 2 />                         </table:table-row>                         <table:table-row>                               <table:table-cell table:number-columns-repeated= 3 />                         </table:table-row>                         <table:table-row>                               <table:table-cell office:value-type= float office:value= 42 >                                     <text:p>42</text:p>                               </table:table-cell>                               <table:table-cell/>                               <table:table-cell table:formula= of:=SUM([.A1:.A3]) office:value-type= float office:value= 4754 >                                     <text:p>4754</text:p>                               </table:table-cell>                         </table:table-row>                   </table:table> Please note that there is no CT markup in the table xml code. There's only a high-level description of what has happened table:tracked-changes section. This results in a lean xml code, on the other hand you need to know some application logic in order to undo the changes, i.e. the office:value in C3 has to be adjusted if you revert the third change. Expressing this example using the generic ct proposal, the xml would look (somewhat) like this:                   <table:table>                         <table:table-column ac:change002= ct2,remove,table:number-columns-repeated,2 />                         <table:table-column delta:insertion-type= insert-with-content delta:insertion-change-idref= ct2 table:number-columns-repeated= 2 />                         <table:table-row>                               <table:table-cell office:value-type= float ac:change003= ct3,modify,office:value,4711 office:value= 4712 >                                     <delta:removed-content delta:removal-change-idref= ct3 >                                                     <text:p>4711</text:p>                                     </delta:removed-content>                                     <text:p delta:insertion-type= insert-with-content delta:insertion-change-idref= ct3 >4712</text:p>                               </table:table-cell>                               <table:table-cell delta:insertion-type= insert-with-content delta:insertion-change-idref= ct2 />                               <table:table-cell/>                         </table:table-row>                         <table:table-row delta:insertion-type= insert-with-content delta:insertion-change-idref= ct1 >                               <table:table-cell ac:change002= ct2,modify,table:number-columns-repeated,2 table:number-columns-repeated= 3 />                         </table:table-row>                         <table:table-row>                               <table:table-cell office:value-type= float office:value= 42 >                                     <text:p>42</text:p>                               </table:table-cell>                               <table:table-cell delta:insertion-type= insert-with-content delta:insertion-change-idref= ct2 />                               <table:table-cell table:formula= of:=SUM([.A1:.A3]) ac:change001= ct1,modify,table:formula,'of:=SUM([.A1:.A2])' office:value-type= float                                                                                                                                                                         ac:change003= ct3,modify,office:value,4753 office:value= 4754 >                                     <delta:removed-content delta:removal-change-idref= ct3 >                                                     <text:p>4753</text:p>                                     </delta:removed-content>                                     <text:p delta:insertion-type= insert-with-content delta:insertion-change-idref= ct3 >4754</text:p>                               </table:table-cell>                         </table:table-row>                   </table:table> Any further changes made to the cell contents of A1 adds one attribute to A1 *and* to all depending cells, in this case C3. So in case of a large table with lots of dependencies this results in a bloated xml file (for 256 x 256 cells each depending on a single cell this means that each value change of this cell results in ~ 2MB of CT code only for the ac:change attributes). So from this point of view the current approach seems to be more efficient. Any opinions? Regards, Frank -- Frank Meies Software Developer Phone: +49 49 23646 500 Oracle OFFICE GBU ORACLE Deutschland B.V. & Co. KG Nagelsweg 55 20097 Hamburg ORACLE Deutschland B.V. & Co. KG 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 -- -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd Change control for XML T: +44 1684 592 144 E: robin.lafontaine@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK