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

# office-comment message

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

Subject: Re: [office-comment] Need more detailed definitions for formulas

• From: "David A. Wheeler" <dwheeler@dwheeler.com>
• To: Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>, office-comment@lists.oasis-open.org
• Date: Fri, 29 Oct 2004 00:00:59 -0400

```Michael Brauer - Sun Germany - ham02 - Hamburg wrote:
> application if it is fully understood. If there is only a set of
> standard functions then this is not sufficient to interpret a formula,
> because the non-standard function are still not known.

But it would be enough to handle most spreadsheets and
essentially all documents.  The purpose of a standard is
to enable exchange of information; if you enable exchange
of data in nearly all practical cases, that's a big step forward.

Let's face, it most spreadsheets involve relatively simple
calculations: add, subtract, multiply, divide, sum, average,
min/max, that sort of thing.  By defining a set of common
functions (say around 100), you'll enable interoperability for
probably 98% of the spreadsheets.  98% is a pretty good start.

> Specifying a
> useful set of standard functions itself already seems to be a challange.
> From its complexity, I would consider the definition of an office
> application formula language as complex as specifying a programming
> language together with a base framework.

No.  In fact, the current specification already HAS a
definition for an application formula language.  I'm not
proposing a radical change from what's there.  The problem
is that it's not _quite_ precise enough to be interoperable.
You've gone 90% of the way there, you may as well finish the job.

the precise details.  Just enough to define syntax
for an interchangeable subset.
For example, do you expect "=3+4" or "=3 4 +"?  Both can be done,
but presumably you want "=3+4".  And your current text says
you should use "=[.A1]*3" ... so make that clear.

You then need definitions for the built-in functions,
but those can be cribbed from existing documentation.

> For this reason, it seems to be a better choice, at least for me, to
> keep the full specification of formulas separate but uniquely identify
> what "function language" is used than specifying a function language
> that does not meet the requirements of office applications.

For specification of NEW functions, I'd expect there to be multiple
approaches.

But for simple calculations that USE functions, there's no need for
multiple languages.  One is all you need.  And implementors won't
want to implement more than one.  That ONE language can call the
others, as needed.

> However, the TC will take your concern serious and may come back to this
> topic in a later stage.

Okay, that's a good start.

--- David A. Wheeler

```

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