Agenda Request: Implementation-defined, Unspecified, and Undefined behaviors in OpenFormula

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

Rob,

I notice in reviewing JIRA issues that there are many places where 

(1) implementation-defined is important in being able to say something
definitive about an ODF feature; and,

(2) implementation-defined is very valuable in sorting out the relationship
of a feature to the different conformance classes.

PROPOSAL: That we introduce the implementation-defined condition in the
conformance section of all parts of the ODF specification.

I request that we discuss this on the next available agenda (06-29 or
07-06).

 - Dennis

PS: I don't think declarative is as passive (done as comments) as David
Wheeler remarked.  It seems to me that such declarative information is about
what is required to be supported for the document to be consumed properly.
It could be ignored, of course, but there is the opportunity for an
implementation to indicate that it cannot honor the declarative requirements
and also obtain agreement to do what it is able to do, if it has a fallback.
Some declarative requirements around discretionary provisions (size of a
table's "used area" for example) might actually be ones that an
implementation, in checking them, might end up declining to process because
there is no reasonable fall-back in the implementation.
    The request for agenda discussion is with regard to whether the TC
considers it worthwhile to introduce an implementation-defined condition on
required documentation.  We certainly need it, either way, to characterize
certain features in a clear way.



-----Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 
Sent: Friday, June 12, 2009 09:55
To: office-formula@lists.oasis-open.org
Subject: Re: [office-formula] Implementation-defined, Unspecified, and
Undefined behaviors in OpenFormula

"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

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php