OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-collab message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: CT and Spreadsheet tables


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

--
Oracle
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

Green
          Oracle Oracle is committed to developing practices and products that help protect the environment


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]