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

[robert_weir@us.ibm.com]

"David A. Wheeler" <dwheeler@dwheeler.com>
wrote on 03/01/2006 10:08:20 AM:

> I think a great value of standardization is revealing
everyone's 
> requirements, and then working to try to achieve them (presuming "not
> excessively complex" is a requirement too).  So far, the
union of 
> requirements looks like this:

> * Don't require EVERY ODF app to support formulas

+1

> * Don't require EVERY formula-supporting app
to support a massive number 
> of functions; some may only want to support + - * / SUM and a 
> specialized set

+1

> * Have a large set of defined functions, so that if two apps DO support
> the same function, it means the "same" thing

+1

> * Have a shorthand way of describing sets of functions (and maybe
> semantics) so that you can describe what a particular application
supports

I'm not sure if we're all thinking the same thing
here.  For example, simply having a section header in the specification
called "database functions" is sufficient to accomplish this,
and becomes a shorthand notation for implementations to state their compliance
level as a checklist item;  "SuperDuper Spreadsheet 1.0 supports
ODF database, financial and advanced math functions".

Or we could have markup-level declaration features
to define which libraries a particular document requires, akin to #include
or import statements, or even with unique namespaces for different function
packages.  But I'm not sure much is added.  Doesn't it work today
to have a simple regex over all formula attribute values to determine the
set of all functions which are referenced?  Of course, all we need
then is for someone to add an Eval(string) functions which allows a user
to pass in a formula as a string, perhaps retrieved from a web service,
or as user input, and all bets are off.  At that point, you cannot
have a static determination of what functions a spreadsheet uses.

> * Have some predefined sets of functions so that users can easily
say "I 
> need set X".
> 

The above certainly enables this.  I'm just not
a big fan of us elevating a certain subset with the loaded term "level
1" or "level 2".  To me this is too desktop-centric.
 I'm wearing two hats here.  As a spreadsheet vendor I'm happy
to have a core set of functions and capabilities chosen for desktop interchange,
but I would expect this to involve a larger ODF modularization and profile
activity and be issued separately from the ODF specification. 

Think of XHTML and their modularization effort.  A
good summary of their goals is here:  

http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/introduction.html#s_intro_whatismod

I think this is exactly what we want, you can replace
"XHTML" with "ODF" in this statement and I would find
it 100% correct and essential for us:

"Modularizing XHTML provides a means for product
designers to specify which elements are supported by a device using standard
building blocks and standard methods for specifying which building blocks
are used. These modules serve as "points of conformance" for
the content community. The content community can now target the installed
base that supports a certain collection of modules, rather than worry about
the installed base that supports this or that permutation of XHTML elements.
The use of standards is critical for modularized XHTML to be successful
on a large scale. It is not economically feasible for content developers
to tailor content to each and every permutation of XHTML elements. By specifying
a standard, either software processes can autonomously tailor content to
a device, or the device can automatically load the software required to
process a module."

But I emphasize that this is a larger effort, involving
far more than formula.  We should do this work, but do it right, and
do it in a unified, coordinate way across ODF capabilities, not just formulas.
 This might be something we can help with from the newly-formed ODF
Adoption TC.


-Rob