About OpenFormula - Office Wiki

Author: The OASIS Office Formula Subcommittee

OpenFormula is the informal name of the OpenDocument formula specification. The OpenFormula draft specification describes how to exchange recalculated formulas between any two applications (primarily spreadsheet programs). Anyone can implement this specification, both proprietary and open source software projects, and it's being developed through the cooperation of a large number of competing implementors.

OpenFormula is designed to let you own your own data, so you can choose which spreadsheet application you want to use, and still exchange data with people who made different choices. As a result, countries can remain sovereign from their suppliers, organizations are no longer entrapped by any particular supplier, data will be accessible far into the future, and anyone can innovate and use the innovations of others.

OpenFormula only covers recalculated formulas (such as those for spreadsheets). For the display of arbitrary mathematical expressions, OpenDocument uses MathML, the standard for displayed mathematical expressions in XML-based documents. MathML and OpenFormula are complementary standards, for example, the OpenFormula specification uses MathML to describe functions.

This page provides some information that counters some common myths, provides the current schedule, and describes some of the key advantages of OpenFormula. It then discusses issues related to supersets and subsets, and the "grouping" system in OpenFormula that we believes meets the needs of both implementors and users. This page then gives a brief history of OpenFormula, and explains how you can be confident that OpenFormula is an open standard. This page concludes by explaining how you can get more information.

Countering Myths

First, let's dispel some two myths:

Myth #1: You can't exchange spreadsheet files between applications that use OpenDocument format.

People are already routinely exchanging OpenDocument spreadsheet files, including formulas, between different applications. The OpenDocument specification itself, plus the hard work of many developers means that people are already quite successfully exchanging spreadsheets. That's in spite of concerns and carefully-crafted "problems" of years ago. It's also important to note that some of the old tests (such as those of NewsForge) used carefully-crafted formulas to cause problems, or used a very old version of KOffice, which had a poor formula engine. Much has been improved since then, in particular, the KOffice formula engine has since been completely replaced with a much better implementation.

And remember that if you "can't" exchange spreadsheet files using OpenDocument, the alternatives are worse. People who say "OpenDocument can't exchange spreadsheet formulas, because the definition isn't published in a final form" often use Excel's ".xls" - yet this is an essentially undocumented format! OpenFormula is already far better defined than ".xls" format, and in any case, this format is being abandoned by all spreadsheet developers. The other likely alternative is Microsoft's XML format, but this is much less mature than ODF's format (see below for more). What's worse, both of those formats are completely controlled by a single vendor who has a financial incentive to inhibit open competition. Not a good idea if you wish to be sovereign from any particular supplier.

So, go ahead and use OpenDocument right now, even for spreadsheets; typical spreadsheet formulas already exchange very well between OpenDocument applications.

Myth #2: It's okay to leave formula formats undocumented.

While files can be exchanged today between applications without a formal specification, in the long run open, public specifications are very important for full interoperability of formulas.

OpenDocument is the first format spec to include a formula specification. Contrary to what this myth might suggest, no format specification before OpenDocument format included an open specification for spreadsheet formulas. The lack of a formula specification in OpenDocument 1.0 was not an aberration. Rather, the OpenDocument community was the first in history to recognize the need for a formula specification, and wanted to ensure that it was done well. As such, we are at the forefront of the development of Open Standards. This need was first discussed in the OpenDocument TC in 2004, and it was agreed that it would be valuable (and that it would need to be done separately). The first draft of OpenFormula was released in February 2005, and was informally developed through the interaction of many in the community of OpenDocument users and application developers. OASIS formally established the formula subcommittee on February 2006; the subcommittee uses the OpenFormula project's specification as their base document.

Even more importantly, the OpenFormula specification is being developed through an open process, including competing vendors and several volunteers. It includes input from multiple implementors and multiple users, without domination and control by any.

