Open Formula - OpenFormula Attributes

OpenFormula Attributes

Key attributes of the OpenFormula specification and development process are:

• Fully open standard The specification meets all widely-accepted definitions of being an "open standard", including those by Bruce Perens and the European Union. For example, (1) both open source software and proprietary software can implement it, and (2) the work is based on consensus, not domination by any single supplier.
• Developed by many different implementors. OpenFormula is being developed by representatives from many different implementors, working together, including OpenOffice.org and Sun StarOffice (Eike Rathke), KDE KOffice (David Faure and Tomas Mecir), Gnumeric (Dr. Andreas J. Guelzow and Jody Goldberg), IBM/Lotus 1-2-3 (Rob Weir), and wikiCalc (Dan Bricklin, co-creator of the spreadsheet).
• Developed with experienced users. Many experienced users (such as Tom Metcalf, a scientist specializing in the astrophysics of the Sun) take part. The group includes several mathematicians, both users and developers.
• Focused development. The subcommittee is a large group focused specifically on spreadsheet formulae, and nothing else.
• Not rushed. OpenFormula is based on specification work that was first released on 2005-02-26, as well as a large body of research into different applications.
• Future-proofed format The syntax has been carefully designed to work indefinitely into the future. For example, it allows an arbitrary number of columns, while also allowing arbitrary names of values.
• Embedded test cases. OpenFormula includes a large number of test cases, ones that test and demonstrate the specification including "edge cases" that people often forget. More importantly, they are specially formatted so they can be automatically extracted and placed in a test spreadsheet to test applications.
• Rigorous definitions The test cases (noted previously) help it be far more rigorous. In addition, OpenFormula defines the types for each function (as prototypes of each function). Function definitions are examined deeply, e.g., YEARFRAC has subtle behavior in the leap years, which were carefully examined and defined.
• Doesn't mandate mistakes. The specification is carefully written to not require certain bugs, just because someone has a bug. For example, Excel incorrectly believes that 1900 was a leap year, and at least draft version 1.3 of the Excel specification claims that compatible applications must make the same mistake, and requires that applications cannot be more capable than Excel by supporting dates before 1900. By comparing many different independent implementations, the OpenFormula group can often detect when an application makes a mistake, and ensure that applications are not overly restricted.
• Innovations from many sources. OpenFormula covers the functions of Excel and OpenOffice.org, plus important functions not found in either one but instead found in other spreadsheet applications, such as Gnumeric and KSpread. For example, the specification includes the functions DECIMAL and BASE, which are much better ways to handle different bases than the old BIN2DEC (etc.) functions. It also includes bit operations like BITAND. These sources include Excel, OpenOffice.org Calc, Sun StarOffice Calc, KDE KOffice Kspread, GNOME Gnumeric, IBM/Lotus 1-2-3, Corel Word Perfect Suite Quattro Pro, wikiCalc, and DocumentToGo's SheetToGo. The subcommittee argues that by including the innovations from around the world of many different independent applications, they produce a better result that is far more inclusive.
• Room for innovation by anyone. Application-specific "namespaces" are defined for functions. This allows spreadsheet applications to add new functions, without interfering with current standard functions, future standard functions, or functions defined by other applications. As a result, different applications can add new functions without interfering with others; once a consensus arises about the new function, it can be standardized. The namespace is based on the Internet's naming service (reversed domain names), so ORG.OPENOFFICE.STYLE would be an OpenOffice.org-unique function.
• Internationalization. The specification does not assume that everyone uses "." as the decimal point, and indeed does not constrain user interfaces at all. Named expressions can have names in local character sets.
• Subset support. Applications can implement a subset or superset. To prevent user confusion, various "groups" are defined so that users can request specific sets of capabilities.