New version of OpenFormula specification

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

Okay, here's a new version of the OpenFormula specification,
based on recent feedback and other editorial fixups.
Download from here:
http://www.oasis-open.org/apps/org/workgroup/office-formula/download.php/19155/openformula-20060714.odt

The highlights:
* Inserted a great deal of text to describe the impact of OpenDocument
   calculation settings; it shows up all over.  I could use help describing
   the regex option - HELP!  For the test cases, I decided to state that
   case-sensitive=false and search-criteria-must-apply-to-whole-cell=false, so
   we'll test at least a few cases with non-defaults (and these are common
   alternative settings, so they're worth testing).
* Several functions' semantics were changed so that they do NOT
   have multiple levels inside them.  Instead, any function simply
   has a set of requirements... which you either meet, or you don't.
   This restriction does make defining groups MUCH easier.
   Congratulate/blame Rob Weir for this :-).  There are a very few cases
   I haven't completed this (e.g., COUNTIF, SUMIF)... suggestions welcome.
   I might even include all shoulds in test cases, because it would make people
   take the "shoulds" more seriously.
   See my earlier email for the list of functions this affected.
* Modified text to make it clear that logicals MAY be a distinct type, but MAY
   be Number instead.
* Modified text to make clear that in "Convert to Number", if given text,
   an application may (1) convert it (e.g., using VALUE), (2) convert to 0,
   (3) report an Error value.
* Documented string length limit: All applications must support AT LEAST 32767
   (2^15-1) ASCII characters for the Text type, more is better.  Modified a few tests in
   LEFT and RIGHT so that they did not violate this.  Excel supports up to 2^15-1,
   OOo supports up to 2^16-1.  Anyone think we ought to increase the minimum?
* Rewrote/fixed "EXACT".  EXACT simply converts both sides to Text (if not already),
   and then compares if they are identical (including upper/lower case, regardless
   of the case-sensitive setting).  The previous text was (a) overcomplicated and
   (b) wrong anyway.
* Added the idea of a "Portable Constraint".  The problem is that the explanation
   of "Constraints" says that a function/operation must produce an error if
   a constraint isn't met (unless stated otherwise).  Yet in some cases there
   are really two constraints: (1) Regions that MUST produce an error, and
   (2) Regions that are not portable... applications MAY produce a result, OR
   an error.  This lets us distinguish those cases.  Let's see if this works.
   I used it on DATE, TIME, and FACT to start with.  Often the problem is that
   some functions may/may not apply INT() to their parameters, or may support
   a larger domain that's too painful to require for everyone.
* An experiment: I have created two NON-required feature groups,
   _DISTINCT_LOGICAL and _AUTO_TEXT_TO_NUMBER.  They're primarily
   for helping users with data files identify that their data files depend on
   these semantics.  In particular, depending on _AUTO_TEXT_TO_NUMBER
   is highly discouraged. I don't know if this idea has legs, but I thought
   it'd be easier to put it down & see if it helps.  Indeed, now that I've
   done this, I can't help but suspect that these groups might make good
   potential calculation settings to transition legacy data files... at least
   to add as a marker to warn somebody about them.
   We can also use this "feature group" idea to handle the one or two
   functions that we really wanted to split into multiple levels, but thanks
   to Rob Weir we can't :-).
* Changed to ISO's bolded shall/shall not/should/should not/may notation,
   instead of the IETF's capitalized terms.  Since we hope to get an ISO
   stamp, may as well make that change now.
* The usual removal of editorial mistakes.  No doubt these are compensated
   by the insertion of new editorial mistakes :-).

Unless someone speaks ASAP, this may be the last version to have
"level 1", "level 2", etc.  Instead, it'll have some predefined groups of
functions and operations, without implying that one is "better".

--- David A. Wheeler