They are also free to re-encode them in valid OpenXML formatting. OpenXML is XML. That means it’s to edit. If people care so much, they could–with relatively little effort–create macros or a regular expressions that re-encode what many of these tags do directly into the document formatting itself (e.g. for WP line spacing, change all linespacing to fn(linespacing).)

I have documents dating back to 1992. I open them just fine in modern word processors: The document format of choice at that time was, surprise surprise, plain text with a couple of formatting codes.

I can even open my Commodore 64 documents just fine. The only catch is that my character set converter of choice (GNU Recode) doesn’t do PETSCII.

The lesson I’ve learned is this: If you want the text to preserve, use plain text or don’t expect the transition to be perfect. If you want perfect formatting, dig out your PostScript files (or PDF in new documents).

Word processors aren’t document formatters. It’s foolish to expect formatting to persist. Despite everyone’s best attempts, it just doesn’t.

And if Microsoft doesn’t describe how to stay compatible, heck, this is a completely doomed effort anyway.

Plain Text is a well-defined standard for information interchange. HTML is a well-defined standard for information interchange. OpenDocument appears to be a well-defined standard for information interchange. OpenXML appears to be an Extremely Obfuscated, Difficult to Parse Plain Text Format that can be attempted to be used for information interchange if you get severely enough drunk first. But with these specs, don’t expect compatibility.

However, if you are trying to generate OOXML documents, the deprecated features are likely to be superfluous. So perhaps this is the use case that Microsoft is trying to promote.

It is definitely in their interest for more content to be created in formats that can only be displayed and edited correctly with their applications …

Please post some specific and broader issues with the spec rather than nitpicking at obvious but small-scoped irritants.

Hello? These "nitpicking irritants" are some of the most important reasons why OOXML is not an open standard.  The broader issue is that the spec is narrowly tailored to fit the internal operations of one company’s product, including its historical versions.  The spec does not give enough specific implementation details to enable Brand X Software to make a fully-compatible application.

It really is not about hating Microsoft.  If their products can compete with Sun and IBM and whomever in an open standard environment, then they deserve to win.  If they want to implement all of the backwards compatibility they can come up with, then so be it.  It just should not be squeezed into an open standard specification like this.

W^L+

Having said that, I will defend Guy’s example of military specifications. Moving footnotes and changing print layouts can in fact be important in maintenance docs and other things that rely on page numbering and appropriate spacing. I know – I used to work for a company that produced software that rendered a lot of them to print. They’re pretty particular about it.

Guaranteeing the precise layout is what PDF and Microsoft’s new PDF competitor XPS are for.

Please post some specific and broader issues with the spec rather than nitpicking at obvious but small-scoped irritants.

Secondly, in some federal agencies, there are already problems working with data saved with older versions of Microsoft and Corel office applications. By "working with", I mean reading and printing, as modifying such old data would compromise the integrity of the archiving (which is the reason such data still exists). This standard, as currently written, does nothing to improve that situation, as it encourages the retention of non-content-related legacy artifacts within the converted documents.

I have been discussing ODF and OOXML at http://lnxwalt.wordpress.com/tag/odf/ .

It might not look good if there is a little bit to much whitespace on a page, and some elements not centered perfect anymore, but the information in the document is still available.

If Microsoft really wants to open up there formats, they should be willing to break some formatting to guarantee compatibility with the future.

If users want backwards compatibility, save it in a DOC or XLS format. If they don’t need that backwardness, save it in the XML DOCX or XLSX format and from here on it that file will be compatible.

Jonathan, I suggest Microsoft stop promoting their file format as general-purpose and stop pushing it as a “standard.” It makes sense as an internal format for Word and it makes sense as a way for other applications to (try to) faithfully import Word files.

As far as a competitor to OpenDocument, who in the world would go with this as their native format? Think of all the word-specific crap you’d have to consciously ignore when reading/implementing/debugging against specs.

This tells you what you should emulate, but does NOT tell you how you should do it. Application could choose to read the property and define a standrad way of showing, e.g., footnotes and show them.

When I say I also agree with the poster is that, they could’ve made it more flexible, and when converting a document actually put the rules there (width, height, and so on).

Now, what intrigues me is, if Microsoft has ceased support for WinXP and WinXP SP1, when are they going to stop supporting Word Perfect and others like that??

Compatibility should’ve gone as far as year 2000.

I am routinely forced to use a powerpoint template that was created with Office98 for Macintosh because it was heavily used and tweaked.

Whether Office2007 will open the legacy documents and translate all their idiosyncracies into non-idiosyncratic OOXML (highly unlikely), these documents will continue to live on far longer than most people realize.

When the managers start trying out that new OpenOffice that is supposed to support the OOXML “standard” and OO cannot render these legacy documents accurately, but Office2007+ can it’s back to Office2007 because it’s “easier and less trouble.”

I agree that there are probably good reasons for having these tags with their “inappropriate” rendering internally by MS. However, to leave them unspecified in a “standard” is a little tough to swallow.