OpenDocument - Adv Document Collab SC

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

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

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

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

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

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

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