On Thu, Dec 15, 2005 at 12:03:36PM +0100, Niklas Nebel wrote:
> Hello everybody,
>
> There has been some disagreement on how to handle changes that would
> improve formula compatibility with other applications, but break
> documents created with existing versions of OOo. Compatibility with
> others and with older versions are two requirements that both have to be
> taken into account. Actually, there even is a third requirement, which
> is that a solution shouldn't interfere with the plan to specify an
> OpenDocument formula language.
>
> So we're now looking for possible solutions that satisfy these three
> requirements. As we're collecting ideas, these don't have to resolve all
> the existing calculation differences at once, any solution for a single
> class of problems would help.
>
> Suggestions are welcome on this list.
You've identified
1) Compatibility with other spreadsheets
2) Compatibility with older versions of OOo/SO
3) Avoiding conflicts with future OpenFormula spec
There are several things we can do, but they will require us to nail
down more detail on (2). Loading an old file (sxc or ods) should
generate the same result in newer version of OOo as much as
possible. What is less clear is what to do when loading a file
generated with the compatibility extensions into older versions.
For the types of changes being discussed there is no way we can
guarantee consistency without creating yet another file format
option which would quickly get unwieldy. Once this restriction has
been accepted there are several areas to look at.
1) Missing arguments
=ADDRESS(1,2,,1)
I've got some work on this that I'd like to discuss at some
point. This is a safe addition. No existing spreadsheet could
be impacted (ignoring bugs in the transition).
2) Support for XL addressing modes
eg R1C1 and sheet1:sheet2!A1:B2
Again there is a CWS with work towards this that has had some
review. Adding this starts to get interesting. In that some of
the worksheet functions are directly impacted. For the time
being I have created ADDRESS_XL and INDIRECT_XL to use the new
parsers, and left the old versions as the defaults.
Unfortunately that makes us inconsistent with all the MS Excel
books out there for users entering formulas. It seems
preferable to use the new functions as the defaults, and have
the sxc/old-ods importers do the mapping.
3) Use less obscure error codes.
It's pretty clear that Err.503 provides less information than #DIV/0
or even than #NUM!. Doing this would create an incompatibility,
operators and functions would return different errors in the new
version. That does not seem particularly onerous. We could do
some mapping in ERRORTYPE which was one of the few safe
mechanisms for examining error results to help minimise the
incompatibilities if necessary.
4) Create a real boolean type.
Faking things with some formating tricks and the use of TRUE()
and FALSE() is not sufficient. Without an internal bool we can
not do compatible implicit type conversions. It's hard to
gauge how much incompatibility this change will generate.
Adding the type itself is a small change relative auditing all
of the iterators to see when to do implicit conversion and when
not. Unfortunately this binary choice (no pun intended). OOo
can only be compatible with one set of arbitrary conventions.
Either we match > 99.9% of existing spreadsheets or we do not.
The prospect of inserting a 'calc mode' flag and supporting
multiple conventions in every function that uses an iterator is
not maintainable.
5) Implicit conversions of strings to values
=1+"2005/Dec/20" => ??
While this is controversial for other reasons (it makes
calculation locale dependent) it is actually a fairly safe
change. Old files would have generated errors in the cases that
need to be considered. It seems unlikely that anything was
depending on that behaviour. The lack of this feature has
significantly more dire consequences as values that were
generated in other spreadsheet no long calculate.
That seems a reasonable set to start with at the global level.
All of the operators and functions also need to be audited. Novell
and Gnumeric have the start of some test workbooks that can be
merged with the basic work done for the google summer of code
project. However, that is a different magnitude of change and
should be dealt with separately.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
