Summary 2010-09-07 of OpenFormula meeting

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

Summary 2010-09-07 of OpenFormula meeting

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

Attendees:
David A. Wheeler
Eike Rathke
Eric Patterson
Andreas G.
Rob Weir
Patrick D.

Not attending:
Dennis Hamilton (who sent his regrets on 6 Sep)

We WILL meet next Tuesday.

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



TOPICS:

Focused first on blockers for 1.2.


* OFFICE-3178
http://tools.oasis-open.org/issues/browse/OFFICE-3178

Need to connect part 1 & part 2 with a "host setting".

Eike: Can do it, but won't be able to until returns a week later.


* OFFICE-2663
http://tools.oasis-open.org/issues/browse/OFFICE-2663

Wheeler: MacOS imposes a different normalization than everyone else.

Eike: CODE is a bad example, it depends on the code page.

Weir: For Unicode, can we just say implementation-defined, but must be
first Unicode character or "logical" value?  What's that?

Wheeler: Could we just say Unicode codepoints?

Patrick: No.  If you look at XPATH language, it says surrogate pairs should be treated specially.

Wheeler: XPATH doesn't require normalization, it just warns
about "unexpected results"; can we do the same?

Weir: What do you with a number converted to a Unicode character?  It should be implementation-dependent.
We have functions that want to operate at a character level, and it doesn't
require normalization.

Wheeler: Someday might want normalization functions, but no implementation does that,
so that's not something we standardized do today.

Eric P: Even adding parameters would be messy.

Rob W.: It is annoying that someone could get different lengths on different systems.

Rob: If we had no implementation constraint, what would we say?
Unicode consortium defines 4 normalization formats.

Wheeler: Not clear that you'd want to force normalization.

Patrick: Perhaps say "you must use a normalization".

Wheeler: No, because data can be from external files, URLs, etc., which
might use different normalizations.

Weir: Not sure we can solve this problem.

Eike: Implementation-dependent.

Weir: It's perfectly reasonable for an implementation from leaving it as-is OR from normalization.

Wheeler: Could say, "Implementation may, but need not, normalize text; no specific
normalization format is specified".

Weir: If given un-normalized string, functions COULD normalize each time.

* OFFICE-3035
http://tools.oasis-open.org/issues/browse/OFFICE-3035

All no-action or ODF-Next; Rob will look through.

Per group:
Part #1: Current draft seems correct.

Part #2: We have FORMULA() function.
The rest is UI, which is outside our scope.

Part #3: No action.

Part #4: ODF-Next.


[Now the NEEDS-DISCUSSION items]
* OFFICE-3040
http://tools.oasis-open.org/issues/browse/OFFICE-3040

Eric: Probably just change log(rate) to log(rate+1).

Rob will finish this week.

* OFFICE-3342 ("IRI")
http://tools.oasis-open.org/issues/browse/OFFICE-3342

The Japanese are concerned about this;
clearly we want to make sure that these specifications
properly handle international issues like this.

Wheeler:
http://www.w3.org/2004/11/uri-iri-pressrelease.html.en
says that "every URI is already an IRI."
Therefore, IRIs are a superset.
Therefore, we should switch everything to IRI for maximum flexibility
where we can.

Weir: Perhaps not in the zip packaging; might not be able to handle IRI.

Wheeler: Fair enough.  But for formulas, we should accept IRIs not just URIs.

Patrick: We need to insert a normative reference for IRIs.
IETF RFC 3987, and that is still current.

Wheeler: Patrick - please add a comment to switch in part 2 all URIs/URLs to IRIs.

* Procedural stuff.

Rob: Comment period is over, comments should all be in.
We have a few weeks to make changes as needed, to produce a new
Committee Draft.

We will meet next week.

--- David A. Wheeler