Summary: In this post I will look at MathML, a web standard for displaying mathematical equations. I will show how well established it is on the web, how it is integrated into ODF, and how Microsoft has decided to go off in another direction with OMML, another “stealth” standard hidden in their 4,000 page Office Open XML specfication, but little mentioned. As I did with my prior analysis of their reliance on the rejected VML specification, I will show why this is a bad thing.

I’ve been reading *Math You Can’t Use: Patents, Copyright, and Software* a book by Ben Klemens, Guest Scholar at the Brookings Institute. It examines the current state of software patents in U.S. and the abuses thereof. He blends his legal and economic policy background with his insights as a programmer to give a perspective worth hearing. Mind you, I don’t agree with him on many points, and in fact I found the book infuriating at times, but he does make a serious argument and I respect that. In any case I like to have my opinions challenged every now and then. It keeps the mind limber.

Although I am not going to talk about patents and copyrights today, I will steal the title of this book and talk a bit about math, the kind you can use as well as the type you can’t. The topic for today is MathML.

MathML is a web standard from the W3C, an XML vocabulary for representing the structure and content of mathematical expressions. In other words, it represents equations for display, especially complicated expressions with integrals, summations, products, limits and all the Greek you can throw at it.

If you are running Firefox and have installed the math fonts then you can get an idea of its capabilities by loading MathML-enabled pages right now, like this one. If you are running Internet Explorer, then sadly you lack native support for MathML, but a browser plugin is available.

MathML 1.0 dates back to 1999, and has been revised through MathML 2.0 (second edition) in 2003.

There are about 100 implementations of MathML if you count producers, consumers and editors, including the powerful software used by working mathematicians and scientists like Maple and Mathematica.

The W3C has made a special effort to get the various MathML vendors together to evaluate how well they handle MathML and this is reported out in their Implementation and Interoperability Report .

Where MathML is supported natively, such as in Firefox, it will render along with the text, and not merely as an embedded GIF image. So, it will scale to different screen resolutions and print well. In theory, since it is just text markup in the page, it can be indexed by an intelligent search engine, though I am aware of none that do this currently. (Is there any use for a Google search of all web pages that include a 3rd degree polynomial inequality? I wouldn’t want to be the first to say “No”.)

MathML also is the key to enabling better support for mathematics via screen readers and other assistive agents. When a visually impaired user is presented an equation in the form of a GIF or other image format, they are left out. But put the formula in MathML and the possibilities look better. The work is not complete yet, but progress is being made. For example this report from CSUN 2004 and NIDE’s MathML Accessibility Project.

Further innovations are seen at sites like Wolfram’s MathMLCentral where we see web services for creating, displaying, or even integrating MathML expressions, using their Mathematica program as the backend.

For the above, and many other reasons, MathML was the only logical choice for us to use to support equations in OpenDocument Format (ODF). With such a thriving ecosystem of producers and consumers, with support the tools used by academia and industry like Mathematica and Maple, strong support in web browsers like Firefox, with the accessibility initiatives around it, I don’t see how you could argue otherwise. MathML is the way the web does math.

But the choice of MathML is more than just a fashion statement. It has practical significance and enables opportunities for innovative workflows around mathematical document production. If you create an equation block in OpenOffice, it saves the equation as a standalone MathML XML document in the ODT document archive. This makes it very easy to access, read, replace, etc.

We should be thinking about workflows like the following:

- Do your complicated calculations in a tool like Mathematica
- When you get the final results you want, export it to MathML, for example, using Mathematica’s MathMLForm[ ] function.
- Copy the MathML into an ODF document archive
- Take the ODF document and complete the prose write-up of the document in OpenOffice
- Share the draft with colleagues, review, etc., in the editable ODF format
- When ready to publish, export to XHTML with embedded MathML preserved for the equations, and embedded SVG for the charts.
- Users can then view in Firefox or Internet Explorer (with extra plugin)

We’re not quite there yet, end to end. Step #6 in particular is not working as I’d expect in OpenOffice 2.03. But you get the idea. There is opportunity for fame glory and perhaps some profit to the person or company who provides an end-to-end mathematical editing and publishing solution based on open standards.

So, in this happy world I’ve described, what is missing? If you guessed “Microsoft Office” then you guessed correctly! Even though MathML is a 7 year-old standard, widely implemented, supported by the leading mathematical tools, the preferred format for publishing math on the web, etc, etc., (the mantra should be familiar), Microsoft has ignored it and instead is pushing forward a new competing format in their Office Open XML (OOXML) specification rushing through Ecma.

