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: Summary of 2009-10-27 teleconference

Here's my brief attempt to summarize our 2009-10-27 teleconference.  Please "reply" with corrections, etc.

Eric Patterson walked through comment #662, which was a large set of comments.  Many we'd already handled; a few were separate comments, so he created new JIRA comments of those so we can handle them separately.

Rob Weir will document parameter naming conventions for the financial functions in the front of the financial function section, and then switch the function descriptions to them.

Section 6.1 already notes that when a mathematical formula is given, it does NOT specify a required order of operation, but there was concern that this may not be obvious enough.  Also, make clear that this spec is a performance-based spec; unless stated we do not require specific algorithms.  We need to promote text like this (e.g., to the front or conformance statement), so it's more obvious, and clarify the two notations in use (math vs. OpenFormula).

There was a discussion about function naming conventions.  Since there are no "."s in the standard function names, many "issues" don't arise.  However, a future version of this spec may add user-defined functions, and there were concerns about ambiguity (esp. making it obvious to readers which do not have user-defined functions).  The group decided that a "USER." prefix *should* be written in front of user-defined functions, if an implementation has them, so that there is no ambiguity.

There was a discussion about EASTERSUNDAY(). At least 2 implementations (OpenOffice.org and Gnumeric) implement it, and it's difficult to do with current functions.  However, there was a lot of concern about "where does this end", because there are many holidays and calendar systems.  In particular, adding this function might slow down international standards body review; one person said this kind of function was like a "red flag".  It would be okay to add a *few* functions, but adding a *massive* number of functions is undesirable, and adding a single function that uses a string selector is also undesirable (what do you put in the string, that works across all languages?).  Several voted for it, while others voted against it, with slightly more "no" than "yes" votes.  Given this lack of consensus, I believe we will need to continue to NOT include EASTERSUNDAY() as a built-in function; applications can still exchange them using application-specific prefixes.  We can revisit this in a future edition.

We will next meet on Nov. 10 (2 weeks).  Unfortunately, there are differences in when different places transition to daylight savings time, so for clarification, we will meet at 10am U.S. Eastern Standard Time.  That may or may not be the "same time as usual", depending on where you are.

--- David A. Wheeler

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