Dear TC Members,
while reading the discussion, I have to express my dismay to the
proposal and more broadly to the various spreadsheet concepts. It seems
little has been learned from past mistakes.
Warren Turkal wrote:
[...]
This doesn't seem useful to me. If I never address anything in those
cells that are outside my range, I'd say it's pretty likely I don't
care about them, and just knowing the max row/col size of the saving
application doesn't tell you that.
[see http://lists.oasis-open.org/archives/office/200811/msg00138.html]
I must strongly back up Warren on this one.
Lets say it this way: suppose I have a spreadsheet program WITHOUT any
grid-size limit (because it implements a very clever iterative mechanism
- making it virtually infinitely wide). I create a 2 columns by 2 rows
spreadsheet. BUT this one is virtually non-openable in any other
program! So, basically THIS spreadsheet program, WHILE FULLY
ODF-CONFORMANT, does create spreadsheets that are NOT READABLE by ANY
other application. So, why the fuss with ODF than?
This is BAD standard design, depending on an implementation detail.
Lets move further. Putting the constraints on the application is
definitely wrong. Even if an application supports 1E+30 rows, it is
still MOST likely that 90% of users will use less than 10,000 rows, and
that 99% of them will use less than 30,000 rows. So, WHY put a
MAX_GRID_SIZE at 1E+30 then?
A different measure is useful! And Apple solved this nicely in Numbers.
What is needed is the ACTUAL size of the current spreadsheet. If there
are only 2 rows by 2 columns, than THIS is needed. If the user adds more
rows/columns, than the spreadsheet program shall automatically increment
as necessary (this is a nice feature in Numbers). We don't have any
problems with named ranges and general <row>/<column> references
anymore. WE have now a portable value - and a clearly defined one.
Referencing a value outside this range shall generate an error and NOT
silently accept 0, if it falls within the MAX_GRID_SIZE. This is
currently a design error. I have yet to see such a use that is not an
error, and I have enough auditing experience to say this. If the user
really needs this (which I really doubt), he will notice the error and
explicitly write something on the corresponding row or column (to define
that row or column, e.g. a label). This is much more transparent and
error-proof.
Eike wrote:
see http://lists.oasis-open.org/archives/office/200811/msg00155.html
Now if this file was loaded in an application that supported more
columns without knowing the original maximum grid size, the formula in
A2 would yield 0 because the range wrapped pointing to then empty cells.
What applications actually can or should do about this is beyond the
scope of the file format standard, nevertheless it seems to be a good
idea to include the hint of the original grid size.
This is again wrong logic. The application does NOT want to know the
MAX_GRID_SIZE, BUT the *actual spreadsheet size*!
So IF the TC is clever it will follow Apple's approach, and limit the
spreadsheet size to its actual size, and not limit the application. [By
the way, I consider Numbers much better than all other spreadsheets
combined, and I feel Apple is brewing even more things.]
Sincerely,
Leonard
P.S. Please move the discussion to [EMAIL PROTECTED]
or cc me directly in case of a relevant response. Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
