But is OpenDocument really an open standard, or not?
For example, can anyone implement it?
Was its development process completely controlled by a single party
(which would not be open), or is there evidence that
it’s a consensus result by many?
It’s generally accepted that OpenDocument is an open standard, but recently
I’ve been told that some people are claiming otherwise.
So let’s figure out what the criteria are for an open standard, and then see
if OpenDocument meets those criteria.

What’s an Open Standard?

There’s no single definition of the term “open standard”.
That’s true for most words and phrases, actually.
But lots of documents hint at what it means, for example:

Europe’s “Valoris report”
defines an open standard this way:
“The minimum requirements for an open standard are that the document format is completely described in publicly accessible documents, that this description may be distributed freely and that the document format may be implemented in programs without restrictions, royalty-free, and with no legal bindings.”

In
an
earlier paper I noted that,
“When you think ‘open’, think ‘open competition’ or ‘open market.’ An open standard should allow competition based on merit, instead of limiting customers’ suppliers to one particular supplier or a subset of suppliers based on their business model, development model, licensing model, and so on. You should be able to replace one product that does the same function for another, as long as they meet the same open standard, and achieve at least the same basic function provided by the standard (though some may perform better or have additional features -- think of plug-replaceable components).”

Let’s first look at the two definitions of
“open standard” that seem to be the most widely used.
The first is by Bruce Perens; the second is by
Ken Krechmer (Fellow of the International Center for Standards Research).
These two are so widely used that when I did a Google search on
“open standards” these were the second and fourth results
respectively (the
first and third were OASIS and the W3C, two standards bodies that
create open standards).
We’ll then look at the European Commission’s definition
of open standards, which is a formally approved definition of
the term (and one that European governments use).

Then, after we’ve looked at these three definitions,
we’ll create a merged definition that includes all of their
requirements (from all three sources).
That way, if the specification meets this merged set of requirements, we
can be very confident that we have an open standard; such a specification
would meet all three definitions.

Perens

A very popular definition of the term “open standards” -- according
to Google the most popular -- is
Bruce Perens’ “Open Standards: Principles and Practice”.
You’re best off reading the actual paper for its full content, of course.
Let me summarize it by quoting its list of principles that it states
a specification must meet to be an open standard:

Availability: Open Standards are available for all to read and implement.

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.

No Royalty: Open Standards are free for all to implement, with no royalty or fee. Certification of compliance by the standards organization may involve a fee.

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. Certification organizations must provide a path for low and zero-cost implementations to be validated, but may also provide enhanced certification services.

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).

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.

Krechmer

Another popular definition is the set of
requirements for open standards created by
Ken Krechmer, Fellow of the International Center for Standards Research
(University of Colorado).
He’s published several versions; here I’ll summarize the
February 7, 2005 version of “Open Standards Requirements”.
He looked at standards from the viewpoint of
recognized standards-setting organizations, implementors, and users,
and tried to find some middle ground merging their desires.
He claims that an open standard must meet the following requirements:

Open Meeting - all may participate in the standards development process.

Consensus - all interests are discussed and agreement found, no domination.

Due Process - balloting and an appeals process may be used to find resolution.

Open Intellectual Property Rights (IPR) - how holders of IPR related to the standard make available their IPR.

One World - same standard for the same capability, world-wide.

Open Change - all changes are presented and agreed in a forum supporting the five requirements above.

Open Documents - committee drafts and completed standards documents are easily available for implementation and use.

Open Interface - supports proprietary advantage (implementation); each interface is not hidden or controlled (implementation); each interface of the implementation supports migration (use).

On-going Support - standards are supported until user interest ceases rather than when implementer interest declines.

Clearly, these definitions have a lot in common.
Ken Krechmer wrote his paper after Perens, and compares his list to Perens’.
Krechmer maps each of Perens’ 6 points to his own list of ten
as follows:

Perens

Krechmer

Availability

Open Documents

Maximum end-user choice

Open Access

No royalty

Open IPR

No discrimination

Open Meeting, Consensus and Due Process

Ability to create extension or subset

Open Interface

Ability to prevent predatory practices

Open Change

Krechmer in particular notes that Perens doesn’t include any requirement
about wanting “One World” or ongoing support.
Rick Jelliffe claims that Krechmer’s “open interface” doesn’t map
to Perens’ “ability to create extension or subset”, but I think it does... and
so does Krechmer!

