[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-formula] Re: Our next adventure: Types and conversions
Hi Tom, On Mon, May 22, 2006 at 09:25:27 -0700, Tom Metcalf wrote: > A2. An alternative would be to save the > locale of a spreadsheet on creation, and ALWAYS use that > B. Text converted to 0. > C. Text converted to 0 if via reference, and auto-converted > to number if in-line. > D. Text converted to error. > E. Allow some set of the above. > > > A2 might be OK if the locale is not allowed to vary and the formula > representation in the file would always use some particular locale > (C, I suppose). After reading the file, the application would > convert to the user's locale, but the formula is always stored in the > same way everywhere. That would require a conversion on both output > and input, though. Convert what? The text? Not always possible, consider the "number text" being made up of a concatenation of formula results. Yes, that's real life. > My primary concern is that my spreadsheets be readable anwhere. It > is very important that valid implementations get the same answer. > D would not work if a spreadsheet works for me, but fails with an > error for someone else. Is that possible? Not if all ODF applications implemented the D behavior. Much worse the current state: it works for you, and it works for someone else, just different. > E might work, but would that require care on the part of the author > to use the VALUEL function to guarantee that a spreadsheet is > portable? Or could that be automated? Not really. You'd have to guess, and you'd most certainly guess wrong in some cases. > I don't like B or C, though in the end we might be stuck with > supporting something like that, give that some applications already > do this. If, according to D, these usages result in an error, the user will notice. You'd "only" get that in documents originating from applications that don't implement ODFF, so we may implement some compatibility layer and not throw an error in such documents. We may also think about allowing an "alien" semantic for saving such documents in ODFF. However, we should first come to a conclusion how we can do things cleanly, and then find a solution for compatibility modes. Otherwise we end up with a bunch of foul compromises. Eike -- Automatic string conversions considered dangerous. They are the GOTO statements of spreadsheets. --Robert Weir on the OpenDocument formula subcommitee's list.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]