Formula kickoff teleconference, March 2 (Thursday), 1700-1800UTC(1200-1300EST)

["David A. Wheeler" <dwheeler@dwheeler.com>]

The "kickoff" teleconference of the office formula subcommittee
will be on March 2 (Thursday), 1700-1800UTC (1200-1300EST).
Here's the dial-in information:

US: 866-205-5235
International:  +1 801-828-9904
 (I _believe_ caller pays for the overseas fees in this case)

Then enter the access code: 6619905

Topics of discussion (per the "Key issues" email on the formula list):
* Working electronically.  So far, no one has protested working electronically.  Unless someone objects, this will also be the LAST teleconference (unless there's a specific request for one).  Please raise a protest March 2, if you want teleconferences, or we'll work electronically from here on.
* Should we use OpenFormula as a base specification? Wheeler proposes yes; it's easier to start with a document and make changes than to start with a blank page. We don't need to decide this at the kickoff, but we need to decide soon, say by March 10. Between now and then, please read the OpenFormula draft. The question isn't whether or not you believe every word (it WILL change), but whether or not starting with it is better than starting with a blank page.
* 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?
* 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 (there's considerable debate on this point)?
** If we have levels, must define the levels. Discuss briefly what we 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.)
* Scope: Define this specification as ONLY an interchange format, and at most RECOMMEND user interface issues? Wheeler recommends defining the spec as ONLY an interchange format. Spreadsheets vary widely in user interfaces: parameter separator (comma vs. semicolon), function names (displayed name often varies by locale), number syntax (what locale?), equal-to operator (= or ==), intersection operator (" " or "!"), and so on. The key is data interchange, not presentation, so Wheeler thinks we should work on defining how it's EXCHANGED as the scope.
* Test cases: Should we include test cases in the spec? Wheeler STRONGLY recommends it. Including test cases eliminates many problems of ambiguity in the text; Wheeler believes it is VERY difficult to write unambiguous text, but that well-written text accompanied by some clear test cases can together create an unambiguous specification that is easier to create and to read. In addition, including test cases makes it much easier to test and assure compliance in implementations. OpenFormula did this successfully, and the KSpread developers seemed to find the test cases 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.
* Syntax. All ODF-supporting spreadsheets support the basic OpenOffice.org storage syntax, e.g., [.B4]. Wheeler proposes that we use the OpenOffice.org storage 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).
* Semantics. How strongly should we constrain semantics, and how should we determine them? For example, different applications use different rules for automatic conversion from text to number (e.g., "3"+2). Some want very specific semantics defined; others want it looser. OpenFormula split the difference by allowing much variance at levels 1 and 2, but having stricter semantics at 3. We could avoid it (leave some semantics undefined or loosely defined), use levels, create a separate category ("strict" vs. "loose" semantics), or something else.
* 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.

We probably won't get through this entire agenda, but if we get through a good start, that's great.

--- David A. Wheeler