However, Krechmer’s list has very serious failure.
Krechmer’s list omits one of the most important factors
of all: the ability of anyone to implement the standard.
The whole point of open standards is to allow anyone to implement
the standard, and to allow any user to have unfettered selection and
switching between many implementations.
Krechmer’s list notes the importance of
patents and copyright (“IPR”),
but his definition allows “open standards”
to forbid competitors from implementing the standard.
This is a fundamental flaw in his definition;
defining “open standard” as “a standard
that some competitors are
forbidden from implementing” is nonsense, and
conflicts with most other sources.
Perens’ definition explicitly forbids this,
as does the
Valoris report,
which required as a minimum that the format
“may be implemented in programs without restrictions, royalty-free, and with no legal bindings.”
It also conflicts with the European Commission’s definition of open
standards, which also required royalty-free use (we’ll get
to that definition in a moment).

The most economically obvious example of this conflict is
open source software (OSS).
Today, in a vast number of software markets, the dominant or #2 program
is OSS, including web servers, web browsers, mail servers, and DNS servers.
Yet OSS are legally forbidden from using royalty-bearing patented works,
so obviously specifications requiring royalty-bearing patents or other
legal restrictions preventing OSS or proprietary implementations
are obviously not open standards.
A standard cannot be “open” if it is illegal for the
dominant or #2 supplier to implement it.

This conflict between patents and open standards
only makes sense, when you think about it.
The purpose of patents are to prevent
competition, while the purpose of open standards is to enable
open competition.
The purposes of patents and open standards are fundamentally in conflict.
Open standards are not the same as open source software;
you can choose open standards and use only proprietary software.
But selecting open standards lets you choose between implementations,
including OSS, and lets you switch to another implementation later.

European Commission

The European Commission (EC) has defined the term
“open standards” as part of the final version 1.0 of the
European Interoperability Framework.
Newsforge
ran a short article about it.
The EC declared that “to attain interoperability in the context of
pan-European eGovernment services, guidance needs to focus on
open standards” -- in other words, the EC views
the use of open standards as a significant policy issue.
They define the following as “the minimal characteristics that a
specification and its attendant documents must have in order
to be considered an open standard”, and I quote them here:

The standard is adopted and will be maintained by a not-for-profit organisation, and its ongoing development occurs on the basis of an open decision-making procedure available to all interested parties (consensus or majority decision etc.).

The standard has been published and the standard specification document is available either freely or at a nominal charge. It must be permissible to all to copy, distribute and use it for no fee or at a nominal fee.

The intellectual property -- i.e. patents possibly present -- of (parts of) the standard is made irrevocably available on a royalty-free basis.

There are no constraints on the re-use of the standard.

The document also suggests that open source software (OSS) compliments
open standards.
It says: “Open Source Software (OSS) tends to use
and help define open standards and publicly
available specifications.
OSS products are, by their nature, publicly available specifications,
and the availability of their source code promotes open,
democratic debate around the specifications, making them both more
robust and interoperable.
As such, OSS corresponds to the objectives of this Framework
and should be assessed and considered favourably alongside proprietary
alternatives.”
Both the definition and explanatory text make it clear that
the intent was that any open standard must be implementable by both
OSS and proprietary programs,
especially given the requirements for
royalty-free use and lack of constraints on re-use.

Merging the definitions

So let’s use a definition of “open standard” merging
the best of each, and so that a specification would meet all
of these definitions to qualify.
Comparing Krechmer’s list to Perens’,
Perens’ list is shorter, clearer, and doesn’t have the
serious defect
of forbidding open competition.
We’ll then add the two points of “One World” and “Ongoing support”
stated by Krechmer as important issues.

Most of the EC’s requirements also map well to Perens’, except that
the requirement for a free or nominal-cost specification isn’t explicit:

Perens

European Commission

No discrimination (though doesn’t explicitly require not-for-profit)

The standard is adopted and will be maintained by a not-for-profit organisation, and its ongoing development occurs on the basis of an open decision-making procedure available to all interested parties (consensus or majority decision etc.).

(No match)

The standard has been published and the standard specification document is available either freely or at a nominal charge. It must be permissible to all to copy, distribute and use it for no fee or at a nominal fee.

No Royalty

