A Tough Case for Content MathML

It seems to me that asking authors to write their math as content MathML in Connexions' current state is a bit like asking programmers to write code without debugging it. Content MathML is only powerful if it has the intended semantics, and using tools like Formulator MathML Weaver, there are ways to author content MathML which can have none of the intended semantics while still being totally valid content MathML. Without having a tool to evaluate the content MathML, authors cannot be sure that the math they just wrote has the intended semantics - hence, my comparison that it's a bit like asking them to write code that they hope will run flawlessly without debugging that code on a set of test cases. Until we have that test case (i.e., some sort of content MathML plugin running in Connexions), I'm not sure I see the utility of asking authors to go the extra mile and enter their math as content MathML rather than presentation MathML.

As an example, consider writing the expression "five times x-hat" in content MathML using Formulator. We intend for "x-hat" to be a variable, whose content MathML representation requires a bit of presentation MathML to get it to look right. Our first attempt is as follows:

<m:math>
  <m:apply>
    <m:times/>
    <m:cn>5</m:cn>
    <m:csymbol>
      <m:mover>         
        <m:mi>x</m:mi>         
        <m:mo stretchy='true'>ˆ</m:mo>       
      </m:mover>     
    </m:csymbol>
  </m:apply>
</m:math>

This is what we get by selecting the two-element multiplication operator from Formulator's content MathML menu, typing "5" in the first argument position and switching over to the presentation menu to build the "x-hat" in the second argument position. Note that what we get is in fact Content MathML, but that the "x-hat" argument is wrapped in a tag set. A visit to the MathML spec reveals that "the csymbol element allows a writer to create an element in MathML whose semantics are externally defined... The element can then be used in a MathML expression as for example an operator or constant." Thus, because we gave Formulator no clue as to what "x-hat" actually was, it punted and used the definition, which requires external definition of "x-hat" by the software interpreting the Content MathML. If we had such software to try this expression out on, we'd realize our mistake immediately. Otherwise, being the content MathML novices that we are, we'd assume we'd done the right thing by going the extra mile and then move on to our next equation. It certainly works fine when pasted into Connexions' edit-in-place.

The right way to do this is to select the two-element multiplication operator as before, type "5" into the first argument, click over to the second and select the "ci" button from Formulator's content MathML menu, and then switch to the presentation MathML menu and compose the "x-hat" as before. Another visit to the MathML spec shows us that "the ci element is used to name an identifier in a MathML expression (for example a variable). Such names are used to identify mathematical objects. By default they are assumed to represent complex scalars. The ci element may contain arbitrary presentation markup in its content...so that its presentation as a symbol can be very elaborate."

This then gives:

<m:math>
  <m:apply>
    <m:times/>
    <m:cn>5</m:cn>
    <m:ci>
      <m:mover>         
        <m:mi>x</m:mi>         
        <m:mo stretchy='true'>ˆ</m:mo>       
      </m:mover>     
    </m:ci>
  </m:apply>
</m:math>

In other words, we've specifically designated "x-hat" as a complex scalar through the content MathML window before switching over to presentation to get it to look the way we want it to look. Feeding it to an interpreter of some sort would confirm that "x-hat" is a variable as we intended.

Now, both ways are technically valid content MathML, but a motivated user who's gotten into Formulator **just far** enough to figure out how to get it to make content MathML output but not far enough to really grasp the subtleties of content MathML may very well think they've generated useful content MathML while in reality what they've gotten is very little more useful than presentation MathML from the point of view of a software interpreter.

Thus, it's admittedly a bit of a chicken-and-egg problem, but I'm not sure I see the utility in asking users to go the extra mile and hand-generate content MathML until we have a way for them to verify that it means what they want it to mean. Note that content MathML output from a program such as Mathematica or Maple, where the internal representation **already** had semantics, is obviously not subject to these misgivings.