The primary reason why I started to talk about OpenXML more recently (OOXML, Office Open XML - whatever), and make a few comments here and there about it, is simply because I do not understand the rationale behind it in any way shape or form. That's pretty much it in a nutshell. Every comment, article and blog post I have ever read about it (and I've read quite a bit of the actual specification now - heavy going) has basically been trying to justify its existence. It's an awful lot of talk about..........nothing in particular. Some of the reasons have been quite flimsy to say the least, and the main one I've gathered out of it all is this:
OpenXML is about Microsoft documenting their Office formats.
Well, that's absolutely fine. If Microsoft want to document their formats and then submit them to some standards body then that's absolutely fine. No problem. That really is entirely up to them. Quite why Microsoft created another format to do that when it's transparently obvious that OpenXML is simply a translation of the old binary doc format and Microsoft Office features into a pseudo-XML format, I don't know. This is logically the case because Microsoft claims they created OpenXML as being backwards compatible. It isn't backwards compatible in terms of the files actually created, but it supposedly is backwards compatible with the Microsoft Office features and quirks within it because they can't be bothered to do a proper conversion.
Why not just document the binary format instead? Why not just create an entirely new and sensible format, eminently suitable for ISO submission, that referenced no previous versions of Microsoft Office or Windows technology and where older Microsoft Office documents could be simply converted, which is the job of Microsoft Office anyway? The latter question renders the issue of backwards compatibility a pretty void reason to me, but many people avoid that question.
However, the issue of it being an ISO standard is a different matter entirely, simply because any ISO standard must meet the aims and goals of the ISO. The biggest of those aims is about free trade and using standards to effectively communicate internationally, between governments, companies and organisations of various sizes:
http://www.iso.org/iso/en/aboutiso/introduction/index.html#sixhttp://www.iso.org/iso/en/aboutiso/introduction/index.html#eightAs you can probably imagine, being able to actually implement a standard in full, unambiguously, is of vital importance in an international standard. To create some parity with other industries and ISO standards, imagine just how worthless ISO 9000 would be if it transpired that only one of company could truly implement it - and they sold quality systems. I would imagine that would cause quite a big fricking fuss considering that ISO 9000 has become a requirement for many fields of work over the years. Having to buy a vendor's product to adhere to strictly it properly is not exactly on the agenda. It's expensive enough as it is.
This is why I had a bit of a go at
Rick Jellife's blog entry, because in reviewing a proposed ISO standard this is absolutely all that matters. It's very important, no? Ultimately, a standard is about communication, and if the standard miscommunicates in a big, big way then you have a big, big problem - because it's useless. So, being able to implement a standard, and OpenXML should it want to be an ISO standard, is of absolutely vital, primary and fundamental importance. If it can't be proven to be fully implemented beyond one platform and office suite, then given that it is a standard that documents the format of one company's office suite, the ISO has then effectively given them a monopoly. Not good, eh, and not what all the talk about open document formats and the whole issue of ODF was about?
This whole issue is quite apart from any duplication of ODF by OpenXML that many people come up with. These debates usually end with accusations that many ODF supporters want there to be only one ISO office document standard, which would bizarrely create a monopoly for IBM...........somehow. I seem to have missed out several steps there. The IBM monopoly situation is not an issue if ODF is truly and independently implementable, and their own applications stick to it. It is what ODF itself is there to avoid. Yes, IBM could make their own incompatible extensions, but, whatever they are not specified in the standard and no one else is guaranteed to be able to do anything with them. There's simply no good reason for any specific extensions to be referenced absolutely anywhere within ODF - so they're not. You can just do it.
I know Groklaw have had a list of
objections up for some time, and I've never seen a Microsoft web page with a point-by-point quote and rebuttal. Many people have tried quite badly to say why these don't matter, including trying to claim that the Microsoft and Office specific extensions and references are not the main part of the specification. Well, the point is, they're in there and the will be used by Microsoft Office, so claiming that no one else needs to use them is rather pointless. If a document cannot be created in Microsoft Office and sent to another system that has another implementation of OpenXML then as an ISO standard it is worthless. I know people have went tit-for-tat over this, so I'll just quote one part of the OpenXML specification and ask a question:
2.15.3.6 autoSpaceLikeWord95 (Emulate Word 95 Full-Width Character Spacing)This element specifies that applications shall emulate the behavior of a previously existing word processing application (Microsoft Word 95) when determining the spacing between full-width East Asian characters in a document's content.Yes, I do know this disclaimer is below it:
[Guidance: To faithfully replicate this behavior, applications must imitate the behavior of that application, which involves many possible behaviors and cannot be faithfully placed into narrative for this Office Open XML Standard. If applications wish to match this behavior, they must utilize and duplicate the output of those applications. It is recommended that applications not intentionally replicate this behavior as it was deprecated due to issues with its output, and is maintained only for compatibility with existing documents from that application. end guidance]
I deliberately chose this section of the markup language reference because of the East Asian character reference, in view of its proposed international standard status, but there are many such sections like this within the reference document pertaining to some specific behaviour within a particular version of Word or WordPerfect.
The main, and only really, reason for being, that I've managed to pick up from Microsoft and various people, is that OpenXML exists for backwards compatibility reasons with, as they put it, the
billions of Office documents already out there. Presumably, this is why sections such as this exist - for backwards compatibility reasons. Presumably, when older Microsoft Office documents are saved in the shiny new OpenXML format, elements such as this are used to preserve formatting. The only problem is that this behaviour is not specified. Anywhere. I can't implement an OpenXML application that will convert older Microsoft Office binary documents, and worse, I cannot even translate a modern OpenXML file simply because I don't know what this behaviour is. There are a great many sections such as this.
The real problem here is that incompatibilities, quirks, caveats and pitfalls in individual applications are simply being transferred from one format, the old binary doc format, to another with no appreciable benefit to anyone - least of all users. These pitfalls will continue to be inherited in successive versions of the document. The net effect is that anyone implementing OpenXML will have to deal with this inherited behaviour, despite Microsoft's disclaimer that applications should not use it. OpenXML, afterall, was invented for backwards compatibility reasons, remember? It would be interesting to see if Office 2007 still uses many of these so-called deprecated elements.
That's some background as to why it's a problem, but it's all beside the point really. The fact is, until I get some form of detailed specification for the behaviour that I need to handle then I cannot make an independent implementation of OpenXML. So, the question I wanted to ask is can anyone, anywhere, tell me where to find the behaviour I need to implement section 2.15.3.6? This could be in the specification documents, or as a reference. It doesn't really matter. If you read nothing else here, answer this question.
In a concise nutshell, if no one can answer that question then I certainly cannot implement anything within the OpenXML specification for backwards compatibility, OpenXML's reason for being remember, and I simply cannot make an independent implementation of OpenXML for myself and others as a result. This goes absolutely contrary to the ISO's free trade and communication aims and goals for its standards, this being the case. There you have it.
