[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]