19 February 2007

OOXML hoax 3: The standard requires cloning of old propriety behaviour

This suggestion probably originates from IBM's blogger Rob Weir and his Guillaume Portes article which is one of the most cited articles in articles about OOXML.

The issue is about the OOXML elements in section 2.15 of the OOXML specs. This section describes compatibility items for documents created in the past with older office versions or even with WordPerfect. The tags should only exist in converted legacy documents and should not be used in any new documents.

The first thing to say is that OOXML does not require any implementation to support these tags. There is little reason to support these tags for virtually any application.

Secondly, IBM's Rob Weir argues that "these legacy tags are some of the most important ones in the specification". Of course he would because he wants to OOXML to look bad. The fact is that applications like OpenOffice currently manage fine in converting most .doc files without supporting these compatibility features If implementing the compatibility tags is really so important then people could interprete Rob's statement that you should never use an implementation that doesn't support full compatibility features with legacy documents and stay with what you have.

Thirdly, the compatibility tags are about rendering Office documents. Rendering behaviour is described in OOXML (or ODF for that matter). It would be very strange to exactly describe how the compatibility tags rendering would have to be, while the normal rendering is not described. Office document rendering is always implementation specific.

Fourthly, these tags describe that converted documents may have rendered differently when they were originally created in their original application. Even for applications that are not interested in recreating that actual rendering behaviour these tags can be valuable. When opening a file and parsing these tags an implementing application can give the user a warning that the document looked different in it's original form. This could be important for evaluating conversions of documents that may require very faithful representations like notary documents or documents that archive printed works.

Ah, but ODF does not have this legacy compatibility shit. Why put it into a standard ? ODf has chosen a different approach for dealing with legacy compatibility. It just doesn't define it but leave it implementation specific.
For instance OpenOffice uses custom application settings like:
UseFormerLineSpacing
UseFormerObjectPositioning
UseFormerTextWrapping
UseOldNumbering

and a lot more...
So OOXML has a lot of deprecated tags that almost impossible to implement but ODF has actually created a special standard tag for stuff that you can't possibly implement. ODF has actually standardized "Application setting" tagging that cannot be interoperable because any such 'standard' tags will not be defined. and this stuff is not deprecated. You can make new documents with it.
If Microsoft would use ODF then they can use the "Application settings" to create fully standard compliant documents and still make them impossible to be interoperable. At least in OOXML the extend of the compatibility is known and when a compatibility issue is found it can be recognized and the uses warned accordingly. In ODF files when using the "Application settings" for compatibility the only thing you can do is to warn the user that the document can behave differently because it has separate undefined settings for different applications.

Two solutions for ugly old settings. Both can lead to very ugly documents. But at least the OOXML stuff is only for the past, the ODF "application settings" can keep haunting us for a long time to come...

3 comments:

The Wraith said...

Microsofts Brian Jones has now also added an article on it. He is probably a much better explainer of it than me.
http://blogs.msdn.com/brian_jones/archive/2007/02/20/beyond-the-basics.aspx

Anonymous said...

I think the difference between the ODF app settings and OXML's legacy formatting tags is that if someone implemented the latter in terms of the former, there would be no expectation that other apps replicate the behaviour: it would be private to the app.

I agree more is made out of those tags than deserves, but I don't think they should be in the standard.

Anonymous said...

@anonymous

I don't understand your objection. Can you elaborate?

the wraith: Thank you for a balanced view. The whole anti OOXML movement is surreal.
Andrew