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
