[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Change-Tracking of Tables
In ODF the XML model for tables of presentation, text and
spreadsheet table is with minor exception very similar. For example,
an exception is the superset of change-tracking for spreadsheet
tables. We agreed about two calls ago that we want to strive to make the system as simple as possible, therefore continue with the design idea of ODF XML or re-usage across formats and similar reuse as many operations/changes as possible across the different file formats. The table - as a de facto two dimensional array of cells - brings challenges to the designer of XML and operations. While the grouping of rows and columns are arbitrary horizontal and vertical selection of cells, in XML only rows do contain cells to avoid the problem of data redundancy. Analogue we should solve the problem of positioning cells within tables. Therefore a cell position always consists of a three positions:
At least three positions, but it can be more as the table could be itself nested somewhere. As I have now implemented a majority of operation support for as well text and a spreadsheet, I would like to share some of my mistakes and insights made from the implementation.Text is the most frequent used document format and therefore text tables were implemented first. For text tables we created a table and explicitly tracked every addition of row and cell. Columns were created implicitly during table creation by a list of widths In Spreadsheets on the other hand the expansion of the table is close to infinite and usually only limited by the abilities of applications. A Spreadsheet with only a single empty cell is still shown by all ODF applications as 'infinite' table. By this we were forced with Spreadsheets to use a different approach and expand the ODF XML table on demand. This way of automatic expansion behavior can work and should be applied similar for text and presentation tables. To make a long implementation journey a short story, I came to the conclusion that features such as the selection of a cell range and doing various scenarios with the cells of the range such as
Are best implemented (best in sense of reusing as much source as
possible) by dividing the following two functions
Therefore I am using now only one method to select a range of cells, providing four positions:a "row start & end" and "cell (aka column) right and left" position. In case of infinity the zero was chosen as position (assuming that counting starts with 1 similar to XML/XPath). By this the cells of the complete table, rows, columns or cell ranges are handled by a single entity. After the selected table/row/column/cells have been selected (or
cut out, repeated cells/rows/columns broken up and/or on demand
the table is being expanded) on each table/row/column/cell a
change is being applied. I guess the above should be enough to start a discussion on
tomorrow's talk. PS: Please excuse the delay of post, currently I am changing the
house with my family and packing the interior of a house into
boxes is always a fountain of joy and recuperation ;) Kind regards, |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]