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 ??
...
_______________________________________________
gnumeric-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gnumeric-list