Contrast this situation with the oft-cited alternatives to OpenDocument: The inadequately-documented .xls format, and the dreadfully incomplete Microsoft XML format. Again, both are completely controlled by a single vendor who has a financial incentive to inhibit open competition. Microsoft has steadfastly resisted, and still refuses, to publicly document the ".xls" file format that is widely used to exchange spreadsheets (including their formulas). Microsoft didn't even begin working with a standards body until December 2005 - 11 months after the first public draft of OpenFormula, and 7 months after OASIS had completed its work on the OpenDocument 1.0 format. What's more, the initial December 2005 version had no details on formulas; up through April 2006, Microsoft had refused to publicly document the formula specification in their vendor-specific XML format with any specificity. Finally, 15 months after the OpenDocument community began defining formulas, Microsoft finally began; in May 2006 it released its first public draft specifying the Microsoft XML format for formulas. Yet this version is very incomplete, and worse, it was released using committee rules that openly discriminate against all other suppliers. We are glad that 15 months after the OpenDocument community began developing an open standard for formulas, Microsoft has started to follow in the tail-lights of the leaders, and has begun to release information about its native format for formulas. We continue to invite Microsoft to instead join other developers to develop industry-wide standards in a neutral setting.

OASIS, and the wider OpenDocument community, take specifications in general (including specifying formulas) very seriously. We want there to be a public specification which gives much more detail about how to exchange spreadsheet formulas, including rigorous definitions of a large set of standard functions. To be credible, such a specification must be developed by many different implementors, working together. Without many representives from many different suppliers, any specification would be a sham. The goal of the office formula subcommittee (SC) is to ensure that users can switch from one application to another, and exchange data with users of different applications, all while recalculating completely correctly. That also means that users must not lose access to their existing document collections in Excel, OpenOffice.org, StarOffice, KSpread, Gnumeric, or other applications. We have developed this work based on existing practice, so that the many people who already use or are converting to OpenDocument can continue using what they're using with confidence.

And we're succeeding.

Estimated SC Schedule

October 2006: Complete all function definitions, full draft of main text.
December 2006: Complete whole-part review, a quality assurance (QA) review where we compare parts of the document to the other parts and to existing applications, resolving any conflicts between sections or ambiguities. We will add test cases as necessary to clarify the draft.

Note that by Febuary 2006 we already had a specification defining over 100 functions. For the most part, OpenFormula is a specification documenting what applications already do, and application developers have already been modifying their applications to track the specification where necessary. As a result, when we complete it, we expect that many OpenDocument applications will already comply or mostly comply with it, since typical OpenDocument-handling applications already comply with much of it.

Some old messages reported that we would not complete until October 2007, but that is simply not true.

Advantages of OpenFormula

Here are some key advantages of OpenFormula, most of which are unique to OpenFormula as a formula specification:

