LaTeXML generates invalid content MML

[AndreG-P]

Just as an example: \mbox{x} + y will generate the following MML tree:

<math xmlns="http://www.w3.org/1998/Math/MathML" id="p1.1.m1.1" class="ltx_Math" alttext="\mbox{x}+y" display="inline">
  <semantics id="p1.1.m1.1a">
    <mrow id="p1.1.m1.1.4" xref="p1.1.m1.1.4.cmml">
      <mtext id="p1.1.m1.1.1" xref="p1.1.m1.1.1.cmml">x</mtext>
      <mo id="p1.1.m1.1.2" xref="p1.1.m1.1.2.cmml">+</mo>
      <mi id="p1.1.m1.1.3" xref="p1.1.m1.1.3.cmml">y</mi>
    </mrow>
    <annotation-xml encoding="MathML-Content" id="p1.1.m1.1b">
      <apply id="p1.1.m1.1.4.cmml" xref="p1.1.m1.1.4">
        <plus id="p1.1.m1.1.2.cmml" xref="p1.1.m1.1.2"/>
        <mtext id="p1.1.m1.1.1.cmml" xref="p1.1.m1.1.1">x</mtext>
        <ci id="p1.1.m1.1.3.cmml" xref="p1.1.m1.1.3">𝑦</ci>
      </apply>
    </annotation-xml>
    <annotation encoding="application/x-tex" id="p1.1.m1.1c">\mbox{x}+y</annotation>
  </semantics>
</math>

However, the mtext tag is considered as invalid for the apply element in mathml documents by
https://www.w3.org/Math/DTD/mathml3/mathml3.dtd

[AndreG-P]

For the DRMF we use the following workaround:

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet exclude-result-prefixes="ltx" version="1.0" xmlns:ltx="http://dlmf.nist.gov/LaTeXML"
                xmlns:m="http://www.w3.org/1998/Math/MathML" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                xpath-default-namespace="http://www.w3.org/1998/Math/MathML">
    <!-- Include all LaTeXML to xhtml modules -->
    <xsl:import href="LaTeXML-common.xsl"/>
    <xsl:import href="LaTeXML-math-xhtml.xsl"/>
    <xsl:template match="m:csymbol[@cd='ambiguous' and text() = 'superscript']">
        <xsl:element name="power" namespace="{$mml_ns}">
            <xsl:attribute name="id">
                <xsl:value-of select="@xml:id"/>
            </xsl:attribute>
            <xsl:copy-of select="@xref"/>
        </xsl:element>
    </xsl:template>
    <xsl:template match="m:apply//m:mtext">
        <xsl:element name="ci" namespace="{$mml_ns}">
            <xsl:attribute name="id">
                <xsl:value-of select="@xml:id"/>
            </xsl:attribute>
            <xsl:copy-of select="@xref"/>
            <!-- merges subsequent text elements -->
            <xsl:apply-templates/>
        </xsl:element>
    </xsl:template>
    <xsl:template match="m:csymbol[@cd='ambiguous' and text() = 'subscript']">
        <!-- interpret subscripts as parameters -->
    </xsl:template>
    <xsl:template match="m:csymbol[@cd='dlmf' and text() = 'apply-upper-index']"/>
    <xsl:template match="m:csymbol[@cd='dlmf' and text() = 'apply-infix-operator']"/>
</xsl:stylesheet>

[brucemiller]

Are you replacing the mtext by ci or wrapping it? It seems the former, but that is making too many assumptions about the intended meaning. It would seem that where mtext (or other random pmml) arises, you'd want to wrap in a ci to be (more) valid, but it still defers the whole question of meaning. In these cases, you've got pretty much no handle on the meaning, though

[AndreG-P]

I agree, our workaround isn't right. However, we needed to solve invalid content MathML quickly and came up with this idea. It looks like it's a more complicated problem than we thought.

[brucemiller]

Well, there's no real "right" without knowing the semantic intent; wrapping in an m:ci is pretty much the only solution (but I think better to wrap than to replace). The patch was actually quite easy. Figuring out the semantics is a bit harder :> Thanks for the report!

[brucemiller]

Incidentally, while I can see that from a quick-n-dirty programming point of view, that it's very convenient to build into the XSL stylesheets your (rather extreme) assumptions about superscripts being powers, it seems me rather dangerous (easily forgotten) and not really the design approach I'd take. I'd rather think of examining LaTeXML's XML tree, looking for candidate assumptions (with the possibility to then actually look at each case to determine the quality of the guess) and then upgrading the meaning, as appropriate. Considerably more programming, for sure, but seems more powerful in the long run.