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
|