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

[robert_weir@us.ibm.com]

"David A. Wheeler" <dwheeler@dwheeler.com> wrote on 06/12/2009 12:25:54 
PM:

> 
> robert_weir@us.ibm.com wrote:
> > Would it be worth taking a declarative approach on some of these?
> 
> I doubt it, but I'd like to know what others think.
> 
> I believe the goal is NOT to have zero implementation-defined items.  I 
> believe, and I suspect you agree, that the goal is interoperability.  If 

> some decision doesn't harm interoperability in real life, then having it 

> implementation-defined is a non-issue. In fact, prematurely specifying 
> something where there is disagreement can make things worse.
> 


Maybe I wasn't clear enough.  Implementation-defined means behaviors can 
vary, but implementations must document what they do, in written 
documentation that accompanies the software.  That is the typical 
definition.

A declarative approach means that implementation behavior can still vary, 
but instead of documenting this behavior only in written documentation, 
the behavior is documented in the XML itself.  This would apply in 
specific cases where there are only a small choice of allowed behaviors, 
such as 0^0, whether boolean and number are distinct, SUM(), etc.  We're 
not mandating specification evaluation behavior, but mandating that the 
behavior used by the application that writes the document be declared in 
the document's XML.

so something like:

of:distinct-boolean-type=true 

or 

of:empty-sum-result="error"

In any case, my experience with spreadsheets is that "real life" can be 
quite weird at times.  Take the zero-parameter SUM() for example.  The 
zero result can be quote innocuous in sum.  So a sum-of-sums would work 
fine even if someone might have an empty SUM() someplace.  This might be 
an error from the business logic perspective.  The spreadsheet might not 
be calculating what the user wants it to be calculating.  But this is user 
error and we can't outlaw that.  On the other hand, they author might well 
aware of this, and it might be a complicated result of indirect 
addressing, interaction with macro automation, etc., that leads to an 
innocuous use of an empty SUM(). 

Now take that sheet, whether manually created or created via macro 
automation, and send it to another user, with a different editor. Their 
empty SUM() no returns an error, which percolates erros all through the 
sheet.  If the original sheet was created via automation, the offending 
formula might be on a hidden sheet or row, maybe even protected with a 
password.  In any case, they are going to be totally confused as to why 
their document is totally screwed up.

So even little things matter here.  In particular, edge functionality with 
SUM() -- one of the most commonly used functions -- is going to show up 
far more often than edge cases of BIN2HEX().  So we might prioritize our 
efforts around reducing implementation-defined functionality in the 
most-used functions.

-Rob