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 15:52, Andreas J Guelzow
<aguelzow@math.concordia.ab.ca> wrote:
> On Mon, 2008-11-24 at 15:34 -0800, Warren Turkal wrote:
>>
>> I am concerned about interop. That's not the issue here.
>>
>
>> "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."
>
> So I guess we all at least agree that opening a file from an application
> with a differnet grid size may result in different formula results.

I haven't see a real world example yet. I could make up a totally
useless one that I have never seen anywhere, but I want to see a real
world honest-to-goodness example.

BTW, my contrived example is the following:

A1 is "=IW1"

It's gives and error in a spreadsheet program that supports only 256
columns. However, it gives 0 in a conforming app that support at least
257 columns.

What use is that kind of logic in a spreadsheet? Can you produce an
example that turns this contrived example into a concrete and real
world example.


Also, assuming we did add those attributes, what would you do when you
open a document in another app with bigger grid? What if someone edits
a cell in the expanded area? What happens when someone saves it?

> Then how can you say that you are concerned about interoperability but
> do not want it to be discoverable whether the grid size has changed?

You haven't shown why it matters. You've given a few examples that
don't illustrate any need for max row/col.

>> 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.
>
> This is ridiculous. Are you claiming that there will never be two
> applications with different grid sizes? If there could be two then
> clearly the larger one could use a formula that does not return an error
> which the smaller one would have to calculate as an error.

No...I am claiming that you haven't showed one single use case where
it mattered what the max row/col in a doc is.

> There is no need for there to be a real world example available anywhere
> for this to be a serious interoperability issue.

Yes there is. If it isn't a problem in the real world, it's not a problem.

wt


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