Re: [OpenFormula-discuss] TODO List (Proposed)

[Jody Goldberg <jody gnome org>]

On Tue, Oct 18, 2005 at 02:39:36PM -0400, David A. Wheeler wrote:
> * Agree on specification license & eventual standardization process.
- Rather than re-inventing this wheel do we want to just adopt the
  process from one of the ISO/JTC/WG groups or possibly as a subset
  to OASIS ?

- We will likely need different licenses for the spec and for the
  validation suite.

>   But the real measure in my mind is:
>   can users can easily exchange data with formulas between
>   many different implementations?

For marketing purposes we should probably make it clear that
'implementation' includes different versions of the same
application.

> * Scope & Basic principles.  We're doing that now; I expect those
>   to end up in chapter 1-2.  One key issue: What's our starting point?
>   Currently, for syntax I plan to use OOo unless strongly contraindicated.
Current OOo syntax has a few limitations we may want to address.
- It does not support full col/row references  eg A:B seems more
  portable between versions than A1:B65535 (in the context of max
  size changes)

- A1 notation is reasonable, but R1C1 would be more amenable to
  sharing and compression.


>   (Excel, OOo, KOffice, Gnumeric, etc.), making sure that we do NOT
>   specify anything that contradicts the widely-used Excel.
amen.

>   Over time we can then work to constrain things further.
>   In the end, I think the _semantics_ should be
>   "as close as possible to Excel"
The Gnumeric development motto is
    'As close to Excel as necessary but no closer'

>   But some spreadsheet implementations have variances, and if
>   they're unwilling to change, perhaps we should define "levels"
>   so that users will know what they can depend on... and what they
>   can't.
If we agree that a validation suite of test workbooks is required we
could use the scores from those (foo conforms 93%)
 
> * Types (Current chapter 4).  What are they?  How much should
>   we say about subtypes (e.g., date)?
At minimum we should agree on a standard set of errors.
Err.511 vs #NA types of thing.  More expansively we'll need to at
least discuss bounds and types.  eg MS Excel's RK structure provides
a window into some of the issues.  Standardizing the bound does not
seem useful, but providing guaranteed minimums would be useful

> * Semantics of built-in operators (+ - * / etc.), logical operators.
    http://www.gnome.org/projects/gnumeric/func-tests/operator.xls
 
> * Function definitions.  We need to define a template, and then
>   fill them in.  It's been proposed to start with date/time (sounds fine!),
>   but we should also work to define a few of the most common ones
>   like SUM and COUNT.

Rather than doing a full set of similar functions I would rather
start by doing the 10 most common functions to get a feeling for the
the diversity we'll need in the spec.

At the same time I'd like to see a spec for how an application
should construct/name non-conforming functions and a discussion of
best practices for handling functions that are known to differ
between implementations.
    eg LOG vs LOG10

> * Other. I think we should note recalculation order as a topic for
>   a later edition, but not START there.

Additional material would include
    - iterative expressions
    - array expressions
    - implicit type conversions
    - ?? natural language refs ??
    ...