A standard is not "free enough" if implementation of it depends on existance of a proprietary technology on the specific platform. Ideally it should be possible simply to buy the specification and implement it without any other financial requirements.
This is where OOXML fails.
OOXML heavily depends on "Object Linking and Embedding Technology" also known as "OLE-technology". Section 9.3.3 of the specification deals with how objects are embedded in the file format. The section is divided in two where the first section specifies how to embed documents otherwise defined in this standard. These documents are defined as
- Text documents
This is one of the clear cases where it is obvious that Microsoft continiously tries to preserve their main cash-cow: The Microsoft Office eco system! OOXML not only depends on Microsoft's proprietary technology OLE, the specification itself also makes it more easy to embed it's own "cousins" than any other file format. Talk about "first class citizens" of OOXML!
The section goes on telling us about binary objects:
Objects that do not have an XML representation. These objects only have a binary representation [...] (see [OLE]).
WTF? Once again a reference and requirement to use proprietary technologies like OLE! What if I want to embed my own JLSObjectType? What if I want to embed some object from the Linux-world like Bonobo-elements or KParts? The schema-elements only emphasizes my point:
Are you also puzzled by this? Well, I don't blame you. To wrap up - we can embed "our own documents" and we can embed
everything else. There are even two seperate elements from the
draw-namespace that specifies this for us: <draw:object/> and
<draw:object-ole/>. The entire schema-fragment is included here for your pleasure:
This is yet another example of Microsoft on one hand claiming "openness" and with the other hand forcing everyone to use their own proprietary, undocumented technology.
But we're not done:
The embedded object is referenced through an XLink attribute in the enclosing frame-element. The behaviour is described as (bold typeface is my addition, /JLS):
The xlink:href attribute links to the object representation, as follows:
- For objects that have an [OO]XML representation, the link references the sub package of the object. The object is contained within this sub page exactly as it would as it is a document of its own.
- For objects that do not have an XML representation, the link references a sub stream of the package that contains the binary representation of the object.
Wow - wait a minute: Is this it? Don't you think a bit of clarification would be in order?
The fileformat for the physical file is a Zip-archive with a number of files and folders in it. But this archive also contains a "TOC"-list of the files and the mime type of the entire package. The latter is not an XML-file - where do I put this? Where do I put the TOC-file? What if my spreadsheet contains an image? Since the image is not in XML-format (it's binary) ... would my entire spreadsheet qualify as having "an XML representation"? And did you notice the part "the link references a sub stream of the package that contains the binary representation of the object."? A stream? Binary representation? Again totally unspecified behaviour and noone will ever be able to implement this apart from Microsoft and Microsoft Office 2007.
Microsoft had a good chance to specify this properly in the beginning. They could have made an open format to enable competition or a format that would stiffle competetion. So what does Microsoft do? Yup, the anti-competitive choice. Anyone surprised?