This is rather straightforward, I think. The key is to start from the manifest so you know what the types of everything are.

So what about this WMF? The manifest declares this as being of type “application/x-openoffice-gdimetafile” and puts it in the ObjectReplacements directory. So this is clearly an OpenOffice extension. But this has no impact on the MathML. For example you can delete the entire ObjectReplacements directory and the file will load and display fine.

If I had to guess, not being an OO developer, this appears to be a performance enhancement, so the initial load of the file in OO can quickly display the metafile for embedded formulas rather than loading the formula engine and regenerating the appearance of the formulas. This is common technique in many applications dealing with embeddings. Office does it. SmartSuite does it. It is a core part of embedding frameworks like Microsoft’s OLE2.

Note that no implementation is required to read or understand the metafile. They only read the parts of manifest they want.

Note an important distinction here between ODF and OOXML. ODF allows implementations to create performance enhancements like this, so long as the underlying format remains ODF. Hints, added in their own content-type or own XML namespace to make the file load faster, that is fine. An implementation that doesn’t understand those hints can ignore them.

OOXML on the other hand mandates some things, like string tables, for performance. No implementation can avoid dealing with them. Now, smart people can differ on whether this is a good thing or not. But think that mandating more complex representations for performance reasons makes it more difficult for implementors of the format, especially small implementors. Not everyone who will work with ODF or OOXML will be writing full desktop editors. In some cases it will be just a few lines of Python script. I wouldn’t want the Python user to deal with WMF or string tables.

Maybe a coder’s primary concern is not performance, but ease of code? Maybe they are dealing with primarily small documents? Maybe an implementation wants to be clever and have string tables for only large documents,but not for small documents, because that may give overall better performance. Maybe an implementation is more interested in optimizing writes than reads?

My point is that how you optimize performance depends heavily on the application and how the application is used. I’d hesitate to include an optimization in the standard file format unless it was universally applicable. In extensions, fine, just make sure they are not required for other applications to understand the format. Better to stick with the core strength of XML, the readability. If the past is any indication, machines will continue to get faster in the future, but people will get no smarter. So ease of programming the format is what we should optimize for.

I still do not see however why OO.o using ODF supporting MathML creates a binary (wmf?!) file as you say whilst MS Office 2007 manages to create a full XML representation of equations without such binary additions.

Mayby that is due to ODF using only the presentation part of MathML?
A full XML representation however might well be a preferable choice for interoperability ???