The intellectual property -- i.e. patents possibly present -- of (parts of) the standard is made irrevocably available on a royalty-free basis.

Availability

There are no constraints on the re-use of the standard.

So again, let’s add “No or nominal cost for specification”.
Perens doesn’t explicitly say that a standards maintainer has to be
not-for-profit, but he does require no discrimination, with
essentially the same notion; we’ll add that as an implicit requirement
to no discrimination.

The result is a slightly stricter definition of “open standard”
than any of the three definitions by themselves.
Thus, so if any specification meets this merged definition,
then it’s clearly an open standard.

Definition of “Open Standard”

Here’s a definition that merges the points of these various
widely-cited documents:

An open standard is a specification that enables users to freely
choose and switch between suppliers, creating a free and open competition
between suppliers. To accomplish this, an open
standard must have the following properties:

Availability: Open Standards are available for all to read and implement.

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.

No Royalty: Open Standards are irrevocably free for all to implement,
with no royalty or fee {or other legal tricks to inhibit
implementation}. Certification of compliance by the standards organization
may involve a fee (as long as it’s not required for implementation).

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. Certification organizations must provide a path for
low and zero-cost implementations to be validated, but may also provide
enhanced certification services.
The standard is adopted and maintained by
a not-for-profit organisation, with open meetings
(all interested parties may participate in the standards development
and maintenance process),
consensus (all interests are discussed and agreement found, with
no domination by any party), and
an open decision-making process with
due process (balloting and an appeals process may be used to find resolution).

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).
I would add that users definitely should be told when an implementation
only implements a subset, and what the nonstandard extensions of an
implementation are, since these can cause interoperability problems.
But it is critical that implementations be allowed to implement
subsets or supersets of standards, because without this permission,
standards cannot respond to changing
conditions, and many open source software licenses are incompatible
with software that cannot be modified.
In practice, useful standards are updated, based on experience based on
real implementations that create subsets and supersets
(XML is a subset of SGML, for example, and all useful updated standards
are based on extensions created by implementors).
There are lots of ways to address the needs of both users (who need to
know about the subsets and supersets) and implementors (who need to
create them).
For example, a standards body
might say that an implementor of only a subset would have to say
“implements a subset of standard X” instead of
“implements standard X”,
and they can require implementors to document their extensions.
The biggest danger here are
intellectual rights (patent) agreements that grant
patent rights to implementors “only to implement this standard, exactly”.
These agreements are often a trap; the organization granting
the intellectual rights then becomes the only organization that
can make improvements on the standard, and can entrap everyone else who
uses the standard.

Protection from 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.

One World: The same standard should be applicable for the same
capability, world-wide. It must not be devised as a “barrier to entry”
by those from other regions.

On-going Support: The standard is supportable until user interest
ceases rather than when implementer interest declines.

No or nominal cost for specification.
(This may soon become a requirement for no-cost specifications that
can be copied further. Fees innately discriminate against many
users and implementors, particularly in the third world;
with the rise of the Internet fees have become
a completely unnecessary discrimination.)

Is OpenDocument an Open Standard?

So, is OpenDocument an open standard?
Let’s walk through the list of requirements.

Availability: Open Standards are available for all to read and implement.
This one is easy. You can
download
the OpenDocument specification for free from OASIS.
Absolutely anyone can implement OpenDocument; if you look at the IPR
statements, they clearly state that absolutely anyone can implement it,
and there are no limits at all.

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.
The fundamental question here is, is this designed to permit
multiple interoperable implementations?
The most obvious way to determine if this is true is to
determine if there multiple implementations available on
multiple different platforms.
The answer to the latter question is emphatically yes;
there are already multiple implementations of OpenDocument, with many
more in progress.
OpenOffice.org/StarOffice and KOffice are office suite applications
that support reading and writing OpenDocument, and are completely independent
implementations.
There are also many specialized products that implement
their relevant portions, for example,
AbiWord and Writely are word processors that can read and write
the word processing portion of OpenDocument;
Gnumeric is a spreadsheet application whose implementation of the
spreadsheet portion of OpenDocument is in development.
(Wikipedia
has a list of applications supporting OpenDocument.)
You can also look at other evidence to help gain more confidence in this:

