openformula-20060714.odt Details

Document Details     TC Member Document View
Title OpenFormula Specification 2006-07-14 (ODT)
Name * OpenFormula Specification 2006-07-14 (ODT) (219K)
Description OpenFormula is an open format for exchanging recalculated formulas between office application implementations, particularly for spreadsheets. OpenFormula defines the types, syntax, and semantics for calculated formulas, including many predefined functions and operations, so that formulas can be exchanged between applications and produce substantively equal outputs when recalculated with equal inputs. Both closed and open source software can implement OpenFormula.

OpenFormula is intended to be a supporting document to the Open Document Format for Office Applications (OpenDocument) format, particularly for defining its attributes table:formula and text:formula. It can be used in other circumstances where a simple, easy-to-read infix notation is desired for exchanging recalculated formulas.
Group OpenDocument - Formula SC
Folder Standards
Submitter Mr. David Wheeler
Date Submitted Friday, 14 July 2006 07:03pm
Document State Draft (A preliminary unapproved sketch, outline, or version.)
Access This document is visible to OpenDocument - Formula SC and shared with:
  • OASIS Open (General Membership)
  • General Public
  • OASIS Open Document Format for Office Applications (OpenDocument) TC

Document Revisions
Name # State Submitter Date Action
98
Draft
Michael Brauer
2010-07-26
97
Draft
Michael Brauer
2010-05-31
96
Draft
Michael Brauer
2010-05-27
95
Draft
Michael Brauer
2010-05-12
94
Draft
Mr. Eike Rathke
2010-05-11
93
Draft
Mr. Eike Rathke
2010-05-11
92
Draft
Mr. Eike Rathke
2010-05-06
91
Draft
Patrick Durusau
2010-05-06
90
Draft
Patrick Durusau
2010-05-03
89
Draft
Mr. Eike Rathke
2010-04-29
88
Draft
Mr. Eike Rathke
2010-04-29
87
Draft
Mr. Michael Brauer
2010-04-15
86
Draft
Mr. Eike Rathke
2010-04-15
85
Draft
Patrick Durusau
2010-04-11
84
Draft
Mr. Eike Rathke
2010-03-18
83
Draft
Patrick Durusau
2010-03-15
82
Draft
Patrick Durusau
2010-02-18
81
Draft
Mr. Eike Rathke
2010-02-16
80
Draft
Mr. Eike Rathke
2010-02-12
79
Draft
Patrick Durusau
2010-02-08
78
Draft
Mr. Eike Rathke
2010-02-03
77
Draft
Mr. Eike Rathke
2010-01-20
76
Draft
Mr. Eike Rathke
2009-12-22
75
Draft
Mr. Eike Rathke
2009-12-04
74
Draft
Mr. Eike Rathke
2009-10-26
73
Draft
David Wheeler
2009-05-08
72
Draft
Mr. Eike Rathke
2009-05-01
71
Draft
Mr. Eike Rathke
2008-12-21
70
Draft
Mr. Eike Rathke
2008-10-10
69
Draft
Mr. Eike Rathke
2008-06-18
68
Draft
David Wheeler
2008-06-14
67
Draft
David Wheeler
2008-06-13
66
Draft
David Wheeler
2008-06-04
65
Draft
David Wheeler
2008-06-03
64
Draft
David Wheeler
2008-06-02
63
Draft
David Wheeler
2008-05-16
62
Draft
David Wheeler
2008-05-15
61
Draft
Mr. Eike Rathke
2008-05-09
60
Draft
Mr. Eike Rathke
2007-12-28
59
Draft
David Wheeler
2007-11-25
58
Draft
Mr. Eike Rathke
2007-07-20
57
Draft
Mr. David Wheeler
2007-06-20
56
Draft
Mr. David Wheeler
2007-06-19
55
Draft
Mr. Eike Rathke
2007-06-19
54
Draft
Mr. David Wheeler
2007-06-18
53
Draft
Mr. David Wheeler
2007-06-07
52
Draft
Mr. Eike Rathke
2007-04-13
51
Draft
Mr. Eike Rathke
2007-04-13
50
Draft
Mr. Eike Rathke
2007-03-29
49
Draft
Mr. David Wheeler
2007-03-23
48
Draft
Mr. David Wheeler
2007-03-22
47
Draft
Mr. David Wheeler
2007-03-17
46
Draft
Mr. David Wheeler
2007-03-09
45
Draft
Mr. David Wheeler
2007-03-02
44
Draft
Mr. David Wheeler
2007-02-22
43
Draft
Mr. David Wheeler
2007-02-14
42
Draft
Mr. David Wheeler
2007-02-13
41
Draft
Mr. David Wheeler
2007-02-09
40
Draft
Mr. David Wheeler
2007-02-08
39
Draft
Mr. David Wheeler
2007-02-01
38
Draft
Mr. David Wheeler
2007-02-01
37
Draft
Mr. David Wheeler
2007-01-25
36
Draft
Mr. David Wheeler
2007-01-21
35
Draft
Mr. David Wheeler
2007-01-17
34
Draft
Mr. David Wheeler
2006-12-22
33
Draft
Mr. David Wheeler
2006-12-20
32
Draft
Mr. David Wheeler
2006-12-08
31
Draft
Mr. David Wheeler
2006-11-29
30
Draft
Mr. David Wheeler
2006-11-22
29
Draft
Mr. David Wheeler
2006-11-01
28
Draft
Mr. David Wheeler
2006-10-25
27
Draft
Mr. David Wheeler
2006-10-18
26
Draft
Mr. David Wheeler
2006-10-11
25
Draft
Mr. David Wheeler
2006-09-29
24
Draft
Mr. David Wheeler
2006-09-23
23
Draft
Mr. David Wheeler
2006-09-20
22
Draft
Mr. David Wheeler
2006-09-14
21
Draft
Mr. David Wheeler
2006-09-13
20
Draft
Mr. David Wheeler
2006-09-10
19
Draft
Mr. David Wheeler
2006-09-06
18
Draft
Mr. David Wheeler
2006-08-30
17
Draft
Mr. David Wheeler
2006-08-23
16
Draft
Mr. David Wheeler
2006-08-16
15
Draft
Mr. David Wheeler
2006-08-16
14
Draft
Mr. David Wheeler
2006-08-13
13
Draft
Mr. David Wheeler
2006-08-11
12
Draft
Mr. David Wheeler
2006-08-09
11
Draft
Mr. David Wheeler
2006-08-04
10
Draft
Mr. David Wheeler
2006-08-02
9
Draft
Mr. David Wheeler
2006-07-31
8
Draft
Mr. David Wheeler
2006-07-24
7
Draft
Mr. David Wheeler
2006-07-20
6
Draft
Mr. David Wheeler
2006-07-19
5
Draft
Mr. David Wheeler
2006-07-18
4
Draft
Mr. David Wheeler
2006-07-16
3
Draft
Mr. David Wheeler
2006-07-14
This doc
2
Draft
Mr. David Wheeler
2006-07-13
1
Draft
Mr. David Wheeler
2006-07-11
0
Draft
Mr. David Wheeler
2006-02-21

