Functions that need to be identified as TBD

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

Earlier on I created blank headers for functions that weren't defined,
but needed to be.

But there are a few cases where I wasn't sure if new functions needed to
be added, and if so, what their names needed to be.  At this point,
I believe we NEED to add headings for ALL functions.  We can actually
change the names of functions fairly easily, but documenting a function
you don't know you need is harder :-).

The real problem will be on AGREEING what those new names should be.
I'd really like to hear what they should be... but let's first make sure the
draft spec documents WHAT should be (possibly) added, or otherwise
we'll lose the idea entirely.

First, there are the "_ADD" functions of OpenOffice.org; "_ADD" is a weird
marker that OOo adds, saying "these are functions with Excel-compatible
semantics that are DIFFERENT than the semantics of my functions without _ADD".
In OOo, they are as follows:
CONVERT_ADD
CUMIPMT_ADD
CUMPRINC_ADD
DURATION_ADD
EFFECT_ADD
ERRORTYPE
GCD_ADD
ISEVEN_ADD
ISODD_ADD
LCM_ADD
NOMINAL_ADD
WEEKNUM_ADD
For example, in OOo, WEEKNUM_ADD uses Excel's nonstandard week numbering
system, while in OOo's display format, WEEKNUM uses ISO standard week numbering.

Also, as an illustration that things don't stand still, KOffice had earlier implemented
an "EASTERSUNDAY(year)" function. OOo now sports a compatible one.
This function may be a challenge. On the one hand, if you need it you REALLY need
it (it's very difficult to do without if you need it).
On the other hand, it's obviously related to
a religious date (and to a particular group's definition - Roman Catholics and
Protestants would find it useful directly, but Orthodox Christians
would expect a different value).  Many may be more comfortable if we find
a way to incorporate many important dates (of many religions/cultures), yet
we don't want to create a new nonstandard mechanism for doing so.
We may want to punt on this one for now; comments?

Consider adding EUROCONVERT (and compare to OOo's CONVERT).
The Euro is here (surprise!), but it's still useful for long-term financial
instruments. But I just need to know if there's enough reason to
include it in the spec itself.

We've "stolen" Gnumeric's bit operations, but they do not have
BITNOT(x;bits) or BITNEGATION(x;bits) (two's complement) functions.
These functions CAN be implemented using BITXOR, though with a little pain.
Anyone want to pitch for additional functions directly?


Here's what I propose, as a starting point:
* Use "WEEKNUM" for the Excel semantics function, and add a function
   "ISOWEEKNUM" for the ISO semantics.  Both KSpread and Gnumeric already
   use "ISOWEEKNUM" as the name of the ISO-implementing function.
   Implementations can tell the difference, btw - if a formula starts with "oooc:"
   it could map functions differently than if "=" is the beginning value).
* OOo's "ERRORTYPE" produces values that really only make sense to OOo, so
   I propose that it NOT be in the spec - OOo can save it as ORG.OPENOFFICE.ERRORTYPE.
   The function "ERROR.TYPE()" would stay in the standard and be the portable
   way to query (ERROR.TYPE maps the Error into a short list of integers - but
   there's no requirement that the list of Errors ACTUALLY be that list).
* For CONVERT_ADD, CUMIPMT_ADD, CUMPRINC_ADD, DURATION_ADD,
   EFFECT_ADD, NOMINAL_ADD, GCD_ADD, ISEVEN_ADD, ISODD_ADD, LCM_ADD:
   define functions without the "_ADD" with Excel semantics, and have "_OOO"
   functions with the OOo semantics, e.g., "DURATION" vs. "DURATION_OOO".
   The "_OOO" naming convention is lousy; it's more
   of a placeholder so that we can differentiate the functions.  Suggestions?
   Many of these (GCD_ADD, ISEVEN_ADD, ISODD_ADD, LCM_ADD) are trivially
   different - should these be implementation-defined (and NOT separate functions)?
   Should these just be application-specific functions when exchanged?
   We need to compare CONVERT_OOO and EUROCONVERT as well.
* Consider adding EUROCONVERT (and compare to CONVERT_OOO).
   Obviously it's still useful for long-term financial instruments, so I just need to know
   if there's enough reason to include it in the spec itself.
* No "EASTERSUNDAY" in the spec; use ORG.KOFFICE.EASTERSUNDAY() if you have it.
   If there's a follow-on effort (there probably should be), revisit this.
* For all functions added per above, place them in the "Large" group.

--- David A. Wheeler