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

Summary 2010-09-07 of OpenFormula meeting

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

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:


Focused first on blockers for 1.2.

* 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

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

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

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

Rob will finish this week.

* OFFICE-3342 ("IRI")

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

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 

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