I do religiously read Brian Jones’s blog, but I’ve seen no comment that points to a problem with MathML in ODF. I think a look at the manifest file of the document would indicate that the binary blob is simply declared as a Windows Metafile. Nothing mysterious about that. And even a look at the specification will reveal that ODF uses MathML Version 2.0 (Second Edition, no modifications, no additions, no nonsense.

The MathML interop is quite simple and straightforward. For example, a MathML expression from Mathematica can be cut & paste to replace the XML in an ODF MathML document. It works — I’ve done it. I’ll post instructions and an example next week, OK?

I see you (or someone of your name) has also posted that I “censor all comments” and “remove any negative messages on ODF” from this blog. This is patently false and you are a liar, a fool, or both if you perpetuate that lie. I’ve posted every comment I’ve received, unless it was spam (online gambling, viagra, etc.).

I don’t think it requires “attitude” or claims of “nefarious purposes” to suggest that Microsoft has been more than a little ham-fisted when it comes to web standards.

Please, yes, let’s start talking about the customer. Let’s talk about how diverging from established standards perpetuates vendor lock-in. Let’s talk about customers and how they will need to forget what they know about established web standards and learn new replacement markup, used only in OOXML. Let’s talk about customers and how moving to OOXML locks them into not only Office, but Windows as well. I am very concerned about customers and what this all means for them.

There is the old joke, that the nice thing about standards is that you have so many to choose from. But that is an old joke, and I’m not laughing anymore.

You are absolutely right in holding up the TC45 work to a high standard and raising the questions you do.

I’d love to hear from Microsoft the exact reasons they did not originally set out using the MathML and SVG standards in their document formats. However, I also believe that when (if?) they explain why, there will probably be very good technical reasons they made that decision at the time.

However, the attitude I was talking about has more to do with the wording of your articles and the perception that you create that Microsoft make these decisions for nefarious purposes.

I think everyone needs to move beyond the them vs us attitude and start thinking about the fact that there WILL be two document standards, one based Sun’s initial work and one based on Microsoft’s work.

Both standards will have flaws, omissions, workarounds and trade-offs, as all other specifications do, and will be refined over time.

It’s time to start thinking about the customers of these two formats and how they will interoperate.

I believe I’ve stated this elsewhere on the website, but for the record what I write here are my words and do not necessarily represent the views or positions of my colleagues at IBM, OASIS or any other organization I’m involved with.

In any case I’d hesitate to stereotype the motivation of those who support ODF. The support is broad-based and diverse, from many quarters in government, education, nonprofit, commerce, industry as well as the open-source and standards communities. The move toward ODF is global and it ranges from individual preferences to national mandates. I imagine the motivations are equally diverse.

Keep in mind that (to my knowledge at least) I’m the only one out here taking a deep technical dive into OOXML to let some light in on what some the deficiencies are, from a standards perspective. I have no gripe against Microsoft or Office per-se. What they would do for their own proprietary Office formats would be of little interest to me personally. For example, you will not see me talking about the still undocumented and proprietary formats used by Visio, Project, OneNote or Access.

But when Microsoft submitted OOXML to Ecma for consideration as a standard, and made it clear that they intended to move this forward through ISO as an international standard, then I think this is no longer merely one vendor’s private matter, immune from criticism. When it crosses that line then it should be evaluated from a more stringent perspective, and criticism on how it contradicts existing standards, or makes it difficult for other implementors to work with it, etc., are all legitimate questions.

Standards are not about a single player with monopolistic powers in a given market ramming though a specification in order to collect an imprimatur to wear as a fig leaf for government sales. Web standards work in an ecosystem of existing standards, tools, knowledge, open source codes, design principles, etc. Is it inflexible to believe that a format that aspires to be an international standard should use relevant standards as well? If so, then count me inflexible on that point.

You might have your reasons, but it is this inflexible “they cannot do anything right” approach that will ensure there won’t ever be a real dialogue that can bridge the gap between ODF and Microsoft.

Clipboard support? What does this clipboard support buy me when running a Linux server? With XML formats we need to think outside of the Windows/Office System and think of all the other places we can do document processing. The format itself should contain the standard formats, not relying on some outside process to provide it.

“Just couldn’t find a way”? Really? Microsoft can’t figure this out? Has the topic even been brought up for discussion at Ecma TC45 meetings? Perhaps it is worth another set of eyes on the problem? Perhaps requesting expert comments on this specific issue from the W3C? If Microsoft is having technical problems finding a way to integrate MathML into OOXML I’m sure many would step into help if asked.

On the other hand, if integrating change tracking and styling honestly required throwing away all of MathML and creating a new XML mathematical equation markup, if this was truly the only way to get the job done, then this speaks volumes about OOXML and how hard it is to work with.

Why would one want to work with OOXML at all if its own authors claim it is so inflexible they cannot integrate standards like SVG or MathML into it, and instead need to come up with proprietary replacements? Does the X in XML stand for eXtensible or eXpendable?

Also, the fact that they support MathML clipboard exchange seems to indicate to me that they really thought about this, but just couldn’t find a way to represent their feature set in MathML.

Finally, on your suggestion to extend MathML in those areas where it lacks. First, those features seem to be not specific mathematical rarities, but rather some very common things that would effect allmost every element (like change tracking or styling). Second, I can fully understand why Microsoft is shying away from this embrace and extend approach lately. They have been accused of that approach quite a bit in the past, to now suggest to them to continue with it seems quite strange.

When a specification has aspirations to be an international standard, I think it is fair to ask to what extent the specification is being written to advantage a single vendor, to perpetuate vendor lock-in, to ignore or even contradict relevant existing standards, and to make life more difficult for those who will need to work with the standard. I think these are legitimate points to raise.

Does OMML represent more forms than MathML can? I have not heard that argument made, but let’s follow that logic for a bit. What % of formulas in use in Word documents do you think can be represented in MathML today? 95%? 99%? What I would have done is used MathML as the base equation representation so the most common-case would be pure MathML. Then for that extra 1% or so of features that MathML lacked, I would add elements/attributes in my own name space. At the same time I would work with the W3C to enhance the next version of MathML so it included that additional 1%. That would give you full-fidelity as well as work with the establish community of MathML users and vendors. Would it require more work in defining the specification? Yes, most good things do.

The point is you don’t throw out a well-established web standard (and they entire ecosystem that has developed around it) and make a new specification just because it is missing your 1%. That way of doing business is based on fear, the fear of standards, the fear of openness and the fear of interoperability.

Your criticism amounts to a complaint that they should have based their equation editing features on MathML. There are a number of legitimate reasons why they might make such a decision. For one thing, MathML doesn’t really support all possible math forms. Perhaps it should but it doesn’t.

Paul Topping
Design Science