Summary 2010-05-18 of OpenFormula meeting

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

Summary 2010-05-18 of OpenFormula meeting

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

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


NOTE:  We will reconvene on June 8, and meet on alternate weeks from then on.
We will NOT meet on the next 2 weeks (just like the TC).

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


TOPICS:

* Entertain any questions about the next steps on formula (we're entering a 60-day review period)
Rob: Need to agree on meeting schedule going forward, e.g., alternate week.
We'll need to respond to comments, etc., but not same level of intensity.

* Discuss proposal to *not* have a teleconference in the next 2 weeks
   (the TC isn't meeting either).
  We will reconvene on June 8, and meet on alternate weeks from then on.

* Review any "NEEDS-DISCUSSION" items on the dashboard (currently none).
   The dashboard is at: http://tools.oasis-open.org/issues/secure/Dashboard.jspa

  None.

* Continue discussion of internationalization, OFFICE-2672.
   http://tools.oasis-open.org/issues/browse/OFFICE-2672
   In particular, can everyone support *all* Unicode characters?
Wheeler:   I'd like to add that as a conformance requirement, at least for the "Medium" group.
Eric: Haven't had much luck yet on getting info on
  Excel, the person needs to talk to isn't available.
  Many different issues.  How much can we abstract outside individual functions?
  Requiring support implies many things: (1) storage (more part 1),
  (2) using operators to act on text strings
  (3) individual definitions of functions.
  Perhaps we can craft text that covers all of them.
Rob: What if we, for initial exploration, it's pure Unicode.  At storage it's UTF-8 or -16
  or whatever. At run-time it's pure Unicode.  If it becomes a horrendous mess, then do something else.
Dennis: I don't think we can do that hastily.  I don't think there's a requirement in part 1.
Rob: Part 1 defines formula as an attribute value, and XML defines what's allowed.
Wheeler: Any Unicode code point could be represented with &#...;.
Dennis: We haven't expressed a requirement on what cells must be able to store (as text).
Rob: You could create illegal characters, e.g., the null character; that's not allowed at run-time.
     What about 0 as a code point?
Dennis: Can you handle code point 0? E.G., is CHAR(0) allowed? Required to be supported?
Eike: I don't think null character support is required.
Rob: Excel 2003 reports an error for CHAR(0).  OO.o permits CHAR(0), though its display varies.
Wheeler: We shouldn't forbid CHAR(0), but *shouldn't* require that implementations support code point 0.
Eric: Standard should *permit* Unicode, but not impose run-time requirements.
Wheeler: Perhaps require at Medium group, require all Unicode characters other than 0.
Eric: Character repetroir (sp?) need not be the same as the set of functions.
Rob: It's not clear that we should require arbitrary characters.  It's allowed,
  no constraint in the standard that prevents any Unicode.
  I don't think we can mandate that word processors support every language / code point.

(At this point, we had serious technical problems with the teleconference service;
we could not hear each other.  We lost many minutes.)

Wheeler: The current proposal (by Eike) would do exactly that, permit support of
  full Unicode without requiring run-time support for any particular set of code points.
Rob: We need to create an inventory of what's supported and what problems are there?
Eric: What else are you looking for from me?
Dennis: Shouldn't return "half a code point".
Wheeler: What do you get beyond BMP?  E.G., with LEFT(" " & UNICHAR(70000) & " "; 2)?
Dennis: It should return UNICHAR(70000).  The values that go back and forth are code points,
   and the encoding (UTF-8, UCS-8) shouldn't matter.
Rob: This is like C++ evaluation points.  At what point should it not value.
Eric: What do we gain by enumerating what implementations currently do?
 [This wasn't addressed directly in the meeting, but David A. Wheeler believes that
  the international community might want a stronger requirement on code point support;
  knowing what implementations currently provide helps us understand how difficult or
  easy such a requirement would be.]
Eike: I added a comment.  We shouldn't require that an implementation do normalization
  in any particular way.  Should simply do the values of the code points.
Rob: If a character isn't legal, what happens?  Suppose I have an UNICODE(UNICHAR(1000000000))?
    Are they inverses for all values?  Implementation-defined?
Wheeler: I wouldn't expect an implementation to check the gaps.
Dennis: I'd expect that the gaps would raise an error.
Wheeler: I wouldn't; I'd expect that gap-checking would be implementation-defined.
  Returning an error if it's above or below the legal range of Unicode code points
  would be sensible.
Dennis: Accents and diacritical marks do occur.
OFFICE-2663 talks about "what is a character", and is related.
Eric: Happy to investigate what Excel does, but need to be specific.
Wheeler: Okay. Specifically, does Excel handle characters beyond BMP?  How?
  I believe Excel stores as UCS-2, at least in some circumstances; what are the circumstances?
  We have new functions UNICODE and UNICHAR, and it'd be
  nice to require their support beyond the BMP.
  The Excel expression UNICODE(LEFT(" " & UNICHAR(70000) & " ", 2)) should return 70000,
  if it had UNICODE and UNICHAR; what would be the impact of requiring that?
  Basically, I think we're going to be pressured to *require* a repetoire
  of code points, at least to support many countries.  If we are, what are the
  impacts of various requirements, such as requiring support beyond BMP?
Eric:  Also, we're getting some unassigned tasks, we should make sure they get assigned.
Wheeler: Agreed.  All, please look at unassigned items and pick them up!


--- David A. Wheeler