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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

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


Subject: Re: Data Grid Size element proposal


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 office-comment@lists.oasis-open.org 
or cc me directly in case of a relevant response. Thank you.


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