You are here: ZDNet UK > News > Software

Office applications Toolkit

Story: Google: OOXML 'insufficient and unnecessary'

Posted by: Marbux (Thursday 28 February 2008, 10:05 PM)

Terse markup for speed -- NOT

Albert, you're repeating a myth propagated by Microsoft. I'm not in love with either ODF or OOXML. Both are standards in name only.

But the OpenDocument Foundation's da Vinci plug-in for Excel repeatedly loaded a million-row ODF spreadsheet faster than than Excel loaded the same spreadsheet rendered in OOXML. The margin decreases with repeated loading due to caching, but ODF is still the winner in that regard.

And if you study the OOXML specification, you will see that much of the markup, e.g., the entire volume in Part 5, specifies verbose markup. If processing speed were actually the criteria, one would expect that all markup would be terse, not just some of it.

It is important to realize that the Office apps still use the binary formats in their internal processes. OOXML support is via conversions performed by the major apps' native file support APIs using plug-ins. OOXML processing speed, to the extent it is a factor at all, is only relevant to the conversion of OOXML to the binary formats and vice versa. OOXML is out of the processing picture entirely until it comes time to convert the file to OOXML when saving.

If you study the OOXML spec, it quickly becomes apparent that the drawing line between terse markup and verbose markup is between the portions Microsoft originally submitted to Ecma and the unique portions developed through the Ecma standard development process.

The reason is fairly simple. The terse markup is a dump to XML of the markup used by particular builds of the Office apps native file support APIs' intermediate formats used in the conversion processes, the builds that were the beginning point for the standards work at Ecma. They are terse because it was far easier for Microsoft engineers to simply convert that markup to XML.

But the markup created later in the Ecma standardization process is verbose, as XML markup should be. See e.g., W3C XML v.1.0 (4th ed.).

"XML documents should be human-legible and reasonably clear. ... XML documents shall be easy to create. ... Terseness in XML markup is of minimal importance."

Terse markup mattered in the days when documents were stored on floppy discs or slow hard drives and storage space and memory capacity was a barrier, making a necessity of compressed binary file formats that were dumps to file of the in-memory binary representation ("IMBR") of a document. But verbose OOXML markup gets converted to terse markup anyway once the OOXML document is converted to IMBR for internal processing.

The better question is why Microsoft inflicted terse markup on developers. One might plausibly answer that it was to save money and development time or even hypothesize something more Machiavellian.

But the bottom line is that OOXML markup terseness is a bug, not a feature. The terse markup forces developers and authors to constantly refer to reference materials to determine markup functionality and gives scant clues for the electronic archaeologists of the future. OOXML violates the principle that "XML documents shall be easy to create .. [and] be human-legible and reasonably clear."

View complete profile

Private message disabled

View all posts