Windows apps auto-detect the encoding by
looking at the data. When the result is
ambiguous, Windows prefers to choose
UTF-16 or that non-ISO Windows code
page.

This leads to some interesting bugs.
Type “john the ceo cries” into notepad,
without quotes or a newline. Save it.
Restart notepad with that file, and…
you see a row of missing-character
boxes.

Also, since these are both file format specifications, the normative text in its entirety defines document conformance. So I don’t think either specification can be interpreted as allowing “any zip file” to be conformant.

Application conformance is a different story. This is much more loosely defined, and perhaps it should be since there are many different kinds of applications that might handle ODF or OOXML documents, from the very simple to the very complex. So WinZip might be a perfectly reasonable OOXML consumer. I certainly use it for that task frequently.

So I now classify Winzip as a both ODF and OOXML producing application.

I would have expected a standard to at least state that a document should have minimum requirements and would have required certain parts of its content to be able to validate against XML scheme’s.
However non such conformance is required within the document standards which in general allows just about any kind of weird files to be send as documents.

Basically, what this means is that Office 2007 will need to contain all of the old code for reading and writing. Given that we understand the old writing code to be a memory dump, this suggests using the old routines as much as is possible – routines which have been demonstrated to be so full of exploitable bugs that many people conscious of security switched to OpenOffice as soon as it was available, since the unknown was statistically speaking safer.

It also sounds like their “spec” is vague enough that not even Microsoft can produce a conformant product – they define the formats that can be embedded so vaguely that it seems *every* older format is potentially included. I don’t think they can render all of those – certainly, there are many older formats that office 2000 cannot render.

So beyond the technical ambiguities and difficulties in the specification, and the economic mountain you must climb to compete against Office, there are several layers of legal hurdles whenever you try to go beyond what is detailed in the spec: 1) OSP no longer applies, so you risk patent infringement, 2)Any reverse engineering restrictions in the EULA, 3) In some areas, like DRM and encryption, the DMCA may apply.

Of course, I am not a laywer. But if I were implementing this stuff, I would be sure to talk to one.

I bet, however, that MS’s EULA for many(if not all) of those versions of Office and/or Word Explicitly forbids this suggested reverse engineering.

This means that — although MS might not be able to sue you for using their patents in reading an OOXML they might still be able to sue someone who (miraculously) succeeds in producing a compliant third-party OOXML reader including old formats for breach of contract.

Given all the flotsom and jetson in ooXML (i.e., the mass of legacy formats), maybe we just need a clean slate that will henceforth be easier and cheaper to implement.

Or to keep with your Star Trek theme, we need something to break the giant tractor beam locking us into proprietary black holes.

Enter ODF.

Jeff
Founder & Director
Open ePolicy Group
http://jakaplan.blogspot.com

In addition, while you seem to concentrate on Word related features, the same holds true for Excel as well. In fact, it’s worse. For instance, sticky notes in Excel 2007 are now wrapped in cryptic VML. It was not the case in earlier versions. And when you take a look at how the OPC rules are violated when defining such thing, the actual comment part is inferred, you get the feeling that the barrier to entry to do whatever with OOXML : read, write, calculate, render is incredibly high and this gives Microsoft not only many years of first-mover advantage, but a vendor should budget for many years.

This revelation I had when I tried to support the Excel charts in their new XML franca. This is so convoluted that I estimate it will take more time to decipher and abstract away than the BIFF8 records for charts. I have given up since I won’t be spending another two years chasing the tail light just because Microsoft intentionally crippled the file formats.