Were multiple implementors involved in its specification to
help prevent lock-in? Yes; Sun, KDE, Corel (vendor of Word Perfect), IBM (vendor of IBM Workplace and Lotus SmartSuite), and others.
I’ll discuss more about the participants later, but that’s enough to
prove the point.

Does the specification maximally reuse other open standards
(otherwise it may end up creating unnecessary dependencies on
nonstandard components)?
Yes; other standards OpenDocument reuses include
SVG, SMIL, XSL, XForms, MathML, XLink and the Dublin Core Meta Initiative.

No Royalty: Open Standards are free for all to implement, with no royalty or fee. Certification of compliance by the standards organization may involve a fee.
There’s no royalty or fee to implement OpenDocument, so this is met 100%.

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. Certification organizations must provide a path for low and zero-cost implementations to be validated, but may also provide enhanced certification services.
I believe this one is also a clear “yes”, however, it’s
more difficult
to measure this than most other points.
We’ll explore this one further in a moment, to see why I believe this
is “yes” as well.

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).
Implementors may implement subsets or supersets of OpenDocument, without
any special requirements, so this is clearly met too.

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.
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.
The OpenDocument specification was specifically designed to be used
worldwide, and not limited to any region.
It includes capabilities to support
arbitrary locales and arbitrary languages, and in fact was developed by
representatives from many different countries.
For example, OpenDocument supports Unicode/ISO 10646 characters
(whose purpose is to support the characters of all languages),
Ruby text (important in supporting
some Asian languages), and text written from
right to left (important in supporting Arabic and Hebrew).
Reusing many open standards helps this, too.
Also, by working to avoid patented techniques, the developers
of OpenDocument made it more likely that
everyone in the world could use the standard (otherwise the
standard might only be usable in countries
that don’t tolerate software patents).
We’ll discuss more about patents in a moment, because patents fundamentally
conflict with the previously-noted requirement for no discrimination.

On-going Support: Standards are supported until user interest ceases rather than when implementer interest declines.
The OpenDocument standard is supported by OASIS, a standards body, rather
than any one particular vendor. 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.

No or nominal cost for specification.
OASIS posts the specification at no charge on their website, clearly
meeting this requirement.

In short, we get “yes” answers for all of these points.
All but one of them are trivially answered as “yes”.
One point, however, is harder to measure - the “No discrimination” point.
This isn’t because there’s a problem with OpenDocument on this point;
the challenge is that “no discrimination” is harder to measure for
any standard.
So let’s drill into the “no discrimination” point to see if OpenDocument
meets this requirement -- if it does, then it is
clearly and unambiguously an open standard.

No Discrimination

Perens requires that open standards have “no discrimination”,
that is, that
“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. Certification organizations must provide a path for low and zero-cost implementations to be validated, but may also provide enhanced certification services.”
There’s no certification issue, so we don’t have to deal with that.

The European Commission had an explicit requirement that the administering
organization must be a not-for-profit, which is easy to show in this case:
OASIS is a non-profit!
But there’s more to preventing discrimination than simply creating
a specification via a not-for-profit organization.

What about the whole first part of Perens’ requirements?

Krechmer maps this single requirement to three requirements:

Open Meeting - all may participate in the standards development process.

Consensus - all interests are discussed and agreement found, no domination.

Due Process - balloting and an appeals process may be used to find resolution.

We can deal with “due process” easily enough.
OpenDocument was developed in OASIS, which has clear balloting
and appeals process, so that’s clearly met.

The “open meeting” requirement that “all may participate in
the standards development” is a little more interesting, but it seems to be
met, too:

Note that this does not mean that everyone has to
participate -- sometimes organizations who should participate
don’t do so.
In 2004, Europe formally asked in very strong language that
Microsoft participate in OpenDocument development;
while it was an observer on the technical committee for a long while,
and is part of OASIS, Microsoft
never chose to become actively involved with this standard.
The definition doesn’t require that all parties get involved, merely that
they are given the opportunity.

Like many old standards bodies, OASIS typically requires payments from
organizations interested in developing the standard.
The problem is that some people who have a legitimate interest in a
standard may not be part of an organization willing to make these payments.
If there were no recourse, this would cause the OASIS group to fail to
meet this requirement.
However, OASIS has worked hard to make sure that there are mechanisms to
allow such organizations to be represented through non-profit organizations;
as a result, this requirement is met too.

