Is OOXML Really Open?
The standard that was presented and rubber-stamped by ECMA International (the former European Computer Manufacturers Association), is so tightly-bound to one software company's products that it will be exceedingly difficult for another company to either figure out what it means or to then implement it in another product.
Rob Weir gives an example: art borders
Further, I am concerned that the specification includes what can
only be considered a clipart collection. What rights does the
implementor have to reproduce this clipart. Keep in mind that
Microsoft's “Covenant Not to Sue”
covers patents, not copyrights. I haven't seen anything that would
grant implementors of OOXML the rights to reproduce this clipart in
their application. Is the specification hard-coded to use clipart which
we cannot copy?
All of these problems (spec bloat, cultural
bias, non-extensibility, copyright concerns) can be solved by one
simple mechanism. Instead of having ST_Border be a fixed enumerated set
of values, have it include only a small number of trivial values like
the basic line styles, and have everything else (all of the Art
Borders) be stored as a separate image file in the document archive.
He talks about how to create a "standard of one," describing the way that OOXML was designed to exclude other implementers.
But evidently in the realm of standards there are no practical limits
to the application of the above technique. It is quite possible to
write a standard that allows only a single implementation. By focusing
entirely on the capabilities of a single application and documenting it
in infuriatingly useless detail, you can easily create a “Standard of One”.
By making the specification detailed enough (and yet keeping key implementation data secret), a competitor can read the specification repeatedly and never find the information necessary to implement it.
But how can we have a standard that is truly open? How can we prevent the standards process from being used to exclude competitors, to the detriment of customers and all of society? Rob Weir again has an idea:
I think the key is to move away from the mere consideration of the
process of standardization and to also consider the content of the
standard. Just as a Constitution that held that women could not vote
was far from open, even though it was drafted in an open committee
process, a standard that does not facilitate use by competitors is not
open, regardless of the process that created led to it. We need to move
beyond strictly process-oriented definitions of openness and bring in
considerations of content and results. A standard can be per-se
non-open if its content violates important principles of openness.
In other words, a standard cannot really be open if it has legal restrictions on its implementation, and is designed solely to directly map to one vendor's products, and contains fuzzy requirements such as sections that require compatibility with something Word 95 does without telling what / how W95 does said thing.