Summary 2010-05-11 of OpenFormula meeting
(As always, please reply-all with corrections.)
Attendees:
David A. Wheeler
Andreas Guelzow
Dennis Hamilton
Rob Weir
Patrick Durusau
Eike Rathke
Eric Patterson
Michael B.
Note: For our current status, see the dashboard:
http://tools.oasis-open.org/issues/secure/Dashboard.jspa?selectPageId=10056
We discuss the current specification status,
OFFICE-2672 (character set support),
and OFFICE-2680 (Part 1 / Part 2 connection).
Wheeler wants to plan on meeting next week; we may be able to cancel it,
but it's easier to cancel meetings than schedule them.
===================
Topic: Current status document
Rob Weir: Yesterday TC call - we reviewed the status of defects.
There's never 0, but we've reached a low number and a comfort level, so
we'll turn it into a single set of all 3, to release as a single 3-part
proposed committee draft. That CD, if approved, would have a
60-day review period.
There are some security-related concerns about digital signature support,
etc., and encryption; we agreed to look at that during the 60-day period.
Final resolutions to OpenFormula are being resolved this week.
Any additional changes made now will be made after the public comment period
unless it's "incredibly urgent" (i.e., causes the CD to fail).
Any changes after a CD need to be change-tracked in some way.
(It may be via a special style.)
Topic: OFFICE-2672 (Internationalized) "Text in OpenFormula"
http://tools.oasis-open.org/issues/browse/OFFICE-2672
Rob: I'd like to limit discussion on the *technical* aspects, and
defer consideration of other matters.
Eric: Not sure what Excel supports.
Dennis: The red flag is that it's specific to ASCII.
646 is a 7-bit code; ASCII is an ANSI standard.
The international standard 646 allows for some substitutions.
PARSING:
Rob: Can we say the syntax of OpenFormula only requires ASCII,
other than strings?
Wheeler: In a sense - You can use &#...; to represent anything.
Dennis: The right name would be "basic Latin".
Wheeler: There's also the names of named expressions.
Rob: Can a formula be parsed with a parser that only accepts basic Latin
characters, except for strings and names of named expressions?
Wheeler: Essentially yes. All function names are within
basic Latin characters, as are operators, etc. Note that this DIFFERENT
than the run-time issues.
Dennis: Beware - it's the *characters*, but it's just the
basic Latin characters. It's wrapped in XML, anyway, so we
don't need to talk about encodings.
Michael: Similar to part 1. The defined terms only use ASCII characters;
there is no limitation on the characters permitted in data.
I'd expect to have named expressions that can be *named* and *process*
other characters.
Wheeler: Spreadsheets generally *display* function names in whatever
language is used, which is not necessarily the same as what is stored.
Eike: You can give function names with arbitrary characters.
Dennis Hamilton: Even if you only have basic Latin characters,
you can use XML character entities &#...; to do the rest.
Rob: The philosophy has been to be able to implement things in a more
constrained environment. E.G., we have not rigidly required
IEEE 64-bit numbers.
Dennis: I think the issue is that the WAY that we expressed it was
a red flag (e.g., ASCII). We shouldn't have said anything.
?: Could just define string as a sequence of Unicode characters,
and drop the second sentence entirely.
Wheeler: What about "UNICHAR(65537)"?
Rob: The code points depend on the character points.
GNUMERIC and OpenOffice.org support arbitrary Unicode characters.
Excel - unknown.
Eric: We should be clear about parsing formulas vs. run-time behavior.
For run-time behavior, it depends on the run-time environment.
Eric: That should be handled somewhere other than 3.2;
instead handle it in the conformance clauses.
Topic: OFFICE-2680 Part 1 / Part 2 connection
http://tools.oasis-open.org/issues/browse/OFFICE-2680
Dennis Hamilton: I have questions about the division of labor.
Rob: I created "identifiers", and mapped into part 1,
using the "identifiers" as common keys.
Then functions can be modified to note the identifiers.
I added "HOST-LOCALE" since several functions depend on that.
Dennis thinks some of them don't belong; if we need to take
any out, we can do that.
Dennis: (See his comments). HOST-REFERENCE-REVOLVER was
intended to be HOST-REFERENCE-RESOLVER. This
will help stabilize definitions.
Dennis: One thing that is not clear is error values.
Error values may be returned, and we allow the literals
to name values as well as deliver an error back to the host.
There should be more hand-shaking for these.
Michael: I don't see how that involves the specification.
Rob: There's no specification on how these values
are provided to the evaluator (bindings, etc.); no need to do so.
OFFICE-1187 is resolved.
Wheeler: Let's plan on meeting next week. We may be able to cancel it,
but it's easier to cancel meetings than schedule them.
--- David A. Wheeler