But that leaves us a mixture of requirements:
“do not favor one implementor over another,”
and “Consensus - all interests are discussed and agreement found,
no domination.”
If there’s a single vendor who controls all real decisions, then
clearly we have a problem.
Thankfully, I think we have good evidence that there wasn’t
domination in the case of OpenDocument.
If there was no domination, then OpenDocument is an open standard
without question.
So let’s look at the evidence, shall we?

No Domination

How can you tell if there’s domination by a vendor in a
standards body?
There are several signs that if present give strong evidence of vendor
domination. For example, vendor domination
is very likely if the rules or processes
controlling the standards’ development
strongly limit the range of technical changes,
forbid changes that would affect only one particular vendor,
or give one particular vendor a sole veto power.
The OpenDocument development process had no such problem; the rules
in placed allowed anyone to propose changes, even if they forced any or all
vendors to change their implementations.
But there can be unstated rules that
effectively limit others’ participation, even if there’s no
obvious written rule enforcing it.

You could also check to see if other implementors involved in the
process are complaining about the process locking them out,
though that isn’t always a valid indicator.
In this case, there seems to be no such problem.
IBM’s Bob Sutor reports that,
“IBM and Sun are working together happily and effectively on the
OpenDocument Format. I think we’ve made a terrific amount of progress
in the last year and that’s because of the broad cooperation by the community.”
In fact,
Andy Updegrove reports that it’s central to Sun and IBM’s
strategy
“to have many applications that support ODF.
Remember - it’s a good thing, and not a bad thing,
for there to be many different implementations -
both proprietary and open source - so long as they all support ODF.
That’s one of the big reasons why ODF matters - to have
multiple choices (and not just one - Office), each
with its own independently valuable features.”

What we need is direct evidence that there was no domination in
the development of OpenDocument.

One easy way is to see if there’s only one party making essentially
all the changes, or if in fact others are making proposals that cause
technical changes to the specification that affect implementors.
Particularly telling are changes that cause all implementors
to make significant changes to their products.
If all implementors are changing their product
to meet the specification, then clearly no one implementor is
calling all the shots.

So let’s start by looking at who proposed the original base
document, and who proposed changes that were accepted.
The original base document was contributed by Sun and the OpenOffice.org
group, so clearly they were involved.
Their base document was based on actual experience of using the format
as their primary format, which is absolutely perfect... here
we have a base document based on actual experience.

But did Sun and OpenOffice.org control everything,
or were changes made to the specification by others?
Sun and OpenOffice.org did contribute the original document, as
well as some later changes, but I asked a number of TC members
and they easily showed that
many other organizations made substantive changes to the specification.
In some cases it’s hard to tell who was the proposer or
proponent, but there’s more than enough evidence to show that
many others were involved.
Even in the cases were I have not identified the
proposer or proponent, it’s obvious that changes were
made that caused implementors to change their implementations.

Below is a long list of examples of the many changes made to the
original base document contributed by Sun/OpenOffice.org
on the way to its becoming OpenDocument.
You don’t need to read this information in detail;
the very point is that it’s
a long set. Anyway, here’s a table showing
some of the changes:

Change

Proposer/Proponent

Modified to allow multiple metadata fields.
The original specification did not allow list, e.g.,
there could only be one author for a document.
At the first face to face meeting,
strongly urged that this
be changed, and the first OASIS draft included this change.

Patrick Durusau (Society of Biblical Literature)

Added SVG to support vector graphics using an already-existing standard,
and worked to resolve issues involving SVG use.

Paul Langille (Corel)

Set of requirements for business charts.

Paul Langille (Corel)

Embedded support for a subset of the XForms standard was added.
XForms add the capabilities typically desired for custom schemas,
which were requested by Europe,
but without the horrific interoperability problems that uncontrolled
custom schemas can cause.
Gary Edwards reports, “It turns out that XForms is an elegant
solution to the ‘custom defined schema’ problem,
able to address both the “collaborate with yourself” ... model, and,
the infinitely more important shared business process schema model.
The binding model in XForms is extraordinary...
we were quite unaware of this potential [at first]...
[but once we began to understand it] oh what a treasure we found.”
In particular, its approach manages to be portable among many different
systems, and not tied to any one.
XForms is also a standard in its own right,
which is a good thing; it’s generally
a very good sign if a standard tries to reuse existing standards instead of
recreating its own incompatible components.

