Re: [office-formula] Semantics

[robert_weir@us.ibm.com]

Interesting debate.

How hard is it to come up with a real-world
example of a formula which would give a different result based on the locale
of the user who opens it?  Not just a different presentation, but
an actual different meaning.  If this can ever happen, it would be
a bad thing, IMHO.  Text which is copied and pasted into columns will
not change under different locales, so if we allow formula to treat that
text differently based on the locale, then it is possible for me to innocently
create a spreadsheet and send it to Germany and have the formulas evaluate
different.  Do we agree that this must be avoided?

Rather than calling this C-locale, can
we just say that our decimal literals follows the lexical representation
of something like XML Schema?  They seem to have it nailed down:  http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#decimal

-Rob

Eike Rathke <erack@sun.com> wrote on 03/06/2006
11:16:22 AM:

> Hi Tomas,
> 
> On Sun, Mar 05, 2006 at 11:54:31 +0100, Tomas Mecir wrote:
> 
> > >  Hmmm. What about DEFINING the text-conversion routines,
to be
> > > locale-independent ? This is about a file format, right
?
> 
> Correct.
> 
> > > The apps
> > > WILL have to store numbers in a locale-neutral way - probably
using
> > > the US locale. So, why not make it so that text constants
can get
> > > auto-converted to numbers using only the english locale
?
> 
> Because you don't want to silently and automatically convert user's
text
> content to numeric content. At least you should not. User said it's
> text, so let it be text. Otherwise you enter hell from the backdoor.
> 
> > >  a1: ="1"
> > >  a2: ="5"
> > >  a3: =a1&"."&a2
> > >  a4: =1*a3
> > >
> > >  How do you make that locale independent? We will have
similar 
> problems with
> > > dates.
> > 
> > I don't. I am proposing to achieve locale independency by pre-defining
> > ONE locale, which would always be used to read documents.
> 
> That is the "C" locale, which is already used for all numeric
content.
> You still don't solve any string-to-number conversion issues with
that.
> 
>   Eike