re: Please participate in OpenFormula! First issue: Where should the mailing list be?

[Jody Goldberg <jody novell com>]

On Tue, Oct 18, 2005 at 12:29:32PM +0200, Niklas Nebel wrote:
> If, howewer, one application includes the day 1900-02-29 in date 
> calculations, and another one doesn't, how in the world are you going to 
> "import" or "export" their formulas to a common specification?

That would need to be a documented as 'implementation specific'.
There are vast swaths of issues here that are less clear cut.
    - A standard set of functions with detailed specs on arguments
      and the expected results.  Ideally backed by a series of test
      workbooks to validate compliance.
    - A specification of how implementors can add and name extension
      functions.
    - Interpreter semantics for iterative methods, array formulas,
      natural language references ...
    - 3 + "Apple" == ??
 
> From my point of view, to complement the OpenDocument specification in 
> a useful way, what we need is something that's confined to the file 
> format. It would probably include the general formula syntax, a list of 
> function names, but not much more.

That seems like a fairly vacuous result.  What is the utility in
knowing that there is an ADDRESS function without knowing that it
will have the same calling convention and results ?
 
> Of course, if we do such a description for the formulas of OOo Calc 
> instead of creating a new specification, we'll instantly have a working 
> implementation. That would make the sc-dev list the right place.

I'd rather see a more long term goal of providing a specification
to help us improve interoperability.  The vast majority of existing
spreadsheets are from MS Excel and can not be changed.  For any
other product to compete or replace it will require us to calculate
the same results given the same input files.  We either standardize
on semantics and and names that are different than XL and add ever
more complex translations on import and export, or we codify the
already existing behaviors for the majority case and fix our apps.

The former does not seem likely to succeed.

> Do we really need a new mailing list for discussing what mailing
> list to use?
Let's avoid that type of meta argument.