Numbered paragraphs/headings without number
and the text:numbered-paragraph element (an alternative to <text:list>)
added more flexibility, for example,
numbered-paragraph is better suited for independently numbered paragraphs.

David Faure (KDE)

Table templates were added; this makes it easier to control
and modify the appearance of tables.

David Faure (KDE)

A “sequence of page styles” and support for copy-frames
was added, a new wrapping mode was added for graphics, and a
desktop publishing mode was added (using the draw:page element).
All of this improved support for desktop-publishing-based layout.

David Faure (KDE)

Hyphenation became a boolean character property, for more control
over hyphenation.

The original specification’s ordered-list and unordered-lists were
replaced by a single list element, with ordered/unordered information
conveyed entirely through styles. This made the specification simpler,
and also made it easier to switch a list from one form to another.

-

A per-paragraph list wrapper element

Phil Boutros (Stellent)

Support for the SMIL standard was added as well, even though Sun and
OpenOffice.org’s implementations didn’t support it.
These aren’t the sort of things you add if you just wanted a rubber stamp.

-

OpenDocument changed the older OpenOffice.org format in how style:properties
were handled.
Originally there was a single properties element,
which contained a mix of all style properties.
OpenDocument has properties per style family (paragraph-properties, etc.),
which allows for a cleaner separation of properties and better handles
dependencies within style families

Proposed by Phil Boutros (Stellent)

A style:display-name attribute was added and a rule that
style names had to be XML tokens was added.

The structure of documents was changed
so that the type of document (word processing, spreadsheet, etc.) could
be trivially determined without looking at the filename ending.
This wasn’t in the original base document, and required a structural
change, but it was added.

Phil (Stellent) recommended this.

The original format had only footnotes and endnotes; this was
generalized to notes with a general note-class value, which
makes it much easier to support additional type of notes.

-

The original format had several different frame-like elements
(e.g. images or text-boxes) that shared certain attributes.
This was generalized to support a single
draw:frame element which would then contain the actual frame content
(textbox, image, etc.) plus an optional replacement image.
This eliminated unnecessary complexity (by eliminating duplication)
and would make it much simpler to implement consistent
user interfaces.

-

Frames were changed so that they could
list a sequence of different format options
(e.g., a vector drawing and a bitmapped drawing)
so the viewer/processor can choose the ‘best’ format that it can support.

-

OpenDocument formulas now use a
“namespace prefix” to identify the formula language used.
This makes it much less likely that the wrong meaning would be
applied to a given formula.

-

Lots of other small changes.
The style:default-outline-level attribute for heading styles was added,
making it easier for users to use templates.
The original style:properties was refined into
style:paragraph-properties, style:text-properties, and so on.
Also, page-master was renamed to page-layout for clarity
(and to avoid mixing with master-page).

-
(David Faure thinks that he commented that the
name page-master was confusing, and that Michael Brauer (Sun) then
offered to rename it.)

I am sure that there are many other changes not listed above,
but I think I have enough listed here to make the point: this
specification was a work of many, not a specification controlled
by any one vendor.

Various other changes were made to the document to improve it
as a document, too.
A big change was that the schema definition language changed to
RELAX-NG, a standard specification language
which is more powerful than the older DTD language yet is
very easy to understand.
One advantage of this additional power is that automated validation tests of
OpenDocument files using the specification can be
much more rigorous.
It’s also more likely to result in interoperability; RELAX-NG can be
much more specific about the permitted values in constructs,
eliminating many potential misunderstandings by implementors.

Clearly, there were many changes made after the initial submission
of the base document, due to interaction of all the members.
The first draft of the original specification was about 108 pages and
its schema was 69K.
The final version is about 723 pages and its schema is 529K.
This growth to a full standard happened through careful review by a large
number of experts from different backgrounds.

A risk of making many changes to a specification is that the result
may be too hard to implement.
The OpenDocument process avoided this problem by having implementors actually
implement the changes as they went, and in particular
used multiple open source reference implementations as proving grounds.
One participant commented,
“it was clear that the proprietary [vendors] had gone into
the source code or at the least downloaded [OpenOffice.org],
and were studying the implementation and methods.
... Explanations, rationale, and techniques were exchanged in ways
that would be impossible if not for a common reference application
and code base everyone had access to.”

Another Tack: Look at the Participants

