Re: [office-formula] Goals/levels/packaging/complex numbers

[robert_weir@us.ibm.com]

"David A. Wheeler" <dwheeler@dwheeler.com>
wrote on 02/28/2006 12:51:51 PM:


> More importantly, there seems to be general agreement that the
> resulting formula spec MUST support BOTH constrained environments
> (like PDAs).  I think Dan Bricklin wants an even SMALLER base
set.
> Yet if the "base" is tiny, or there's NO defined grouping,
then
> either everyone has to implement EVERYTHING (no PDAs for you!)
> or the base is tiny (no interoperability for you!).
> 

I don't agree with that logic.  Imagine you have
a PDA spreadsheet.  Then you are given a valid ODF document which
matches your subset of functionality.  You can read it and process
it with no problems.  Any document you create on that implementation,
is by default valid ODF and can be read by any ODF-compliant implementation.
 Further if someone sends you a spreadsheet which you cannot handle,
then you need to handle that as an error condition and degrade gracefully,
notify the user, etc.  The task is the same whether you have levels
or not.  It is the same today when exchanging documents between Excel
and 1-2-3.  Any implementation which is less than a full implementation
needs to check if the document it reads uses functions it does not support.
 This applies to formulas, charts, styles, whatever.  This can
not be avoided in a world of multiple implementations.  

I think the meta-requirement is that the functionality
required to understand a document be easily discoverable by reading the
document.  With that capability (which I believe we already have)
then we support the reality that there are an infinite number of levels.
 Everyone who downloads the OO source code and adds or removes a function
can create their own "level".  The person who wants scientific
computing on PDA has a different level than someone who wants financial
functions on their cell phone.  Also, every implementation which allows
custom, user-defined functions via script or binding to external code,
allows a custom level.  

So, the question is do we want to elevate some sets
of functions to official "levels" which we specify and carve
in stone for an enduring standard?  Or do we want to encourage a more
flexible approach, and allow vendors and users to discover "what works"?
 Is the choice we make in levels a good choice for today, tomorrow
and the day after?  Is this subcommittee the best place to determine
what bundles of functionality are best used in a PDA spreadsheet? Or a
Wiki? Or for a vertical application?  

Presumably an implementor knows their users/customers
best and will give them the functions they want, regardless of what levels
we define.  The real purpose of the spec is not to tell implementors
what features they need to write, but to give them a common way to express
the features they do decide to implement.  So, I think of the function
specification as a cookbook.  You are not required to make every dish
in the cookbook in order to be compliant, but if you use these function
names in this namespace, then you must follow the syntax/semantics of that
function definition.

The metadata discussions we've been having on the
main TC list show the range of special-use ODF-editors which are being
imagined.  We really need to think beyond the general-purpose monolithic
desktop editors we have today.  There will be more than just a handful
of implementations that will want to claim ODF compliance.  I'd rather
not have us make problem domain level decisions for users and implementors
about which functions are "basic" and which ones are "advanced"
and define compliance based on those labels.  

-Rob