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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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


Subject: Re: [office] Data Grid Size element proposal


On Mon, Nov 24, 2008 at 14:06, Andreas J. Guelzow
<aguelzow@math.concordia.ab.ca> wrote:
>> Couldn't Gnumeric tell if the formula referred to cells outside it's
>> gridsize? It seems like it could just notify the user if a cell is
>> addressed that isn't within it's grid size.
>
> Of course we could tell the user that "hey there are formulas that
> appear to require 319 columns and 1231124 rows" after we have parsed the
> whole file and all of its formulas. I believe it would be desirable to
> tell the user that the sheet was created in a program with 400 columns
> and 2000000 rows so that there might be references or content outside
> the range before we start reading such a big file in its entirety.

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.

>> Wouldn't Gnumeric know if a sheet was loaded that had values outside
>> it's gridsize? It seems that information would already be in an ODS
>> file. For instance, if Gnumeric could only load 256 columns and a
>> value for the cell "$IW$1" is defined in the file, wouldn't it be
>> possible for Gnumeric know that it couldn't address that cell?
>> Wouldn't it be good to notify the user the the file being loaded had
>> data that cannot be addressed or saved in that case?
>>
>> > http://groups.google.com/group/How-to-Documents/browse_thread/thread/1f3ab6e086392bd4 seems to do some similar.
>>
>> This isn't depending on the error at all. It seems to be depending on
>> functionality of Google Spreadsheets allowing addressing of cells out
>> of its range. For instance, I can have up to 256 that I can address
>> and update. If I do put "=IW19*3" (column 257, row 19) in a cell
>> though, I get 0 instead of some error. I don't think this situation
>> makes a case for the explicit maximum size.
>
> If you try to put "=IW19*3" into a cell in Gnumeric you get an error
> rather than 0. This is a problem if you are at all concerned about
> interoperability.

I am concerned about interop. That's not the issue here.

I was also saying that the formula that you showed as an example
didn't depend on the behavior you were saying the explicit definition
of a max sheet size would address. The Google Spreadsheet has
different behavior.

For instance, the ODF formula 1.2 draft10 spec says the following on page 68:

"A reference with an explicit row or column value beyond the
capabilities of the application shall be computed as an Error, and not
as a reference.  Authors of portable documents may use whole-row and
whole-column references, such as [.1:.1] or [.A:.A], to facilitate
updating a document to large sizes."

When I can reference a cell outside of the app's supported range, like
IW1 in Google Spreadsheets, and I get value and not an error, that's
not compliant with the ODF formula spec reference above. I was
pointing out that using this as an example is invalid because it
doesn't say anything about the topic at hand.

In a conforming application, declaring the max size of the sheet is
pretty useless unless there is some use for relying on an error
generated by referencing a cell outside of the application's supported
range that I just don't see. I am open to the possibility that such an
example exists. However, at this point, I haven't seen one.

Cheers,
wt


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