I stated above that the most important measure was to see if there
were changes made from many different sources, and I think I’ve
proven that very conclusively.
But for some additional evidence, let’s look at the participants themselves --
do we see the multiple implementors, multiple users,
and diversity of views that we’d expect to see from
a standard not dominated by any one organization?

First, a quick background.
Version 1.0 of the OpenDocument specification was
developed after lengthy development and discussion by multiple
organizations.
The first official OASIS meeting to discuss the standard
was 2002-12-16; OASIS approved OpenDocument as an OASIS standard
on 2005-05-01. This is about two and a half years of hard work;
it’s not easy to create a good specification.

The standardization process included the developers of many
office suites or related document systems, including (in alphabetical order):

Adobe (Framemaker, Distiller)

Arbortext (Arbortext Enterprise Publishing System)

Corel (WordPerfect)

IBM (Lotus 1-2-3, Workplace)

KDE (KOffice)

SpeedLegal (SmartPrecedent enterprise document assembly system); both product and company later changed names to Exari.

Sun Microsystems / OpenOffice.org (StarOffice/OpenOffice.org)

That’s a lot of implementors, some of whom are direct competitors,
and they represent a very broad range of concerns.
That’s a very good sign, when competing implementors work together on
a standard.

Another good sign is that there were users with specific issues
who were involved:

Boeing (complex large documents)

CSW Informatics

Drake Certivo

Intel (complex large documents; they are developing sample documents as a test suite)

National Archives of Australia (retrieve documents long after development)

New York State Office of the Attorney General (complex large documents retrieved long after development)

My personal favorite is the “Society of Biblical Literature”,
because they’re so unexpected --
I would never have thought to invite them!
Yet this group worries about dealing with
large multilingual documents in any living language as well as many
long-dead ones, and they worry about long-term retrieval
issues in terms of millenia.
The National Archives of Australia was represented, too.
If their needs are met for
internationalization and long-term retrieval, then
my needs will be met too.

Another way to show that they really had diversity is to see the
different goals of different groups all getting met.
Michael Brauer, chair, insists that the only objective of the
group was to support “Desktop Office Suite work”.
Others, such as Gary Edwards, believe OpenDocument really covers
three areas:

Gary Edwards has claimed that Boeing was actually primarily interested
in the second area (SOAs), for example.
Interestingly enough, there’s no need to declare which set of
goals is “right”.
Different organizations joined the group because they had different
goals, unsurprisingly, yet in the end all believed their (different)
goals had been achieved. That is very good news!
A standard that can meet the different goals of different organizations
tends to be a good standard as long as it’s implementable... and since
it’s been implemented, there’s no question there.

Also, the fact that Boeing wanted the specification to be so
good that it could be a “universal transformation layer”
is excellent
evidence of OpenDocument’s capabilities.
To fulfill this role, OpenDocument has to be so expressive that it’s able
to capture the information from many different document formats,
not just Microsoft Office or any other single format.
The result is a more general and flexible standard.

Although it’s not part of the definition of
“open standard” I can’t help but be impressed by the expertise of
many of the participants.
Tom Magliery (Corel/XMetal) was on the original W3C XML 1.0 working group
(as well as the original NCSA Mosaic browser team).
Phil Boutros (Stellant) is an expert on Microsoft’s file formats.
Paul Grosso (founder, ArborText) was chairman of the XSL:FO effort.
Doug Alberg (Boeing) well-understood the needs for enterprise publication
and content management software systems.
Patrick Durusau is a well-known SGML expert.
And so on.
This is why it’s a good idea to create standards through an
open process -- by
gathering the experts together, in a way that lets them truly
fix problems they find, a group of experts can develop a very good result.

Digital Standards Organization (Digistan.org)

Since this original document was developed, the
Digital Standards Organization
(Digistan.org) has
stood up and developed a much simpler definition for
open standard
(aka "free and open standard"):
"a published specification that is immune to vendor capture
at all stages in its life-cycle".
More specifically, they define an open standard as one meeting the
following criteria:

"The standard is adopted and will be maintained by a not-for-profit organization, and its ongoing development occurs on the basis of an open decision-making procedure available to all interested parties.

The standard has been published and the standard specification document is available freely. It must be permissible to all to copy, distribute, and use it freely.

The patents possibly present on (parts of) the standard are made irrevocably available on a royalty-free basis.

