Summary of formula meeting 2010-01-26

["David A. Wheeler" <dwheeler@dwheeler.com>]

Summary of formula meeting 2010-01-26

Here is my summary of the Office-formula ("OpenFormula") meeting on 2010-01-26.
Please reply-to-all with any corrrections.

Attendees:
Eric P.
Eike R.
David A. Wheeler
Andreas G.
Hideki Hiura
Patrick D.
Rob W.
Dennis Hamilton
Michael B.


Issue (raised by Eike): How deal with unfixed issues once deadline arrives?

Rob: It's reasonable for us to say that editing, conformance clauses, etc.,
have reached a point where it's ready to be a committee draft.
We may get additional comments to resolve.
Then eventually make it a public review draft, get more comments, etc.
We don't want to set the bar TOO high for a CD draft.
We may have more than 1 CD.
The broad scope should be correct, vote on it as a CD and move on.
If you look at the timing of part 1 (the largest part)... its comment
period ends March 26.  By working backward from mid-April,
we need to have a revision ready in mid-Feb, and second CD mid-March.
The first CD of part 1 was rough and had sections missing.
For the financial functions, public review should help.

Michael: I agree with Rob.
Let's not focus on issues that don't need to be resolved.

Rob: We might create a tag for "fixed" version.
We could plan on having two CDs of part 2 before going to public review.
Then identify "which issues are critical to be resolved", then focus on them.
Then we'd at least highlight what's important.
I'd highlight structural changes... that way, we can enable change tracking later
without creating a mess (from CD1 to a later version).

Eike, Wheeler: Sounds fine.

Rob: Any structural changes that need to happen first?

Patrick: If we leave the processing model as chapter 2,
then there are some things that may move about but won't
change the numbering.  Nothing really obvious that reorders chapters.

Michael: There are 2-3 sections in the conformance clause chapter that
aren't really conformance clauses.  That could change the numbering of
the conformance clauses, which isn't TOO problematic but would change
numbering.

Dennis: We found that the change tracker is actually remarkably smart.
I agree; the organization is pretty close to stable.

Wheeler: Even removing pseudotypes would be only within a chapter.

Dennis: We want to make sure we have the structure down before CD1 release.

Rob: Perhaps bring it to TC on Feb. 15, 2009.
Uploaded by Feb 10.
Two more calls of subcommittee precede this.

The official CD would *not* include the test cases, rationales in yellow, etc.
Michael B. has a script that removes these, and it will be used to generate
the version to become the CD.

There was then a discussion on tracking changes for CDs.

Patrick has the document & has been doing editorial changes.
Patrick has a few issues, e.g., matrix, what is "expression", etc.
Plans to finish a version this Friday; then Eike can make editorial changes
through the next Wednesday.


Issue: Test cases.

The test cases will NOT be in the CD.
But what about epsilons for the answer?

Rob: We should be giving precise mathematical descriptions for the
intended result.  For some function, there is no closed form, so it's always
an approximation.

Eric: Didn't try to explain what is "close enough".

Eric: I have the test cases.  Is the concept of epsilon ("what's good enough")
sufficiently in the text?

Then the group discussed IEEE standards on numerical representation and model, etc.

Rob: We could look at the C/C++ specs for example spec text.

Eric: I'm fine with 3.3.1 as-is, I just want to make sure others are.
Let's create a JIRA issue on this, separate from the text cases,
and then separately resolve the test cases.

Rob: Every implementation must decide how much precision to implement.

Wheeler: The numeric model is implementation-defined.

Eric will create the JIRA issue, Dennis will comment on it.


Wheeler: Are there other blockers?

Patrick: The formula refers to part 1 for "constant values", but part 1 says "fixed values".

Dennis: We have conversions between strings and numbers.
E.g., when  you emit a document, and it has a value, then that's what the values are.
In that case, they're really just the current values.

Section 3.1 uses the term "constant value", which is a value NOT defined by a formula.
In many other sections, (e.g., COUNTIF), it's NOT a reference.

Patrick will create JIRA issues for these.


--- David A. Wheeler