Re: [office-formula] Key Issues

[Richard Kernick <yingtong@bluebottle.com>]

(resending...)

David A. Wheeler wrote:

* Should we use OpenFormula as a base specification? 

Yes

* 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?
  

Would like to understand how much work people are able to put in. This will take some effort, and if everyone has only a few hours spare per week, 6 months might be too short.

* Issue: Goals/range.  Rob Weir and David A. Wheeler both want it to support both limited resources (e.g., tiny PDAs) and massive capabilities.  

I like the levels approach and agree with the need to support all types of implementation, including on-line. I think there will be some things that need to consigned to the sidelines in order to clear away the mess of the past, making way for a good implementation. Two examples: the IM* set of complex number functions and the way dates are handled may call for an LEGACY_DATE set of functions to include things like the 1900 leap year bug, making way for a proper DATE function that handles years from the beginning of time, and perhaps offers support for locales etc.

* Scope: Define this specification as ONLY an interchange format

Agreed - although sometimes hard to separate.

* Test cases: Should we include test cases in the spec? Wheeler STRONGLY recommends it.  

Test cases are like pictures - worth a thousand words.

* Discuss use of Wiki.  

The Wiki works well. Does MoinMoin support RSS? I would like to see the wiki as a place where discussion occurs, rather than the separation we have had between the wiki and the mailing list. You have to keep in mind everything you have read in the mailing list when reading the wiki, much better to have the pertinent points from the discussion in the wiki.

it's unclear if OASIS will install the MoinMoin math formula support. Without formula support, formulas may be harder to create.
  

Suggestion: could you create formulae as a graphic in order to work around these limitations. Obviously not easy for others to edit...

* Syntax.  

Not my strong point, will probably defer to those more competent.

* 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.
  

I became comfortable with the level structure in OpenFormula. I think that, in the end, it addressed both aspects of function sets and semantic strictness sufficiently. I do not agree that semantics should be strictly defined at Level 1, because doing so could alienate many implementations resulting in the specification becoming a side show. Rather implementation of the strict semantic rules, contained within the specification, should become an aspirational goal of every spreadsheet application. The test cases will show clearly the capabilities of an implementation, and yes, some will claim the badge simply because they attain the lowest possible level and will fool some people. However, I believe demand for interoperability is growing, and I think the approach adopted by OpenFormula will work.

* Complex Numbers. 

There are some things that we need to dump. However, that does not prevent us from specifying these function sets - in deed, I think we should define them - but they should not be required. As with the semantic strictness, full implementation will be the aspiration of all until such time as everyone begins to adopt proper complex numbers in their spreadsheets, at which point such functions sets are more easily dropped than if they were a mandatory part of the specification. I would hesitate to do this too often, but this is one occasion where I think it is the right move.


-- Richard Kernick.