RE: [oic] Implementation-defined, Unspecified, and Undefinedbehaviors in OpenFormula

[Doug Mahugh <Doug.Mahugh@microsoft.com>]

Rob,

I'm not sure how useful this exercise would be.  It sounds like quite a bit of work, and would certainly delay publication of ODF 1.2.  It would also increase the scope of work that implementers would need to do in order to implement OpenFormula, which would delay broad adoption of the standard.

Consider the example you've given below, where SUM() has no parameters.  If we dictate the runtime behavior for that situation, we may make it harder for implementers on certain platforms, or those working in certain programming languages, to implement OpenFormula.  We would also be introducing inconsistencies between the behavior of "SUM nothing" in other contexts, and its behavior in OpenFormula.

Regarding the specific example of 0^0, if mathematicians don't agree on what that means (and apparently they don't), it seems to me that we're creating an issue if the ODF TC takes a stand and attempts to stipulate the meaning/interpretation of 0^0.  Is that really a debate we want to get into?  And regardless of the position we take, aren't we risking being at odds with mathematicians who disagree?  I'd hate to see OpenFormula's future adoption limited by these sorts of debates, and I think we should be careful not to create too many of them.

It's not clear to me how this would affect type coercion in OpenFormula.  Currently there are two classes of conformance, and type coercion is only defined in one of them.  Are you proposing that these two conformance classes be merged into a single class that would standardize all type-coercion issues?

I'd rather see us focus on getting the current OpenFormula draft ready for public review, so that we can get ODF 1.2 approved sooner rather than later.  And I think that ease of implementation of OpenFormula should be a priority.  The existing approach seems to be well-designed from that perspective, so I think we should polish it up and get it done.

I have one question about this matter, which perhaps David Wheeler or somebody involved early on can answer: how were the existing implementation-defined items determined?  I'm assuming that some thought has already been given to what should be in the standard and what should be implementation-defined, and that is reflected in the current content of the OpenFormula draft.  Is that a fair assumption?  And if so, it would be useful to hear some of the rationale for how these decisions were originally made.

Regards,
Doug


-----Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com]
Sent: Wednesday, June 10, 2009 1:20 PM
To: office-formula@lists.oasis-open.org
Cc: oic@lists.oasis-open.org
Subject: [oic] Implementation-defined, Unspecified, and Undefined behaviors in OpenFormula

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.

My aim here is several-fold:

First, since implementation-defined means that we want implementations to actually define these behaviors, in their documentation, it will be good if we enumerate these cases, so it is clearer what we want them to define.
 It might be good, for example, to have an annex in the specification that presents a form that could be filled out listing these answers to these questions.

Then I wonder if we truly need to have all of these items be implementation-defined?  Or to ask the question differently, would there be tangible user benefit, in terms of increased interoperability, if some of these items were fully specified, knowing that some implementations would then need to change their code in order to conform, and that they would need to deal (perhaps with version-conditional logic) with legacy documents?

In some cases, the implementation-defined features are "hard" problems, like the various text to number paths, which are at the very least locale-dependent, not portable and hard to pin down.  This might be an area where there needs to be user awareness that these constructs are not portable and should be avoided in areas where portability is desired.

However, in other areas, like what SUM() does with a empty argument list, or what VARP() does with only two values, or what 0^0 or ATAN(0;0) is, these seem to be things where we might be able to come to some agreement on.

What do people think?  Is this an area that is worth cleaning up rather than trying to standardize a snapshot of the legacy application mess?  It seems to me that if people want a legacy monstrosity, they all have another standard the can use for that.  We have the opportunity with OpenFormula to be bit tidier.  But only if implementations are willing to conform to the standard, even if it varies in some details from what they have today in their apps.

-Rob