Comments from Dan Bricklin

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

I had a long phone conversation with Dan Bricklin earlier today. Here's my attempt to capture what he said. (He gave me permission to publish a summary; any mistakes I've made in trying to summarize his thoughts are mine.)

Fundamentally, Dan believes that the formula work, like OpenDocument in general, should be a foundation for building into the future, and NOT simply a definition of what CURRENT systems do. Thus, it's important to think about the "philosophy of formulas", that is, don't just think about what documents do TODAY, but ALSO what you want them to be able to do into the future.

Dan believes that future spreadsheet implementations will become increasingly specialized, emphasizing different sets of functionality.  If that's so, requiring a single very large set of functions (like OpenFormula's "level 1") for ANY implementation is too much.  In his view, the only truly common general capabilities expected of ANY spreadsheet are +, -, *, /, parentheses, and the function SUM.

Dan particularly holds up his wikiCalc implementation as an example.  It has few functions (one of them being SUM).  Instead, his implementation emphasizes new datatypes and functions of special value to applications that are designed to work with the web.  For example, his implementation has HTML as a distinct datatype from text; it's displayed as HTML. He has a function (I think it's HTTP()) that is given a URI; it downloads the contents of the URI and that result AT THE TIME is used as the result.  The function also accepts a period (how often to re-request). This way, he can trivially create stock quote graphs; just embed the HTTP get as a function, and display as a chart... now you get real-time stock quotes, with a simple spreadsheet function.   Although it's called HTTP, this is obviously extendable to any URI or other WWW protocol.  (Perhaps a better function name would be GETURI(...), where given a URI/IRI, periodicity, etc., it gets the data and returns it.)

Instead, he believes we should think about what applications MIGHT support as data types.  He noted that images might be a supported datatype, which would automatically be displayed as an image if it's a formula result.  A datatype for XML and HTML might be appropriate, so that you could use DOM (or SAX) functions on them, and so that they'd be displayed correctly.  Types for embedded OpenDocument contents would make some sense.  Support for arbitrary MIME types could make sense too (though clearly some operations only apply to some types!).  By identifying the set of data types that spreadsheets of the future MIGHT support, we can help make sure that we don't "box ourselves into a corner" and prevent future ideas from blossoming.  We don't need to figure out all the details for different data types, just make sure they're in our thinking.

He doesn't believe that all spreadsheet implementations SHOULD support the 109 functions noted earlier.  He doesn't plan to implement in-spreadsheet database functions like DSUM, for example; he certainly does NOT plan to implement complex numbers.  He's concerned that if the "low bar" is set too high, implementations may avoid using the formula specification that could otherwise use it very effectively.

On the other hand, Dan DEFINITELY sees great value in defining a set of functions, so that if an application DOES implement a function, there's agreement on its semantics.

====================================

We could certainly go this way.  The idea of identifying some plausible future
data types (so that we don't accidentally forbid them later) is straightforward enough.

We could have a "really low bar" (+ - * / SUM () as the minimum).  But how can we help users know if their spreadsheets will interchange between applications, without having to check with EVERY implementation, EVERY time?  No user wants to go into the applications testing budienss. There is an alternative in the standards world: Profiles.  These are the same, as far as I can tell, to the "packages" discussed earlier.

We COULD just define a large collection of operators and functions.  We could then predefine a set of "packages" that identify a set of REQUIRED functions or groups of functions (directly or via other packages).  That way, you can say "My spreadsheet file requires the financial and complex number packages", or whatever, and then you can see if YOUR implementation has those packages.  If it does, you're set.

--- David A. Wheeler