Fixed, thanks.

Tim

A small typo perhaps?
On line 5 (6) you wrote:

“in 2006 it because an ISO standard.”

Did you mean “became”?

Cheers
Malcolm

Too bad you didn’t ask Mr. Pauoli about compliance with the other half of XML – the Extensible Stylesheet Language (XSL) compliance and it’s vital component XSL Transformations (XSLT) compliance.

Have you got any more detail about this? It’s odd because apparently the Microsoft-sponsored ODF/OOXML converter uses XSL.

I actually said that it should NOT use XSL because it tends to be slow and memory-hungry; not good if you are working with large documents.

Tim

To be brief, that if you don’t get to work on your specifications, and just get to work, you’ll come a cropper.

And you’ll probably see why I for one distrust ECMA 376. It is intended to represent at least ten years of hidden (and/or reverse-engineered) file formats, most of which turn out to have niggling incompatibilities with the ones immediately before them or after them, and wild differences if you get to three or more major versions between them.

So it’s just going to incorporate those incompatibilities? That sounds like bad engineering. It’s going to harmonize them? That sounds better, but how? It’s going to ignore them? How, while retaining this this widespread compatibility?

I don’t think Paoli makes this clear.

And I think the example given of tables with borders in DOC format and their non-transfer to ODF is somewhat ingenuous. Isn’t that supposed to be a matter for the application plus file filter to handle? As long as ODF can put a border around a table, as long as the application supporting ODF can give a set of styles for borders, then it’s not a major issue – borders around tables do not as a general rule, represent significant information. If I insist on a particular style and only that one style, and will not be satisfied with anything else, no matter how close it gets, then I should see a psychiatrist, not a programmer.

I’m sure Joel Spolsky could enlarge on that, if Paoli ever asked him.

I wished you would have pressed more follow-up questions.

Actually this was a long interview, about twice as long as I normally do. Of course I have not quoted everthing that was said. I would like to have asked more questions, but Paoli tends to give lengthy replies and we simply ran out of time.

Will we see an interview with the other side of this issue, perhaps with Sam Wier or Bob Sutor? That would offer balance. Just let them respond here, on your blog, if you will.

Sure, they can comment, though I think you have conflated a couple of names there And possibly an interview, if it can be worked out.

— One of its “likely goals was to undermine” the dominance of Microsoft Office by providing a free alternative.
Really? Can you source this belief?

I’d refer you for example to many comments from Scott McNealy over the years. Here’s a quick link for example.

ODF went through a laborious, non fast-tracked ISO certification. Microsoft refused to participate in ODF’s development even though they were invited. How is that “sneaking ahead?”

Just that Microsoft was an early XML adopter, both in general and in Office.

— Silly comments about reference implementations and the poor quality of the Microsoft-sponsored OOXML/ODF converter do not help.
By “silly” do you mean critically honest? That statement is confusing.

I mean only that it is silly to say that Corel or Sun is producing a reference implementation of Office Open XML. I don’t think that claim helps the case.

Tim

— One of its “likely goals was to undermine” the dominance of Microsoft Office by providing a free alternative.
Really? Can you source this belief?

— …it must frustrate the company to see the later ODF specifications “sneaking ahead” in the standards game.
ODF went through a laborious, non fast-tracked ISO certification. Microsoft refused to participate in ODF’s development even though they were invited. How is that “sneaking ahead?”

— The Open XML format has them all, but ODF which has not been designed for backward compatibility, does not have them. It’s really the tip of the iceberg. So if someone translates a binary document with a table to ODF, you will lose the framing details. That is just a very small example.
Has Microsoft published the .doc spec publicly? Then why should ODF worry about the past? It’s not ODF’s concern to worry about Microsoft’s past formats. (Understand that the .doc format alone changed six times in the last eight versions of Office!) That’s Microsoft’s legacy problem, not ODF’s.

— …third parties like Corel, which have previously implemented support for binary formats like .doc and .xls, should find it easy to transition to OOXML.
They have? Where is there file converters? What’s taking so long? If it was so easy, why was Novell’s first effort so incredibly poor? (You’ve got to ask the follow-up question man!)

— On the IBM/ODF side there is open hostility.
Yes, I would say I’m openly hostile to lies, in every part of life, work, and business. Aren’t we all?

— Silly comments about reference implementations and the poor quality of the Microsoft-sponsored OOXML/ODF converter do not help.
By “silly” do you mean critically honest? That statement is confusing.

Except that it is not true at all.

I’ll give you two counter-examples, but you can find a ton more.

1) VBA macros. MS OOXML does not define them, therefore they are a) not expressed using XML b) not made interoperable. In practice, it means you need Office 2007 to use your existing VBA macros. Office 2007 is not just a UI on top of OOXML. Office 2007 is a UI on top of 15 years of legacy and proprietary protocols and formats. Out of which OOXML is an emanation.

2) Charts. There is a new chart engine in Office 2007. But it does not respect existing charts created using an older version of Office. There are MANY bugs, it’s just incredible. Oh, and of course, they don’t look the same anyway visually, so any “full fidelity” requirement à la SOX puts OOXML out of the game.

The level of hypocrisy in MS blogs is astounding. You seem to be following them pretty well too. I am surprised by the dissonance between what they say in their blogs, and the huge lobbying in private.

I’ll add a couple more things.

One of new scenarios enabled by the “custom xml parts” (again, if you read their blogs, you must have heard of this stuff) is the ability to bind xml sources and a control+layout so that it enables the equivalent of data queries (we’ve had in Excel for many years already), just with a source which is part of the package, contrary to the typical external data source connection. Well this stuff, besides the declaration (which includes, big surprise, GUIDs and stuff like that) requires the actual Office 2007 run-time to work. So whenever MS says this stuff is interoperable, they cannot mean you can take this stuff away in another application. Because you can’t. This binding is more or less the same than the embedding of VBA macros. It’s all application-specific, and only Microsoft’s own suite knows how to instantiate this stuff.

The same for Word document chunk merge feature. A number of people over at the openxmldeveloper.org (MS owned, with paid MS consultants answering questions) are willing to do this with just a ZIP and XML stack, failing to understand that the merging feature requires an actual instance of Word to do it given the complexity/remapping of all the underlying objects.

Anyway, this comment is way too long already. I guess you get an idea where I am at…

Yes indeed, but you could argue that IBM has been doing it even longer, with SGML. SGML isn’t XML, of course, but the issues should be fairly similar. If Microsoft is suffering from a little “not invented here” syndrome, then so may IBM…