Standards do matter.

Standards help people and products work together by defining common ways to do things. These "common ways" can be at any of several different levels:

  • Using a common character-set standard helps ensure that the bits stored to represent a particular character, such as "!", will be interpreted as the intended character when read back later.

  • Using a common document format helps ensure that the content, formatting and metadata contained in a document (such as a word-processing document or spreadsheet), will be interpreted and saved consistently no matter which application is used to read or write the document.

  • As a "last resort" (too often mistaken for "best practice"), using a single common application (usually a single authorized version of a single application) gives a "brute-force" assurance that all users will be able to work with the document consistently.

Saving a document as a text file using a specific character set (such as ISO-8859-1 or UTF-8) essentially guarantees that any software that can read text files will technically be able to read that data. On the other hand, unless the document uses a native-text format such as HTML, all formatting and metadata associated with the document will need to be recreated each time the document is read. This is one of the major reasons why such "structured" text formats are popular (for Web pages, email, and many other uses).

At the other extreme, mandating that all authorized users of a document use a single version of a single (usually commercial) application essentially guarantees that (barring defects in the software) any document saved by one user can be read by any of the others – at the time the document was saved. Applications not based on open standards have a historical tendency over time to modify their "current" format and drop support for older formats; thus, just because you saved, for example, auditing data in "Acme Spreadsheet 2007" is not necessarily a guarantee that you'll be able to work with it correctly in "Acme Spreadsheet 2020" – or, for that matter, any other software at any time going forward. Your auditing and regulatory-compliance teams may have some nasty surprises waiting for them.

The obvious middle ground, and what we have found to generally be the lowest-risk approach, is to use document formats that are:

  • defined and maintained by a neutral organization (such as OASIS and the ISO) not beholden to any specific vendor;

  • fully supported by multiple implementations not relying on a single vendor or organization.

The first condition makes it quite likely that, even if all existing implementations of a "standard" disappear (perhaps they were all commercial implementations, and the companies were bought by a larger company that then "broke" the old standard by "replacing" it with a new, incompatible one), the "old," open standard still is specific enough that a team of competent software developers can re-implement support for the format working entirely from the pre-existing specification. That's how things should work.

The second condition guarantees that "things" actually do work "that way." With multiple applications that have each been shown to be fully interoperable with others, there is both a solid basis for expecting a team to be able to implement support solely from the spec, and an expectation (proportional to the number of implementations) that the need for such a "bare-metal" approach will be unnecessary. Hence, risk is significantly lower than with the single application that could conceivably no longer be available at an uncertain future time, and usability tends to be higher – as implementations competitively emphasize improvements in usability and functionality.