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-09 of OpenFormula


Summary 2010-03-09 of OpenFormula

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

Attendees:
David A. Wheeler
Dennis Hamilton
Rob Weir
Andreas Guelzow
Eike Rathke
Eric Patterson


NOTE: Our meeting next week will have
the same *U.S.* time, which means that it is an
hour earlier for Europe and China.


Discussion:

============


TOPIC: Voting on the CD.
http://www.oasis-open.org/apps/org/workgroup/office/ballot.php?id=1841

CD1 passed, 17 out of 18 votes, all "yes".

Rob: Need to discuss follow-up. We're supposed to update title page
and footers so it says that, change date to approval date,
upload that as PDF and HTML.

Rob: I'll take that as a task.

Wheeler: By Thursday?

Rob: Yes.

Dennis: The CD will go into a special directory, yes?

Rob: A public review draft is more complicated, but that doesn't apply to CDs.



TOPIC: Meeting times due to daylight savings time.

Wheeler: I propose use the rule "do whatever the U.S. does",
because the Adoption TC uses that rule.

Rob: Doing anything else would cause problems.

Rob: This Sunday, North America will change times,
Europe/China will be an hour earlier, and the week after that,
Europe changes, China stays an hour earlier.

Dennis: So, next week, UTC will be an hour earlier.


TOPIC: OFFICE-2568
http://tools.oasis-open.org/issues/browse/OFFICE-2568

We need to understand why this happened, so it won't happen again.

Wheeler will send an email to Michael B., asking to check into this.

Dennis: In the original, the object isn't there... the defect
probably occurred BEFORE the process.

Draft 21 of 16 Feb was okay.
Draft 21a of 18 Feb is not okay.
Something happened between those versions.
We need to figure out what happened so it won't happen again.



TOPIC: OFFICE-2586
http://tools.oasis-open.org/issues/browse/OFFICE-2586

Eike will pick this up.

Excel has "Very hidden" sheets, which are different from "hidden" sheets.
A "hidden" sheet is not displayed.
A sheet can also be "very hidden" sheet; this can only be set via programs.
This is a different property.
You can only get access to it via the object model.
Excel currently doesn't have a SHEET() function... would it be affected
by these values?

Rob: If it's hidden from the calculation, that's different than just not displayed.

Hidden is useful - it hides intermediate values from view -
but it still affects calculation.

"Very hidden" can still affect calculation; they're just
not under UI control.

OpenOffice.org ignores the "hidden" property for SHEET() and SHEETS().

Rob: Hidden is a visibility property, not a calculation property.

Wheeler: We should explicitly note that for SHEET/SHEETS, it doesn't
matter if they are hidden.

OFFICE-2030 is related (subtotal).
We should note that UI and object model can make some information hidden,
and how they are treated.

Rob: I can try drafting a statement.
A formula is within a context of a table of values.
Some columns/rows/sheets may be hidden, and then define the behavior
according to that.  Rob will create a new JIRA issue, assign to himself,
and resolve.

Eric: When you filter a list, there are functions that can give you
totals (etc.), on JUST the visible values.
At first, the subtotal had a list of what function to use.
But if you hid cells manually, they weren't excluded from the total.
So a new set from 101..111 was created, that excluded hidden values from
the total.

Eric: "Very hidden" in Excel only applies to entire sheets.



Topic: NEEDS-DISCUSSION filter not working properly.

Eike fixed the NEEDS-DISCUSSION filter for the
OASIS Technical Committees Issue Tracker at:
http://tools.oasis-open.org/issues/secure/Dashboard.jspa?selectPageId=10056



Topic: OFFICE-2322 (Nontraditional Roman numerals)
http://tools.oasis-open.org/issues/browse/OFFICE-2322
This was marked as "NEEDS-DISCUSSION", so we discussed it.

Issue: What do we do with non-traditional Roman numerals?
E.G., "IIVI"?

Andreas Guelzow would like nontraditional Roman numerals to be
*permitted*; implementations may accept it, *or* return Error.

(This is a good example of in general what we require evaluators
to do vs. what we permit them to do... what is the boundary between them?)

We can discuss the specific (minimum) case, or the more
general case.

Wheeler: We should define a minimum set, and then permit more.
I've seen "MIM" for 1999.

Rob: Define an algorithm for as many as possible.

Wheeler: We could specify a minimum set ("must implement"),
note that more *may* be implemented (Error may be implemented),
and then give a general algoriothm that handles values beyond
the minimum set.

Time ran out;  Wheeler asked that everyone with an opinion
or information on this topic please comment on the JIRA comment:
http://tools.oasis-open.org/issues/browse/OFFICE-2322


--- David A. Wheeler


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