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 think that's a good thing!
> I created a spreadsheet that illustrated each one of these cases, which I
> am attaching.
Thanks for doing that. And I agree, a little form to fill these out
(for example) would be great.
> 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?
Re-examining these is a good idea.
However, I think that expecting "0 implementation-defined values" is
both unrealistic and undesirable in most real standards, including this
one. In all non-trivial standards there are areas where there are
legitimate differences, and trying to prematurely force a specific
answer is simply undesirable. Simply identifying those areas, so users
know what to avoid, is a major benefit, even when we don't specify the
specifics.
Regarding the specifics, I have comments on two:
* I have to admit, I'm tired of the 0^0 discussions, but we can have
another one. There are good arguments for 1, or 0, or an Error, and
actual implementations DO vary, so it's hard to pin that down. I don't
think this has a massive impact on interoperability; it'd be NICE to pin
down, but it can be managed.
* In practice, I don't know why anyone would CARE what SUM() does with
an empty argument list. This is not a REAL interoperability issue; it's
hard to imagine a normal user even DOING that. We could leave that
completely *undefined*, and not impact real world interoperability.
If we can nail down a few more specifics, that'd be great. But we
needn't get hung up on this.
--- David A. Wheeler
