Comparison of OpenXML math and MathML


Murray Sargent who was the architect of the new math functionality in Office 2007 has a blog post where he talks more about the design of the Math schema in the Office Open XML formats (http://blogs.msdn.com/murrays/archive/2006/10/07/MathML-and-Ecma-Math-_2800_OMML_2900_-.aspx). Murray has also been active in the MathML community and is even joining the MathML 3.0 working group.

I gave some background information on why we made the decision to support MathML, but not to use it in the Office Open XML formats. We support MathML on the clipboard, and also have XSLTs that go both ways (from MathML into Office Open XML and from Office Open XML to MathML). Murray goes into much greater detail on this in his post. Here is a small snippet from his post:

Naturally there’s been a lot of discussion as to why we even have OMML, since MathML is really good. Brian Jones has addressed that issue in some detail in his Open XML Formats blog. The main problem is that Word needs to allow users to embed arbitrary scan-level material (basically anything you can put into a Word paragraph) in math zones and MathML is geared toward allowing only math in math zones. A subsidiary consideration is the desire to have an XML that corresponds closely to the internal format, aiding performance and offering readily achievable robustness. Since both MathML and OMML are XMLs, XSLTs can (and have) been created to convert one into the other. So it seems you can have your cake and eat it too. Thank you XML!

-Brian

Comments (10)

  1. marc says:

    Regarding maths, it seems that MS OpenXML ( future ECMA and may be ISO standard ) needs some leap-year-calculation teaching:

    http://www.robweir.com/blog/2006/10/leap-back.html

    🙂

  2. hAl says:

    @marc

    I do not see the section that Rob Weir is mentioning in the OOXML draft

  3. hAl says:

    @marc

    I do not see the section that Rob Weir is mentioning in the OOXML draft

  4. hAl says:

    Never mind. Rob has changed his blog article to point the  section which hold the date issue.

    I agree that OOXML has made a poor choice of resolving the date issue. It would have been a good time to lose a bug in the excel implementations of the 1900 date.

  5. jones206@hotmail.com says:

    Yikes, those IBM folks are really getting aggressive with the mudslinging. I’ll admit I’ve also voiced criticisms of ODF in the past, but that was only done in response to those people who challenged our decision to not use ODF as the default format; I wanted to provide more details on why we made that decision. The negative comments from IBM are of a slightly different nature. They have convinced a number of governments to mandate ODF because it’s been chosen as a strategic investment for IBM. Heck, they have a vice president on the road telling governments that ODF is the only choice. When you have a VP doing this (and heavily blogging on it), it’s probably a good indication that there has been a good amount of money invested, or they feel they have a lot of money to gain by that tactic. Their goal of course is to try and block deployments of Microsoft Office, and instead get their services and consulting in place. It’s definitely a move that makes sense on their part, but I think they were also caught off guard a bit by our formats. They really, really, really want to try to block the Office Open XML formats from government adoption, and it looks like they are starting to turn up the heat in this area.

    Now, clearly the Open XML formats standard is a huge spec, and it’s extremely detailed. We wanted to make sure that every element and attribute was clearly documented and explained so that there would be no chance of misinterpretation. There will definitely be places where people question a design decision, it would be impossible to not have that. Even smaller file formats that are less specified like ODF have areas where people have challenged the design decisions. Ultimately it was up to the engineers (who spent countless hours working on the standard) to decide what the right tradeoffs were in different cases.

    That was a pretty big write-up by Rob for what really is a minor issue (and pretty straightforward). Yeah, maybe it’s a bit awkward, but it doesn’t break interoperability, and it’s certainly very well documented.

    We discussed this specific issue in the TC45 meetings (it was mentioned by Novell), but the group decided to keep the behavior in place. It’s actually not a bug but a design decision. It was purposely put in place that way many versions ago to enable compatibility with older Lotus spreadsheets (kind of ironic given that the comments are coming from IBM). People had spreadsheets that relied on that behavior and we didn’t want to break them. That’s the case still today (even more so), so the behavior remains. We haven’t had many complaints about this behavior, but if we changed it, there would be a lot of broken spreadsheets as people have functions and solutions that rely on this behavior. If we changed the values for those dates, then any formulas could also be broken. Barclay’s Capital is a member of the technical committee and they have a huge investment in existing spreadsheets (millions of dollars worth). The compatibility of this format with their existing spreadsheets was crucial, and that’s the case with a huge number of other companies as well.

    There was a discussion around this up on the openxmldeveloper.org site, and someone pointed to this blog post from Joel Spolsky http://www.joelonsoftware.com/items/2006/06/16.html which covers some of the details if you guys are interested.

    -Brian

  6. hAl says:

    [quote]That was a pretty big write-up by Rob for what really is a minor issue (and pretty straightforward). Yeah, maybe it’s a bit awkward, but it doesn’t break interoperability, and it’s certainly very well documented.[/quote] It weirdly isn’t listed in the primer 3.16 section about dates.

    I think that it wasn’t a very good descision by the TC to let that date issue left in the OOXML format as this was a good opportunity to remove it and it isn’t a real legacy issue as it can be easily solved in conversions.

    However for David Wheeler to commenting on the article about the use of iso 8601 dates in the ODF format was a bit low. Especially since I know from a lot of personal experience that the iso 8601 date format is really a horrible mess and absolutly not what any programmer would want in his programs was a bit overdone.

  7. Fernando says:

    IBM is becoming more and more desperate… ODF seems to be bombing big time.

  8. Brian, I think you should take heart that the other side is now at least actually *looking* at the spec before critcizing it. That’s progress, isn’t it?

    Also, how ironic that this is the infamous Lotus 1-2-3 calendar behavior that Excel carefully copied for compatibility back in the early 90’s…and 1-2-3 is now…an IBM product! And of course it retains this behavior too for the same reasons Excel does.

    Chris

  9. marc says:

    >They have convinced a number of governments

    > to mandate ODF because it’s been chosen

    > as a strategic investment for IBM…

    >When you have a VP doing this

    > (and heavily blogging on it) …

    i feel this kind of pressure more scaring than a blog:

    http://www.mass.gov/Aitd/docs/policies_standards/etrm3dot5/responses/microsoft.pdf

    ( stop-with-this-game-or-we-will-sue-you like MS letter cc: a state governor )

  10. jones206@hotmail.com says:

    Hey Chris, just like you said, we now converse more through blogs than in person (for anyone interested, I used to work for Chris)… 🙂

    Marc, You really find that scary? I’m much more concerned about about corporations asking governments to mandate a specfic technology baring any others that may come along so that they can gain a competitive advantage. That letter you linked to was Microsoft asking Mass. to reconsider and view Office Open XML as an open standard as well. You think choice is a bad thing?

    -Brian