The new math markup format is called OMML and you’ve probably never heard of it. You can check Google, you can check Wikipedia, you can check MSDN. You won’t find it. In fact, I’m not even sure what OMML stands for since the acronym is not defined in the spec. But it is there, nestled away in the 4,081 page draft OOXML specification as the markup that “specifies the structures and appearance of equations in the document”, Section 25.1, all 93 pages of it.

OMML is not MathML, though it does the solves the same problem. But if you use OMML, it will not work with Firefox, with Mathematica, with OpenOffice or with any of the other 100 applications that support MathML. OMML works with Office, and that’s it. One door in, no doors out.

Consider that Ecma TC45’s Programme of Work included the goal of:

….enabling the implementation of the Office Open XML Formats by a wide set of tools and platforms in order to foster interoperability across office productivity applications and with line-of-business systems.

How exactly does the OOXML specification foster this interoperability when it ignores relevant web standards like MathML (and SVG and XForms)?

Microsoft’s typical argument is to say that the existing standards are inadequate, that Microsoft users expect more, that they need more features, that this is because they need to deal with billions of documents and trillions of dollars, etc. But this rings hollow when talking about math. An examination of the history of mathematical notation demonstrates, as you may already know, that mathematical notation is not exactly experiencing a high rate-of-change. Equations, as used in math and sciences, for the most part use the same notation they did 100 years ago, and many parts of notation are 200-300 years old. Certainly there is no essential change in notation since 1999, when MathML was created.

Now if Microsoft had merely wanted to create a proprietary format for equations and use that in Word in order to trap their customers onto that platform, then I’d simply say that’s not my concern and I’d blog about my heirloom tomatoes or something else. But when this shows up in a nominally open standard destined for approval by ISO, then this raises my eyebrows a little. The obvious choice would have been to simply reuse MathML. So, why are they creating, and standardizing a whole new math markup language? Are there no standards worth reusing? Will XPS replace PDF, VML replace SVG, Windows Media Photo format replace PNG, OMML replace MathML, and OOXML replace ODF? Let’s say “No” to OMML and “Yes” to MathML, **the math you can use**.

This work, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 United States License.

{ 13 comments… add one }

Although I am a staunch proponent of MathML, I think the criticism that OMML doesn’t use MathML is not really fair. I suspect that one of Microsoft’s goals in OMML was to represent the math in their documents in an absolutely faithful way. Since their internal representation is not MathML, it’s XML representation can’t be either without incurring conversion errors.

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

Paul, you know equations in Word better than almost anyone, so I’ll take your word for it that OMML is closer to the internal representation in Word. Clearly the best choice from the sole perspective of reducing Microsoft’s effort is to make as much as possible of OOXML be a one-to-one mapping to the internal Office representations. That is the easiest approach, but I’ll argue that this is not the only approach, and certainly not the optimal approach, when taking the broader view of the industry and users.

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.

Rob, have you looked at Brian Jones’ response to this post? He raises points about integration with document level features like change tracking, styling etc that seem to make sense to me.

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.

I did read the article, thanks.

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?

“Just couldn’t find a way”? Nonsense. OpenDocument uses MathML, and handles change tracking and styling. The only plausible explanation is that Microsoft is trying to PREVENT interoperability, by creating its own complete non-standard-everything. In Microsoft’s head, you must re-implement every existing function, in a non-standard way. The ECMA standard appears to be a charade, to fool gullible governments into locking themselves into a single vendor, again.

Rob, if your attitude towards Microsoft is representative of the attitude of people working on ODF, it is no wonder that Microsoft would not join.

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.

Hi Ray,

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.

Hi Rob

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.

And two standards for representing vector graphics, and two for mathematical equations, and two for forms, and two for raster images, and two for portable page description langauges, and two for java-like languages, and two for browser markup, and two for javascript-like languages, and two divergent versions of CSS, and so on and so on.

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.

Luckily the commenters on Brian Jones XML weblog have looked at the implementation by OO.o of MathML and compared it to the MS Office beta. And frankly the lack of spec definition in ODF show in their findings. It is unlikely that with current ODF specs anyone with make a compatible application from it.

hAI,

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.).

Well, Rob, mayby I misjudged you censoring posts but I have posted several messages (3 or 4) in the past using the anonymous identity option (mostly after your post was on groklaw) and never seen those back on the blog.

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 ???

Start with the manifest.xml file. That’s like the table of contents for the document archive. The formula is defined as type “application/vnd.oasis.opendocument.formula” and points to a directory in the zip file. In a simple example, with just one formula it points to Object1 directory. That directory has a content.xml which is the MathML for the formula.

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.