There are no constraints on the re-use of the standard.

A key defining property is that an open standard is immune to vendor capture at all stages in its life-cycle. Immunity from vendor capture makes it possible to improve upon, trust, and extend an open standard over time."

Note that this specifically makes clear that it must be available at
no cost, and that it must implementable irrevocably on a royalty-free basis.
Although I didn't specifically analyze OpenDocument against this particular
definition, it should be clear that OpenDocument meets it quite handily.

Conclusions

Without doubt, OpenDocument is an open standard.
It meets every requirement of a rigorous (merged) definition of
“open standard,” with lots of evidence.
In particular, there is significant evidence that it was not
controlled by any single vendor.

And that’s a good thing.
When I send a pure text file, nobody asks
“did you create that using WordPad, vim, or emacs?”
When I send a bitmapped PNG file, nobody asks
“did you create that using the GIMP or Paint Shop Pro?”
Why? Because it doesn’t matter.
Data formats that are fully open standards can be
implemented and understood by all. By using them, I’m free
to use whatever tool I want.

Governments have started to realize how important open standards are:

EU Commissioner Erkki Liikanen said, “Open standards are important to
help create interoperable and affordable solutions for everybody. They
also promote competition by setting up a technical playing field that is
level to all market players. This means lower costs for enterprises and,
ultimately, the consumer.”

Europe’s Telematics between Administrations Committee (TAC) said:
“Because of its specific role in society, the public sector must
avoid that a specific product is forced on anyone interacting with it
electronically. Conversely, any document format that does not discriminate
against market actors and that can be implemented across platforms should
be encouraged. Likewise, the public sector should avoid any format that
does not safeguard equal opportunities to market actors to implement
format-processing applications, especially where this might impose
product selection on the side of citizens or businesses. In this respect
standardization initiatives will ensure not only a fair and competitive
market but will also help safeguard the interoperability of implementing
solutions whilst preserving competition and innovation.”

Neelie Kroes
(European Commissioner for Competition Policy)'s presentation
"Being open about standards"
at OpenForum Europe, Brussels, 10th June 2008
made the following comments:
"If voting in the standard-setting context is influenced less by the technical merits of the technology but rather by side agreements, inducements, package deals, reciprocal agreements, or commercial pressure ... then these risk falling foul of the competition rules...
As purchasers, we need to be smart when we buy technology. We need to be aware of the long term costs of lock-in: you are often locked-in to subsequent generations of that technology. There can also be spill-over effects where you get locked in to other products and services provided by that vendor.
That is just bad purchasing.
The Commission must do its part. It must not rely on one vendor, it must not accept closed standards, and it must refuse to become locked into a particular technology -- jeopardizing maintenance of full control over the information in its possession.
This view is born from a hard headed understanding of how markets work -- it is not a call for revolution, but for an intelligent and achievable evolution.
But there is more to this than ensuring our commercial decisions are taken in full knowledge of their long term effects. There is a democratic issue as well.
When open alternatives are available, no citizen or company should be forced or encouraged to use a particular company's technology to access government information.
No citizen or company should be forced or encouraged to choose a closed technology over an open one, through a government having made that choice first.
These democratic principles are important. And an argument is particularly compelling when it is supported both by democratic principles and by sound economics.
I know a smart business decision when I see one - choosing open standards is a very smart business decision indeed...
Standards are the foundation of interoperability...
When a market develops in such a way that a particular proprietary technology becomes a de facto standard, then the owner of that technology may have such power over the market that it can lock-in its customers and exclude its competitors.
Where a technology owner exploits that power, then a competition authority or a regulator may need to intervene. It is far from an ideal situation, but that it is less than ideal does not absolve a competition authority of its obligations to protect the competitive process and consumers...
In addition, where equivalent open standards exist, we could also consider requiring the dominant company to support those too.
Better, much better, than trying to sort out these problems, is preventing them from arising. And we all have a responsibility to ensure that this type of perpetual lock-in does not happen, and, where it does happen, we have a responsibility to minimise the damage."

In short, open standards create freedom from control by another.
That’s a freedom we should all experience.

My thanks to the many people who helped me find the
information in this paper, including
Daniel Carrera,
Patrick Durusau,
Gary Edwards,
J. David Eisenberg,
David Faure,
and
Daniel Vogelheim.