ODF 1.2 Begins Final 60-day Public Review

A major milestone was reached for the OASIS Open Document Format (ODF) TC last week.  The latest Committee Draft of ODF 1.2 (CD 05) was sent out for a 60-day public review.

As you may recall, ODF 1.2 is a single standard in three parts:

• Part 1 specifies the core schema, and was send out for public review in January.
• Part 2 is OpenFormula (spreadsheet formulas)
• Part 3 defines the packaging model of ODF, and went out for public review back in November

The current public review is the first complete review, presenting all three parts of ODF 1.2, including the new Part 2, OpenFormula, which is our spreadsheet formula language.

We will accept public comments (and that includes comments from technical experts in ISO/IEC JTC1/SC34) through September 6th.  Comments should be submitted via the TC’s public comment list, which you can join via these instructions.  You can monitor incoming comments also by subscribing to the comment list, by searching the archives or unofficially via the ODFJIRA Twitter feed.

The OASIS ODF TC will track and review all received comments and produce a report indicating how we have resolved each comment.  If we decide to make substantive changes to the specification based on comments received then we would approve such changes in a Committee Draft (CD 06) and send that out for a 15-day public review of the changes made.  I expect this will occur.  Then, the TC may vote to approve the public review draft as a Committee Specification.  Then we can have a ballot of the OASIS membership to approve it as an OASIS Standard.  And finally (after some additional administrative paperwork) we can submit ODF 1.2 ISO/IEC JTC1 according to their PAS process.

I think we can finish up the above remaining formal steps in the 4th quarter.

As I mentioned, the biggest difference in CD 05 over previous Open Document Format public review drafts is the inclusion of the OpenFormula specification.  If you are interested in contributing comments during the public review, I’d especially encourage you to review this document.  The other parts have already gone through one or more cycles of public review.  This part has not.

An outline of the contents of OpenFormula is:

• 1 Introduction
• 2 Expressions and Evaluators
• 3 Formula Processing Model
• 4 Types
• 5 Expression Syntax
• 6 Standard Operators and Functions
• 6.4 Standard Operators
• 6.5 Matrix Functions
• 6.6 Bit operation functions
• 6.7 Byte-position text functions
• 6.8 Complex Number Functions
• 6.9 Database Functions
• 6.10 Date and Time Functions
• 6.11 External Access Functions
• 6.12 Financial Functions
• 6.13 Information Functions
• 6.14 Lookup Functions
• 6.15 Logical Functions
• 6.16 Mathematical Functions
• 6.17 Rounding Functions
• 6.18 Statistical Functions
• 6.19 Number Representation Conversion Functions
• 6.20 Text Functions
• 7 Other Capabilities
• 8 Non-portable Features

The ideal reviewer for OpenFormula would have expertise either in formal descriptions of computer languages, e.g., know EBNF, type systems, numeric computing models, etc., or knowledge of one or more of the domains of knowledge we cover via the spreadsheet functions.  Honestly, I think we have enough “language lawyers” on the TC already, so I’m not so worried about that part.  And we did have direct participation by experts in some functional domains.  For example, the statistical and mathematical functions have been given a good scrub already by “Dr. G.”

However, the financial functions, these I think could use a thorough review by a subject matter expert, ideally an expert in financial accounting standards, actuarial sciences, or similar. If anyone knows such an expert who is willing to contribute comments on approximately 30 pages of function definitions related to loan amortization, bond coupon and yield, rates of return, day count conventions, etc., please let me know via email.

Note finally that although OpenFormula is part of the ODF 1.2 specification, it was designed to be a portable, embeddable expression language syntax.  It is a natural fit for a spreadsheet application, but it could be used wherever you need to encode a calculable expression with a rich library of domain-specific functions.  It was designed so it could be used in other contexts.

I think it would be a fun project to implement OpenFormula as a standalone library, Java or Python, where you feed it an expression, along with an “address resolver” object to resolve names (e.g., cell references) to values, and then have it calculate the output value.  This could be the first step toward some interesting things.  For example, I give you an ODF spreadsheet and you generate a web app that executes the same model as my spreadsheet.  (Many years ago, in the 1980’s there was a “spreadsheet compiler” that did something similar to 1-2-3 files).  Or I give you a spreadsheet and indicate some variable input cells and you execute thousands of variations on it via Monte Carlo analysis.  Or I give value ranges for you on input cells, and you calculate the sheet in variations via interval arithmetic.   This may be interesting for sensitivity analysis, risk analysis, analysis of propagation of errors, etc.

Think:  “Plugable spreadsheet evaluation engines, all understanding a common formula expression language.”

Once you have a standardized model for a spreadsheet and that model is independent from the calculation engine, then you have the ability to plug in in different calculation engines that conform to the standard, and these various calculation engines can have various strategies.  This is a very powerful capability, made possible via standardization.