Re: [office-formula] Implementation-defined, Unspecified, and Undefinedbehaviors in OpenFormula

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

robert_weir@us.ibm.com wrote:
> I've been going through the current draft of OpenFormula, looking for 
> areas that are specifically called out as "implementation-defined", 
> "unspecified" or "undefined".  I did not find as many as I thought I would 
> find.
> I created a spreadsheet that illustrated each one of these cases, which I 
> am attaching.

I took your spreadsheet and added a new column, "Why Undefined in 
OpenFormula?".  I then filled this column in, in an attempt to document 
in more detail the rationale for WHY those items are undefined.

So, attached, is my attempt to answer those issues.  Of course, we don't 
have to agree with my attempt to answer these items. For example, maybe 
we've learned more since.  And in two cases (VARP and TEXT), I think we 
should change the spec as described below.  So this analysis by Weir was 
worthwhile for at LEAST that reason.

As you can tell by the attached spreadsheet, it turns out that there are 
actually very FEW causes for something to be undefined in OpenFormula. 
A few items that were SPECIFICALLY agreed to be undefined end up causing 
"undefined" in several places in the spec.  So, I named those reasons, 
which end up getting reused all over. See the attached spreadsheet for 
details; they are:
* DISTINCT_LOGICAL_TYPE
* AUTO_CONVERT_TEXT_TO_NUMBER
* ZERO_PARAMETERS_IN_LIST
* OLD_BASE_CONVERTERS.  Basically, we want people to avoid these older 
functions in the future... we specify just enough so that they can 
continue to be used in older sheets.
* PERMIT_EXTENSIONS.  A desire to permit extensions in certain very 
limited areas, without requiring universal support.

These 5 issues explain the 85% ((61-9)/61) of the implementation-defined 
areas, plus 9 more that are very specific, which means we have 
REMARKABLY few implementation-defined areas.  That's great!  "Few but 
non-zero" is, to me, a sign of a GOOD specification.  "Non-zero" 
suggests that we've been practical; "few" suggests that interoperability 
with this specification is really good.

I added two more items not on Weir's list, at the end. (Not counted in 
the discussion above.)

This analysis brings out two points:
* What should VARP() do when passed one value?  Both Excel and 
OpenOfficce.org return 0.  I think that makes sense - if given only one 
value, its variance is zero.  I think we should SPECIFY this, removing 
one of our implementation-defined items.  Comments?
* TEXT() is vacuous.  We should at least define SOME format string 
commands.  Can anyone take this on?


--- David A. Wheeler

implementation-defined-openformula-wheeler.ods