[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.) 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]