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

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

* 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.

  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
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.
* 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 ??

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]