Developed by many different implementors. If you want to be locked into a single supplier, forever, then you should use a specification written essentially solely by that supplier and by groups completely controlled by that supplier. But if you want to be able to choose your supplier, then you need a specification written by many different suppliers, working together without domination by a supplier. We are graced with representatives from many different implementors, all 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). And you can see from the mailing list that there is no domination; all implementors are working together to create the best specification possible for the many millenia ahead.
Developed with experienced users. We also have many experienced users (such Tom Metcalf, a scientist specializing in the astrophysics of the Sun). Several mathematicians, both users and developers, are a part.
Open development. The discussions of the group, and weekly drafts, are available to the public. Specifications developed behind closed doors usually have something to hide. Instead, we invite and respond to criticism, revealing the whole spec and discussions behind it, because that's the only way to produce a truly good and open result.
Fully open standard This is a fully open standard - the specification meets all widely-accepted definitions of being an "open standard", including those by Perens and the EU. Both open source software and proprietary software can implement it. The work is based on consensus, not domination by any single supplier... the chair of the group isn't even an implementor! OpenDocument and OpenFormula are open standards, because they fully comply with the requirements of being an open standard, including being developed in an environment where there is no domination or control by any one supplier. Empty promises and market-driven labelling do not make a standard open; we work hard to make things truly open.
It's already taken seriously. Implementors have already made changes to their applications due to the work of this body, such as changing how they handle signed values in MOD, the association of exponentiation, and even implementing new functions to conform to the draft standard. When application developers change their applications to make sure they comply with a specification still in development, you know it's being taken seriously.
Focused development. The subcommittee is a large group focused specifically on spreadsheet formulas. We've gathered world experts in this specific area, and as a result we can create high-quality results. In particular, we're not distracted by having to figure out how to manage spreadsheet formatting, or word processing; all of that has already been ably handled in the OpenDocument standard.
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. This work hasn't been rushed, it's been worked on for a long time.
Format for tomorrow, not just today. 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. Every few years applications start widening the number of allowed columns, yet many formats are not designed to handle this predicable change. The OpenFormula format allows as many columns as you'd like; it has no built-in limits (unlike Microsoft's XML format). It also supports arbitrary names of named expressions and sheets, including international characters - so users can use names that are natural for them, no matter what their language. It defines how to exchange references to subtables, references to unnamed cells in external spreadsheets, and other such capabilities as well. It also avoids nasty mistakes in the syntax, such as considering space an operator in some places and ignorable in others (this can lead to horrific problems when exchanging data).
Embedded test cases. Specifications often give a few examples, hidden in the body of the text. In contrast, OpenFormula includes a large number of test cases, ones that test and demonstrate the specification including "edge cases" that people often forget. What's more, they are specially formatted, and we have a program that extracts them from the OpenDocument text file and creates a spreadsheet that tests applications. This is incredibly powerful - this means that users of OpenFormula-based applications can have high confidence that their documents will be interpreted the same way everywhere, because anyone can run the tests and see the results for themselves. Rob Weir reports, "This gives us a self-testing specification, a great labor savings, as well as a demonstration of the innovative things you can do with ODF (OpenDocument format)."
Rigorous definitions, including function data types. The test cases (noted previously) help us be far more rigorous. In addition, we define the types for each function (as prototypes of each function). Spreadsheet functions are very sensitive to the types of their parameters, yet almost all documents on spreadsheet functions completely ignore type information. In contrast, for every function and operator we clearly identify the type of every parameter and the type of the result. We delve in deep into function definitions, making sure they are defined sufficiently for independent implementations to correctly interoperate. For example YEARFRAC() has subtle behavior in the leap years, with different behaviors required by various financial bodies (AFB, ISMA, ISDA). We do the research and define the exact behavior, where other specifications leave the details unspecified. And in cases like this we include a large number of test cases, so that users can be confident that applications will get it right.
Doesn't mandate mistakes. Just because one program gets something wrong doesn't mean that everyone should make the same mistake. 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. Nonsense. Instead, OpenDocument wisely stores dates as dates (not just numbers), and thus does not require that applications have this bug. The Excel specification also requires that applications cannot be more capable than Excel (it doesn't permit support for dates before 1900). Again, nonsense. In fact, at least one OpenDocument spreadsheet application (OpenOffice.org Calc) can correctly calculate dates and date differences going back to 1583! Similarly, many applications handle complex numbers in a very clumsy way; we've devised the specification to make sure that future applications can support better approaches, instead of tying their hands to a technique known to be poor. Because we constantly compare many different independent implementations, it's often easy for us to detect when an application makes a mistake.
Innovations from many sources. We cover 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. Indeed, we constantly analyze many different applications (both for innovations and to identify defects through cross-comparison), including 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. By including the innovations from around the world, of many different independent applications, we produce a better result... and one that is far more inclusive.
Room for innovation by anyone. We define "namespaces" for functions. These allow spreadsheet applications to add new innovative functions, without interfering with current standard functions, future standard functions, or functions defined by other applications. This makes it possible for different applications to innovate without fear, and once a consensus arises about the new function, it can be standardized (combining the ideas of many). What's more, the namespace is based on the Internet's naming service, so you don't need to pay separately to innovate... everyone can innovate! Without this ability, only one supplier could practically create new functions; the result would be a stifling of innovation. The OpenFormula approach creates a whole process for bringing innovation from anywhere in the world, from any supplier, to users.
Internationalization. We have representatives from around the world, to help us keep the entire globe in mind. Contrary to the thinking of some, not everyone uses the "." as the decimal point; our specification is designed to not presume this. In fact, we've carefully not constrained the user interface, so that users can use whatever user interface is most natural to them. Named expressions can have names in local character sets, and yes, we specifically test for this.
No straightjacket. We work hard to ensure that users can choose their application, instead of being locked into only one office suite. For example, we have different groups of functions (small, medium, large), so that tiny applications aren't required to implement unnecessary functionality. Yet, if you create a document on an application that only implements the "small" set, as long as you stick to the standard you can hand that document to any application that implements a larger set - and know that it will work.

Subsets, Supersets, and OpenFormula Solutions (Groups and Supplier-unique names)

Subsets and supersets are necessary for open standards, yet if not carefully handled they can be problem. Let's see why subsets and supersets are required - yet can be a problem - and how OpenFormula addresses those potential problems.

Need for Subsets and Supersets

Clearly, standards are critical for interoperability. One obvious but hopelessly naive way to get "perfect" interoperability is to strictly forbid the implementation of subsets or supersets. Malevolent organizations can enforce this legally by granting patent grants that only permit implementations of "this specification, exactly". This "one size fits all" model doesn't work, and many definitions of "open standards" (including the most popular definition by Perens) explicitly require the ability to implement subsets and supersets. Without the ability to implement subsets and supersets, standards cannot respond to changing conditions. For example:

If you can't implement a subset, you implicitly require that everyone recreate a new incompatible standard from scratch when only a subset is needed. This would quickly cause a proliferation of completely incompatible standards for only slightly different purposes. It also essentially forbids open source software implementation (because such projects work publicly and necessarily start incomplete), and inhibits most proprietary software implementation (because implementors often have to work in stages too). Subsets whose value is proven can become standards themselves; XML, for example, was created as a subset of SGML.
If you can't implement a superset, there is no way for implementors to experiment with new capabilities that should eventually make it into the standard. Standards group should try to avoid standardizing things that have no field experience - how can you get that experience, except through supersets? A standard that can never have a superset implemented quickly ossifies, because there is no way to gain experience. The solution is to let implementors add capabilities (supersets) beyond the standard; the successful experiments should then be incorporated into future versions of the standard.

Indeed, malevolent organizations can turn a statement requiring only "exact" implementation into a trap. An organization granting patent rights - but only to "exact" implementation - then becomes the only organization that can make improvements on the standard, and can entrap everyone else who uses the standard. The result would be that you have to use their proprietary version of the standard, or use a completely different incompatible specification that they control. That is not where users want to go.

But if a supplier can implement subsets and supersets, and there is no mechanism for addressing them, there are other risks. There's the risk that the products won't be interoperable, for one thing. Another risk is that users will become unintentionally locked into using a particular supplier, because they inadvertantly depend on supplier-unique extensions. This is the basis of the "embrace, enhance, and extinguish" attack on standards - supplier exploit the need to permit supersets, by making naive users unknowingly depend on their supplier-unique extensions. Users need to be able to find out if the product they're getting only implements a subset (as opposed to the whole standard), and be able to easily avoid non-standard extensions (which means they need to be able to know what is a non-standard extensions in the first place).

At first, this appears to be a conflict between implementors' needs (to allow extensions and subsets) and users' needs (who need to know what they're getting). But these are not really in conflict. There are lots of ways to address the needs of both implementors and users. Here are a few:

For subsets, a standards body might say that (1) an implementor of only a subset cannot say that they implement the standard, or (2) such an implementor can only say “implements a subset of standard X” instead of “implements standard X”, or (3) include definitions of groups of functionality or define certification requirements that define a particular set of useful functionality.
For supersets, implementors who claim to implement a standard can be required to document their extensions, and/or define a separate namespace that identifies non-standard extensions.

In practice, useful standards are updated, based on experience based on real implementations that create subsets and supersets... but standards bodies often discuss how handle them in a controlled way.

OpenFormula Solutions: Groups (Small, Medium, Large), Test Cases, and Supplier-unique Names

So an open standard must allow for subsets and supersets, so that it can be tailored for any user's needs. Yet if every application implemented their own set of functions, you could end up in a situation where documents could never be exchanged. Formulas don't work like many other office suite capabilities; "graceful degradation" is often fine when you're talking about minor formatting tweaks, but formulas either recompute correctly or they don't. How can we resolve this?

For OpenFormula, the "Group" system, the built-in test cases, and the supplier-unique function naming mechanism are the primary answers to resolving both user and implementor needs.

OpenFormula predefines a number of different "groups" of capabilities. Applications are free to implement subsets and supersets, but in most cases we expect at least some of the groups to be requested by users. That way, applications can quickly express what they support, and users can quickly express what they want. Users could even define their own groups, if they wanted to, but we expect most will be happy to use the predefined sets.

The most important predefined groups are small, medium, and large:

The small group is actually very capable - it includes a number of functions for trigonometry, database, finance, and statistics (over 100 in all). The vast majority of spreadsheet documents are ably handled by applications that implement the "small" group. We know of at least one PDA application with this level of capability, and wikiCalc added the functions in the small group specifically to meet the set defined by OpenFormula.
The medium group includes all the capabilities of the small group, and adds about 100 more functions.
The large group includes all the capabilities of the medium group, adding around 130 more functions, as well as capabilities such as complex numbers.

Applications are free to implement one group plus additional functions, or even no groups, depending on what their users want. Implementing a larger group doesn't necessarily make an application "better" for all users; smaller sets are quite sufficient for many users, and they may prize other attributes more (such as small size, low price, having a web interface, and so on). But the grouping mechanism, supported by tools such as the test cases, makes it easy for users to determine if a particular application could meet their needs or not.

It's worth noting that the built-in test cases help here too. A supplier could claim to implement some function, but the supplier better have tried, because the specification's built-in test cases provide a first-cut check at them. Yes, a supplier could create functions that only give correct answers to the specific test cases provided, but that is not enough to actually meet the specification, and a supplier's reputation will not do well if such easily-detected subterfuge is tried.

Finally, the specification lets suppliers experiment by adding supplier-unique functions, but it does it by defining a naming convention so that such functions are clearly different from standard functions and from each other. The convention is disarmingly simple, and similar to Java's - prefix any supplier-unique function with a reversed DNS name. Thus ORG.OPENOFFICE.STYLE and COM.MICROSOFT.CUBEKPIMEMBER are supplier-unique function names. Since the naming convention itself is in the standard, application developers can confidently create new function names without worrying that they will interfere with another application's function names. Without a naming convention like this, suppliers would quickly create incompatible names, or be beholden to a single supplier who would be the only one that could create new functions. In the OpenFormula way, different suppliers can experiment with new functions, and if their experiments turn out to be useful, they can then be added to the standard. Standards should not standardize useless or problematic areas, yet if vendors can't experiment, there's no way to know if they will work - this mechanism resolves the issue.

History

2004-11-01: David A. Wheeler recommended that the Open Document's specification of formulas be enlarged
2005-01-14: TC agrees with value of formula specification, but rejects as an embedded project, saying instead that the formula specification should be a separate work
2005-02-26: Wheeler releases first draft of formula specification, as a separate work, begins informal discussions with others
2005-10-15: OpenFormula project formally established, with the goal to create a base document for formula specification that will be contributed to a standards body
2006-01-09: KOffice KSpread, a spreadsheet application, changes their application to comply with OpenFormula. KSpread modified their MOD and DCOUNTA functions, and added some missing functions (particularly ISERROR, ISERR, and ISNA), to comply with the specification as it existed at the time. This is an excellent indication that people are taking the specification seriously.
2006-02-06: OASIS OpenDocument technical committee (TC) establishes the formula subcommittee. This subcommittee adopts the OpenFormula project's document as a base document, which already covers over 100 functions (including database, financial, and other categories).

OpenFormula is an open standard

OpenFormula is an open standard. If you're not sure what an open standard is, take a look at Is OpenDocument an Open Standard? Yes!, which identifies the requirements for an open standard. Then let's go point by point, and you can see that OpenFormula is indeed an open standard:

Availability: Open Standards are available for all to read and implement. Yes. You can download the specification for free from OASIS. What's more, there are absolutely no known intellectual property issues that would even slightly inhibit implementation.
Maximize End-User Choice: Open Standards create a fair, competitive market for implementations of the standard. They do not lock the customer in to a particular vendor or group. Yes. There are already multiple implementations of OpenDocument, and of OpenFormula as currently drafted. OpenOffice.org/StarOffice and KOffice are office suite applications that support reading and writing OpenDocument, and are completely independent implementations. Gnumeric is developing an implementation as well. What's more you can tell that many different suppliers were involved in developing this specification.
No Royalty: Open Standards are free for all to implement, with no royalty or fee. Yes. There’s no royalty or fee to implement it.
No Discrimination: Open Standards and the organizations that administer them do not favor one implementor over another for any reason other than the technical standards compliance of a vendor’s implementation. Yes. No supplier controlled the development of the specification. This is important, because when a supplier controls the specification, they generally include all sorts of nonsense specifically to prevent or constrain use by others. If you want to be free to choose your supplier, you need to choose specifications that are developed by many suppliers.
Extension or Subset: Implementations of Open Standards may be extended, or offered in subset form. However, certification organizations may decline to certify subset implementations, and may place requirements upon extensions (see Predatory Practices). Yes, supersets and subsets are allowed. This is important; implementors need to be allowed to experiment with subsets and supersets for various needs, so that the successful experiments can be incorporated into future versions of the standard. Yet users need to be able to find out if the product they're getting only implements a subset, and be able to easily avoid non-standard extensions. For OpenFormula, the "Group" system described above and the function naming extension mechanism lets suppliers experiment by adding vendor-unique functions, and if they turn out to be useful, they can then be added to the standard. Standards should not standardize useless or problematic areas, yet if vendors can't experiment, there's no way to know if they will work - this mechanism resolves the issue.
Predatory Practices: Open Standards may employ license terms that protect against subversion of the standard by embrace-and-extend tactics. The licenses attached to the standard may require the publication of reference information for extensions, and a license for all others to create, distribute, and sell software that is compatible with the extensions. An Open Standard may not otherwise prohibit extensions. Yes. The OpenFormula developers, like the OpenDocument developers, chose to not embed any protective measures against subversion by external parties. However, all the members of the technical committee that created the standard were required to grant royalty-free licenses to implement it. This prevented anyone from quietly inserting a requirement in the standard and after ratification announce that they would extort payments from implementors. Thus, this requirement is easily met.
One World: Same standard for the same capability, world-wide. Yes. It's designed to be used worldwide. For example, it supports named expressions with names in the entire ISO 10646 (Unicode) set. We have worldwide participation to help ensure this; participants hail from the U.S., U.K., Germany, and China, among other countries.
On-going Support: Standards are supported until user interest ceases rather than when implementer interest declines. Yes. The standard is supported by OASIS, a standards body, rather than any one particular supplier. Thus, as long as there are users who wish to support the standard, they can work with OASIS to continue its support. There’s absolutely no indication that this is a problem anyway; there is a massive amount of interest in OpenDocument and OpenFormula.
No or nominal cost for specification. Yes. OASIS posts the specification at no charge on their website, clearly meeting this requirement.

When people exchange simple text files, or PNG graphics, or JPEG pictures, people don't assume that only one program can use the result. Why? Because these (and many other formats) are open standards. There are many programs that can handle these formats, freeing users to choose the best application for their circumstances. That is what we plan for spreadsheet formulas as well.

For more information

This is a Wiki page, and is constantly updated for those outside of the OpenFormula subcommittee who want a quick, informal summary. It is not formally vetted, but we do actively try to keep it accurate; please let us know if there's some omitted information that needs to be here, or if there's a correction that needs to be made.

See the OpenDocument formula page for the statement of purpose (charter), current documents including the current draft, mailing list archive, and other official information about OpenFormula. If you're looking to understand OpenFormula in more detail, that should be your first stop.

Some additional OpenFormula status information is here:

Some commentary about MathML, the format for non-recalculated mathematical expressions used in OpenDocument and everywhere else:

Other commentary:

Game of Zendo, which discusses the dangerous problem of overconstraining a standard, using the "Art Page Border" as an example. This is an inevitable result when a specification-writing group is controlled by a single organization

The OpenDocument Fellowship has more information about OpenDocument in general. The ODF (OpenDocument) Alliance provides information on the benefits and opportunities of the OpenDocument Format and now has a long list of members. Sam Hiser's "What Is OpenDocument" explains a little about OpenDocument. OpenFormula, like OpenDocument, is a choice that lets you choose.

If you have questions not answered otherwise, or are interested in participating, you may contact the SC chair, David A. Wheeler, at dwheeler (at) dwheeler, dot com. Include "xyzzy" in the subject line, so that he will know you're not sending him spam.