Re: [office-formula] Key Issues

[Tom Metcalf <tom.metcalf@opendocument.us>]

David A. Wheeler <dwheeler@dwheeler.com> wrote:
 
> * Should we use OpenFormula as a base specification? 
 
 Yes, I believe this is a good place to start.
 
> * 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?
 
 Seems reasonable.
 
> * 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?
 
 I think it is important that a subset of the spec be implementable.  I'm not sure yet 
 whether "multiple levels" or "base level + packages" will be the better way to go.  Most
 of the spreadsheets I see (for example coing out of the accounting department) look 
 visually complex, but in fact only use +,-,*,/, and SUM.  Whether it is called level1 or 
 whether it is called the base level, I would guess that 90% of spreadsheets will not go
 beyond this.  It would be nice, however, if a spreadheet could delcare what level or what
 packages are require to read it.
 
 > * Scope: Define this specification as ONLY an interchange format, and at most 
 > RECOMMEND user interface issues?  
 
 I agree.  The spec only defines what is in the file.  The implementations use this
 information to read the file and having a spec ensures that each implementation can 
 interpret the information in the same way.  How that information is presented to the 
 user should not be part of the spec.
 
> * Test cases: Should we include test cases in the spec? 
 
 Yes, normative test cases are extremely important in my opinion.
 
> * Discuss use of Wiki.  
 
 The wiki worked very well for OpenForumula.  As the text becomes near final, it is probalby 
 best not to allow to allow changes without discussion though.  
 
> * Syntax.  All ODF-supporting spreadsheets support the basic OpenOffice.org syntax, e.g., 
 > [.B4].  Wheeler proposes that we use the OpenOffice.org 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).
 
 Starting with OpenFormula gets my vote.
 
> * 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'm not sure how to deal with this, but I do not think it should be avoided.
 
 
> * 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.
 
 Complex numbers are important to me personally, but not to most users.  I hope we can 
 spec something much more reasonable than what is currently implemented.  If a more reasonable 
 system is implemented, complex numbers will be much more useful.  If it is not implemented, 
 the situation is no worse since the current state of affairs is not useful.  This actually gets 
 a bit into the user interface which I argued above is not what the spec is about.  But the
 lack of good complex number support is kind of frustrating.
 
 Regards,
 
 Tom