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

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

robert_weir@us.ibm.com wrote:
> 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
That _almost_ works, and where it's possible we SHOULD do that.  
Everyone groups functions by concept anyway, so it's a very sensible way 
to go.  If we did it that way, we'd probably need finer groupings than 
currently. E.G., instead of "Mathematical Functions" there might be 
"Trigonometric Functions", "Hyperbolic Trigonometric Functions", and so 
on as groupings.

> 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".
Yes.  Though a simpler shorthand for a common set would be helpful too.

> ...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?
It's not clear that's enough.  Some functions allow additional 
parameters, REQUIRE parameters others don't, or allow input domains 
others don't (fractional values, negative numbers, strings, that sort of 
thing).  Some applications allow empty parameters, or 0 parameters, and 
they matter in those cases.  There are several OpenFormula functions 
where requirements got allocated to different levels for these reasons; 
this may suggest it's not enough.  Some functions where this happened 
include: DATE, LOG, TIME, COUNT, COUNTA, VALUE, LOOKUP, HLOOKUP, 
VLOOKUP, AND, OR, IF, SUM, LEFT, REPLACE, RIGHT, SUBSTITUTE.

It's worth considering the pros and cons.


> 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".
Oh, well if it's just the NAME you object to, that's fine, just call it 
something else.

>  To me this is too desktop-centric.
OK.  How about "Desktop-basic" for a name instead of "level 1"?  If 
you're not building a traditional desktop spreadsheet, then there would 
be no reason to implement Desktop-basic.  We could even call a package 
"Desktop-centric" in your honor :-).

The key thing here is that if you're building an application that is 
specialized, you should NOT be required to implement the universe.  But 
if you're a customer who wants a "basic desktop spreadsheet", you should 
be able to QUICKLY state your requirement, and QUICKLY determine if a 
given application meets it.

> 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. 
But they would immediately turn back to us and ask "can you write the 
formula spec so that we CAN profile it", and "what is a good initial 
set?"  We _ARE_ the people for formulas; there's no one to pass the buck 
to :-).  So let's give them the tools they need to profile formulas, 
should that effort ever come to pass, and include enough material so 
people don't HAVE to wait for a group that doesn't currently exist.

> Think of XHTML and their modularization effort.
Yes, that's what I'm thinking of.  But in order to have modules, the 
spec itself has to be written so that you CAN think in terms of 
modules.  If a later group wants to create OTHER profiles, GREAT.  But 
let's give them the tools so that they CAN define such profiles, and in 
case they never show, let's define a few starting profiles so that 
people can have useful profiles NOW.


--- David A. Wheeler