Obviously all of them have been re-engineered to different extents, but only Microsoft is able (or rather “would be able, if they really wanted”) to render them in precisely the same way in every detail as it was done in the original application. Now lest anyone attempts to use Microsoft Office to convert those legacy documents into a format that would enable any odd application to display, use and print them as originally intended, they chose to not convert them in the first place but rather tag them such that only Microsoft Office can do that.

In other words:
so you’ve got an MS Word (old version) document. You can (in theory) open that with the current version of MS Word to look and feel the same as it did back when it was created. If you had an open standard format, i.e. one not referring to proprietary algorithms, you could export the file from Word into that format and henceforward work with it in any other application supporting the standard, without any recognisable difference in rendering or functionality. To get around that, the exported file instead refers to the proprietary algorithms used in the original application it was created with, making it impossible for other contenders to accurately emulate its look & behaviour in every detail.

So instead of converting a, say, Word 95 document into a neutral format and in the process translating its quirks and attributes into a neutral format, they just tag the contents with something like “render like Word 95″. Which only they can do when it comes to it and takes the idea of a neutral standard ad absurdum.
What they say is “you can save this document into OOXML but if you want it rendered it exactly the same as in Word 95 then you better use our product”. Which is anti-competitive behaviour in my opinion. I don’t think it’s a technical issue in the first place rather than a political one (and that’s why they are so bullish about it), nor that they should get away with it.

Sorry for the long post.

Speaking as someone who has to deal with much of the Microsoft legacy code – a lot of the people I help with their computers, either bought them ages ago, or were given old computers with old software – that would not be a bad idea.

Consider this – Microsoft has made its billions on the back of this software, which has lost nearly all its book value because Microsoft has stopped supporting it. It has also lost nearly all its “Intellectual Property Rights” value because it has also been reverse-engineered world-wide, courtesy of books like Microsoft Press’ “Inside Windows NT” which has a very positive view of reverse engineering and gives detailed instructions on how to go about it. Ergo, Microsoft should do the honest thing and release all this legacy source code under a suitable open-source-style license like the template Microsoft Community License – without any further additions whatsoever.

I can say this, that the spam and malware problems would decrease markedly, if these old computers with their legacy software – malware’s sitting ducks – , were able to be upgraded by suitable people using Microsoft’s own source code without any stupid malware-friendly restrictions.

So you are saying that since competing applications over the years have struggled with, and in some cases succeeded with, reverse-engineering aspects of proprietary documents, there is no need for ISO standards to do any better than this.

Indeed, by your own logic, why have an OOXML standard at all, since OpenOffice can already read many Office legacy binary documents?

Length and information content are not two measures of the same thing. This isn’t about making the specification longer or shorter arbitrarily. It is about specifying a set of features in an economical fashion, using time-honored engineering principles.

For example, if we had a flexible line spacing model, we would not need to specify exceptions for legacy versions of Word. If the model is flexible, we simply describe what the spacing is, in real units, just like it would be specified in a new document.

The point is you put the burden of accounting for the Word 95 bug on the convertor that converts Word 95 documents into XML, not on everyone else in the world who needs to deal with with OOXML.

It means adding several hundred more pages worth of details on how each version of Word: did horizontal justification, vertical line spacing, treated raised and lowered text, kerned letter pairs, condensed and expanded spacing, stretched and condensed character pitch, etc. Plus a heck of a lot more stuff for non-Western scripts.

Would you prefer that Microsoft insert its source code into the spec?

If OpenOffice.org can import a WordPerfect 5.0 document and correctly display the top spacing, then they know how to render suppressTopSpacingWP already and don’t need to be told.

If they ignore the WP5 top spacing brokenness, why wouldn’t they ignore suppressTopSpacingWP as well? How are they worse off?

Either they care about maintaining rendering fidelity with documents created in WordStar or whatever or they don’t. If they do, they already do so for documents they import from WordStar binary formats. Didn’t care enough to import WordStar? Why start caring now?

Yes, MS will be the only people to implement the whole thing. But this is about interoperability. As long as they don’t start setting the mwSmallCaps flag in new documents created in Office 2007, there is no interoperability issue.

In my opinion, what is really important here is not if the format allows application-defined stuff. The important thing is: is this information needed for proper displaying the document or not?

If those sections include, for example, where was my cursor when I last saved the document, what was the zoom level, what were my printer settings, and so on, the document doesn’t actually need them. This is just additional, optional information. It is perfectly safe to store that information in a good place (e.g. separate files from the main document), and applications are allowed and incouraged to do so in order to achieve a better user experience.

If instead an application is using that data in order to add vendor-specific stuff that is required for correctly undestanding the document, this is definitely wrong (and typical of the Embrace-Extend-Extinguish strategy).

My two cents :-)

Tidier is in the eye of the beholder…

I agree with orcmid that both ODF and OOXML has virtually everything “optional”. Perhaps Rob should had made it clear that ODF has a lot of optional things as well. Again, the question of who has more “optional” item is in the eye of the beholder.

Both ODF and OOXML containers (zip file) permits additional files to be included and those are simply going to be unspecified in the ODF/OOXML specs.

My own preference for application-specific stuff is to isolate it in less important files, not sprinkling in the main content where I have no choice to parse it in order to consume the main content. This is of course looking at the problem from the consuming application point-of-view, not how beautiful or self-containing the main content is.

If you think that throwing application-specific compatibility flags into the schema of an ISO standard submission is a “tidy” solution, then I think we have radically different defintions of “tidy”.

In any case, the point was to respond to those who dismiss any criticism of undefined, poorly-defined or incorrectly-defined elements in OOXML as “don’t worry, that part is optional”. Since everything is optional in OOXML, an ocean of sins can be buried (and indeed have been buried) by that disingenuous logic.

One of the criteria for evaluating a specification is whether the normative content is unambiguous. Normative content includes optional and deprecated elements as well.

In fact, everything in OOXML is optional.”

Indeed, nothing in OOXML is any more optional than in ODF, where everything, including tons of private (i.e., “foreign”) extensions, are optional.

My reading of OOXML is that they are tidier about it than that.