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 2010-03-23 of OpenFormula


Summary 2010-03-23 of OpenFormula

(As always, please reply-all with corrections.)

Attendees:
David A. Wheeler
Eric Patterson
Eike Rathke
Dennis Hamilton
Michael B.
Patrick Durusau
Rob Weir

Andreas Guelzow was on the chat line, but not on the phone
(perhaps he did not log off).

Discussion covered these topics:
* CD02 deadline
* unassigned CD2 comments (none)
* All topics marked NEEDS-DISCUSSION (including OFFICE-2345 raised by Patrick)
* We plan to meet on April 6, even though there's no TC meeting April 5.

Note: For our current status, see the dashboard:
http://tools.oasis-open.org/issues/secure/Dashboard.jspa?selectPageId=10056


Topic: CD02 timeline
Rob: The goal was to get the CD2 resolutions entered by April 1, then
there would be a week to apply the fixes, and once that's done we can
request a CD2 ballot.
Rob: We'd like to get as much of OpenFormula done now, in part because many
members will also have to work on the issues in the other parts.


Topic: Unassigned issues.
CD02 has no unassigned issues.


We then went through the items marked as NEEDS-DISCUSSION


Topic: OFFICE-2380
http://tools.oasis-open.org/issues/browse/OFFICE-2380

Eike: The functions that specifically accept reference lists specifically say so;
otherwise, it's obscure.

Eike: I recommend to leave it as-is.

Patrick: The problem is the "in these cases"... what does that mean?

Eike: Move the first sentence, then.
It's really "in all other cases, passing a reference list shall generate an error".

Patrick: Why say that here?

David: I.E., this is already subsumed by other text about types.

Patrick will add proposed text to JIRA.



Topic: OFFICE-2322 (ARABIC)
http://tools.oasis-open.org/issues/browse/OFFICE-2322

Wheeler: Perhaps add "The ARABIC function shall be able to correctly translate any sequence
that ROMAN can produce in either upper or lower case".

Eike: There's an identity statement.

Wheeler: We need to modify the identity statement to include a "shall".

Wheeler: I think going beyond that is unnecessary.

Andreas: I have no trouble stating a minimum, as long as it doesn't forbid extensions.

Eike: What would VVX be?

Andreas: It'd be zero.

Eric: Negatives too?

Andreas: VVVX would be -5.  I see no problem with that.

Wheeler: Let's just change the identity to a "shall", and permit extensions
without requiring it.  So change "The following identity holds..." to "The following identity shall hold".

?: We need to remove "The symbols V, L and D may not be followed by a symbol of greater or equal value."

Example: in "VLIVM", all the symbols "VLIVM" are negative, the "M" is parser.

The key thing is that we want the 'open' cases well-defined, even if not everyone implements them.


Topic: OFFICE-2287 (BETADIST)
http://tools.oasis-open.org/issues/browse/OFFICE-2287

Wheeler: I'd change "With substitution" to "Note that with substitution" to clarify that this is
a note for implementors, not a conflicting definition.



Topic: OFFICE-2345 (Defining error)
http://tools.oasis-open.org/issues/browse/OFFICE-2345

Eric Patterson added a comment on 08/Mar/10 07:09 PM
Wheeler: I think this is a good summary, "Functions should propogate errors"
is really "Functions SHALL propogate errors unless otherwise defined".

Eric: Is =#N/A a value formula?

Wheeler/Eike: Yes.

Wheeler: Note that "=" isn't defined specially, so
=#N/A=#N/A is a formula that uses the operator "=".
Since "=" isn't specially defined as an operator that consumes errors,
it will return the leftmost error (in this case, #N/A).

Eric: Excel does that.

?: OpenOffice.org also returns an error for =#N/A=#N/A
(it's not clear it's the same reason or same error code).

Patrick: I'd prefer that there not be a list of suggested errors.

?: This list in 4.12 helps people know what errors are in common usage.

Patrick: We can make observations that aren't "should" or normative.

Change these from should/recommended to simply an observation that
"implementations MAY implement the following constant error values".

Change "Applications should use the following identifier names when they
intend to represent that particular error and there is no more specific error that they are able to represent:"
to
"The following is a list of constant error names that are used by several existing implementations,
but note that evaluators may implement other constant error values:"
"Evaluators may support other error values, including the following:"

Change table title "Recommended Constant Errors (when no more specific information is available)"
to "Possible Other Constant Error Values".


Topic: What about April 6?  Are we meeting?

Wheeler: I think we should.

--- David A. Wheeler


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