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


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

[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

>  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

>  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.


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]