Re: [office-formula] Key Issues

["Tomas Mecir" <mecirt@gmail.com>]

On 2/25/06, David A. Wheeler <dwheeler@dwheeler.com> wrote:
> * Should we use OpenFormula as a base specification?
Yes, agreed. Why create it again from scratch, when it would
inevitably end up being the same ?

> * Schedule: We need to define syntax, then semantics.  Proposal: Draft syntax defined by start+2 months; final syntax/semantics (inc. function definitions) defined by start+6 months.  Should "start" be March 2?

Isn't syntax already defined in OpenFormula ?

> * Issue: Goals/range.  Rob Weir and David A. Wheeler both want it to support both limited resources (e.g., tiny PDAs) and massive capabilities.  Yet if everything is optional, no one will know what is supported, and users won't have real interoperability.  A solution for this problem is to define "levels" (OpenFormula did this).  Do we agree that we should have multiple levels?

I'd say, try to put only PDA-compatible efatures to level1 (or create
level 0 for them). Levels are good, I like the idea. Possibly could be
expanded using sub-levels, see below.

> ** If we have levels, must define the levels.  Discuss briefly whatwe  want, what are the levels.  Can we try to create rough resolution by March 17 on the levels, if we agree to define levels? (OpenFormula had four levels; we don't need to have 4, or use its breakdown, unless we like it.)

Defining levels first is good. What I didn't like on OpenFormula's
approach was that features got moved between levels on a case-by-case
basis, without any clear reasoning other than "it's a problem for app
X". We should go over all the functions/features and extract a common
set of features for each level, then stick to it. For example, say,
"Level 2 requires all functions to behave in accordance with maths
theory", then functions would specify what it means. Say, x/3*3 has to
yield x at level 2 (maths says so), but not necessarily at level 1
(due to finite accuracy) - things like that. Note that this was just
an example - actual levels for these things may differ.

> * Scope: Define this specification as ONLY an interchange format, and at most RECOMMEND user interface issues?

Definitely recommend certain parts of "user interface", so that
complaint apps don't confuse their users with different syntax for
formulas - even if they convert them to ODF upon saving the document.
If everything is defined correctly, there will be no reason to use
different syntax for operators ... We can still say, operator X can
also be presented to the user in the form Y, but must always be saved
as X - for all cases where it matters.

Note that this is not really user interface - user interface are
dialogs and widget placement and such. This is about formula syntax,
as perceived by the user.

> * Test cases: Should we include test cases in the spec?  [cut]  OpenFormula did this successfully, and the KSpread developers seemed to find the test cases useful.

Definitely yes, and indeed, they were mightily useful.

> * Discuss use of Wiki.  Do we want to try to put stuff in a Wiki and LATER transition text to ODF? Transition to an ODF document NOW?  Transition some text now (e.g., what's in OpenFormula), use Wiki, and transition incrementally?  One issue: The Wiki must be MoinMoin, and it's unclear if OASIS will install the MoinMoin math formula support.  Without formula support, formulas may be harder to create.

I do not understand the difficulty in creating formulas - we write
them to the wiki as plain-text, right ? Not maths notation for the
most part. Or do you speak about the definitions of what the functions
should compute ? Can't we use external references or images, in that
case ?

Anyhow, I'd prefer a wiki to a text document.

> * Syntax.  All ODF-supporting spreadsheets support the basic OpenOffice.org syntax, e.g., [.B4].  Wheeler proposes that we use the OpenOffice.org syntax as a starting point; OpenFormula did this.  However, we may need to add to the syntax as necessary (e.g., to support the cell union infix operator, empty parameters, or inline arrays).

Best would be to use what ODF uses - I think that's the same as
OpenOffice's syntax, right ?

> * Semantics.  How strongly should we constrain semantics, and how should we determine them?

Constraints should be high - that's what this is about. If things are
too loose, there's no interoperability, because results differ.
Lowering constraints as low levels is fine, but the highest level
should be as strict as reasonably possible.

There should also be formal definitions of what the functions compute,
and a reference algorithm should be provided, if possible.

> * Complex Numbers.  We don't have time to go into it at the beginning of this process, but although many implementations support complex numbers, their support is really HORRIBLE to users.  Later on we'll need to determine what we should do about them.

Agreed. We may also want to delve into support of precision higher
than long double. As in, GnuMP and similar tools.

/ Tomas