On Mon, 2007-29-01 at 17:54 +0100, Eike Rathke wrote:
> Hi Andreas,
>
> On Friday, 2007-01-26 13:50:34 -0700, Andreas J. Guelzow wrote:
>
> > > 1. Documents exported to Excel using the new semantics don't work there
> > > and at its best generate an error. Ok, nothing strange, maybe users
> > > can live with it.
> > >
> > > 2. Much worse, if Excel defined the same number with a different meaning
> > > ex/imported documents silently work different. Most certainly nothing
> > > users would like to live with.
> > >
> > > We can prevent both by not defining new basis numbers.
> >
> > Well, no, this does not prevent conflict. Applications will (and in
> > other areas already have) define behaviours and functions that go beyond
> > what one can do in Excel. So there is a potential for conflict. Avoiding
> > any specification for items not defined by Excel just means that we add
> > conflicts between other applications.
> >
> > Since Excel does not support ODF we can in fact address the Excel
> > compatibility when we open Excel files
>
> That's easier said than done. While it works for single value arguments,
> you can't remap an argument's value in an import filter if the argument
> is calculated.
Why? I can't just remap one constant to another but I could clearly
construct a function wrapper on import.
>
> > so that is not a good reason to
> > invite compatibility issues between applications such as Gnumeric.
> > OpenOffice.org and KSpread!
>
> Did any of these applications add a new basis number definition for
> YEARFRAC so far? Is there a need for it?
Excel hasn't added anything lately either. I believe it much more likely
that Gnumeric will add new basis numbers than Excel.
I hope we have _not_ adopted the idea of building a standard that is
fully compatible with Excel.
Andreas
--
Andreas J. Guelzow, Professor
Dept. of Mathematical & Computing Sciences
Concordia University College of Alberta
