OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Need more detailed definitions for formulas


Formulas need to be defined much better than they currently are.
The current text isn't sufficient to meet the goal of an
interchangeable data format for spreadsheets.
It shouldn't be hard to fix this by expanding the definition.

Section 8.1.3 purports to define formulas, but other
than saying that they often begin with "=", and an
example using SUM(), it doesn't say much.

Section 15.1 is even worse; it implies that formulas
are strings with no common syntax.  If that's true,
then spreadspreads can't be interchanged using this
format.  Which is both absurd and unnecessary, especially
considering that so many other parts of the specification
hinge on formulas.

This definition needs to be tightened up considerably.
Spreadsheet interoperability hinges on getting a common
definition of formulas.  For example, a common set of
functions that are defined (and thus can be exchanged
with confidence).

It will be long enough to need its own subsection
(or maybe its own section!!).
Here's a start:

For purposes of this specification,
a formula represents a calculation
that produces a single numeric answer.
Formulas are widely used, for example, in spreadsheets.
The format used to represent formulas is intentionally similar
to those used by traditional programming languages and
various spreadsheet programs, using "*" for multiply and
"/" for divide.

While formulas can be displayed, they are not designed to
represent arbitrary mathematical constructs; for that,
use Mathematical Content instead.

A formula MUST either be a number or start with an "=" sign;
the text following the equal sign will here be called an "expression".
An expression must have following form:

  expression :== [optional-negation]
                 ( Number | String | FunctionCall | CellReference )
                 [ operation expression ]

  FunctionCall :== FunctionName "(" [ function-argument
                                      [ "," function-argument ]* ] ")"

An operation can be "+" (add), "-" (subtract), "*" (multiply), "/" (divide),
"^" (exponentiate), or the comparatives "=", "!=", "<>", <", "<=", ">", ">=".
The usual mathematical precedence rules apply: unary minus,
exponentiation, multiplying and dividing, adding and subtracting,
and then finally comparitives;
within these groupings, the order is left-to-right.
Parentheses may be used, as long as they are properly nested, and they
override the precedence rules given here.

A String is surrounded by double-quotes (") or single-quotes (').

Note that cell references and function calls
are unambiguous because function calls end in "(" after the name,
while cell references do not.  However, while cell references
SHOULD be written so that they begin with a table name, or
an initial "." if it's the current table, readers SHOULD
handle formulas where the cell name of the current table omits
the leading dot (e.g., "=A1+B1", which should be "=.A1+.B1").

Most systems supporting formulas will support a large number
of built-in functions.  The following are functions that are
generally supported (and thus should be interoperable); implementations SHOULD
implement at least these functions:

{SUM, etc.  Pick a nice big list, so that interoperability
is enhanced.  Create the list based on
OpenOffice and/or Gnumeric or whoever.  The list is going
to be large, and will need many subsections itself,
so this will probably need its own subsection
or section.  But it should be easy to create; a vast number
of functions are accepted by all, many starting from the
original VisiCalc.  And although there are many functions,
most are very easy to define. }


--- David A. Wheeler



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]