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: 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





implementation-defined.ods



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