Comments  
Subject & Text Submitter Date Action
Initial comment by submitter
* Inserted a great deal of text to describe the impact of OpenDocument
calculation settings; it shows up all over. I could use help describing
the regex option - HELP! For the test cases, I decided to state that
case-sensitive=false and search-criteria-must-apply-to-whole-cell=false, so
we'll test at least a few cases with non-defaults (and these are common
alternative settings, so they're worth testing).
* Several functions' semantics were changed so that they do NOT
have multiple levels inside them. Instead, any function simply
has a set of requirements... which you either meet, or you don't.
This restriction does make defining groups MUCH easier.
Congratulate/blame Rob Weir for this :-). There are a very few cases
I haven't completed this (e.g., COUNTIF, SUMIF)... suggestions welcome.
I might even include all shoulds in test cases, because it would make people
take the "shoulds" more seriously.
See my earlier email for the list of functions this affected.
* Modified text to make it clear that logicals MAY be a distinct type, but MAY
be Number instead.
* Modified text to make clear that in "Convert to Number", if given text,
an application may (1) convert it (e.g., using VALUE), (2) convert to 0,
(3) report an Error value.
* Documented string length limit: All applications must support AT LEAST 32767
(2^15-1) ASCII characters for the Text type, more is better. Modified a few tests in
LEFT and RIGHT so that they did not violate this. Excel supports up to 2^15-1,
OOo supports up to 2^16-1. Anyone think we ought to increase the minimum?
* Rewrote/fixed "EXACT". EXACT simply converts both sides to Text (if not already),
and then compares if they are identical (including upper/lower case, regardless
of the case-sensitive setting). The previous text was (a) overcomplicated and
(b) wrong anyway.
* Added the idea of a "Portable Constraint". The problem is that the explanation
of "Constraints" says that a function/operation must produce an error if
a constraint isn't met (unless stated otherwise). Yet in some cases there
are really two constraints: (1) Regions that MUST produce an error, and
(2) Regions that are not portable... applications MAY produce a result, OR
an error. This lets us distinguish those cases. Let's see if this works.
I used it on DATE, TIME, and FACT to start with. Often the problem is that
some functions may/may not apply INT() to their parameters, or may support
a larger domain that's too painful to require for everyone.
* An experiment: I have created two NON-required feature groups,
_DISTINCT_LOGICAL and _AUTO_TEXT_TO_NUMBER. They're primarily
for helping users with data files identify that their data files depend on
these semantics. In particular, depending on _AUTO_TEXT_TO_NUMBER
is highly discouraged. I don't know if this idea has legs, but I thought
it'd be easier to put it down & see if it helps. Indeed, now that I've
done this, I can't help but suspect that these groups might make good
potential calculation settings to transition legacy data files... at least
to add as a marker to warn somebody about them.
We can also use this "feature group" idea to handle the one or two
functions that we really wanted to split into multiple levels, but thanks
to Rob Weir we can't :-).
* Changed to ISO's bolded shall/shall not/should/should not/may notation,
instead of the IETF's capitalized terms. Since we hope to get an ISO
stamp, may as well make that change now.
* The usual removal of editorial mistakes. No doubt these are compensated
by the insertion of new editorial mistakes :-).
Mr. David Wheeler
2006-07-14
---