OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office-formula] Implementation-defined, Unspecified, and Undefinedbehaviors in OpenFormula


robert_weir@us.ibm.com 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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]