MathGroup Archive 2006

[Date Index] [Thread Index] [Author Index]

Search the Archive

a summary of MathML use cases that don't work with Mathematica (stuff WRI should fix for the next go-round)

  • To: mathgroup at smc.vnet.net
  • Subject: [mg69987] a summary of MathML use cases that don't work with Mathematica (stuff WRI should fix for the next go-round)
  • From: "Chris Chiasson" <chris at chiasson.name>
  • Date: Thu, 28 Sep 2006 06:18:25 -0400 (EDT)

See below for code, this is just the description:

1)
It appears the ContentMathML part of a MathML export is based on some
kind of parsing of the printed form of an expression. One would think
that the content MathML would come directly from the Kernel
representation/FullForm of an expression, but I demonstrate below that
this is probably not the case.

This is a particularly strange situation to be in for an
implementation from WRI. Mathematica usually maintains very good
simultaneous control of both the content of an expression and its
presentation.

As a result of the smearing together of content + presentation on
MathML export, Mathematica can't reliably round-trip MathML.

2)
Mathematica fails to import (as XML) its own MathML exports.

3)
When Mathematica imports (as MathML) any MathML, even if it only
contains content MathML, the resulting expression is a Box form. I
would understand if that happened with presentation-only MathML, but
content MathML should be imported as a kernel/FullForm expression.
Imports of combination content + presentation MathML should take an
option to allow the user to choose which result is desired.

4)
When writing MathML, Mathematica screws up arbitrary precision numbers
with accuracy less than 1.0.

5)
It is very difficult to capture the SymbolicXML form of a namespace
prefixed MathML expression due to lack of an appropriate option on
XML`MathML`ExpressionToSymbolicMathML and, subsequently, various
Import/Export shortcomings. This makes it hard to write it out in a
compound document that can be transformed.

Today's XSL 1.0 transformers are unable to handle compound documents
with unprefixed namespaces. A typical case would be the transformation
of DocBook + MathML into XHTML+MathML. An XSL 1.0 transformer can't do
this without having a prefix on the MML elements.

The code:

1) & 4)

shows how content MathML is based, paradoxically, on the Box form of
the exported expression
&
shows how 5.4 is actually written out as 5.0 (this bug is common to
content and presentation MathML exports)

In[1]:=
MakeBoxes[YoungsModulus,_]="E";
MakeBoxes[SectionModulus,_]="I";
eqn[1]=\[Delta]==F*L^5.4``0.9/(3*YoungsModulus*SectionModulus);
ex[1]=ExportString[eqn[1],"MathML",ConversionOptions->{"Formats"->"ContentMathML"}]

Out[4]=
<math xmlns='http://www.w3.org/1998/Math/MathML'>
 <apply>
  <eq/>
  <ci>&#948;</ci>
  <apply>
   <times/>
   <ci>F</ci>
   <apply>
    <power/>
    <ci>L</ci>
    <cn type='real'>5.0</cn>
   </apply>
   <apply>
    <power/>
    <apply>
     <times/>
     <cn type='integer'>3</cn>
     <imaginaryi/>
     <exponentiale/>
    </apply>
    <cn type='integer'>-1</cn>
   </apply>
  </apply>
 </apply>
</math>

2)
shows that Mathematica can't import its MathML as XML

In[5]:=
ex[2]=ExportString[eqn[1],"MathML"];
ImportString[ex[2],"XML"]

Out[6]=
System`Convert`MathMLDump`ImportMathML[C:\DOCUME~1\Chris\LOCALS~1\Temp\000\
003a01664]

1) & 3)

shows that Mathematica thinks that the content MathML should be
represented by a box structure
&
also note the incorrect presence of \[ImaginaryI] and \[ExponentialE],
as if they came from the printed form of the equation instead of the
internal representation

In[7]:=
imp[1]=ImportString[ex[1],"MathML"]

Out[7]=
FormBox[TagBox[
    RowBox[{\[Delta],\[LongEqual],
        FractionBox[RowBox[{F, ,SuperscriptBox[L,5.`]}],
          RowBox[{3, ,\[ImaginaryI], ,\[ExponentialE]}]]}],MathMLContentTag,
    AutoDelete\[Rule]True],TraditionalForm]

1)
even after the Box form is turned into the expression that Mathematica
should have automatically returned, it is not the same as the
expression that we exported because of the presence of E and I:

In[8]:=
imp[2]=ImportString[ex[2],"MathML"];
ToExpression[imp[2]]===eqn[1]

Out[9]=
False

5)
Where is the missing NamespacePrefixes option for
ExpressionToSymbolicMathML?? And yes, I do know of a workaround, but
it does not replace a direct option here. Notice that the option is
present for ExpressionToMathML, even though it doesn't work right,
since it also outputs a default namespace in addition to a prefixed
namespace.

In[10]:=
Options@XML`MathML`ExpressionToSymbolicMathML

Out[10]=
{"Annotations"->{},"Formats"->{"PresentationMathML","ContentMathML"},"UseUnicodePlane1Characters"->True,"MathAttributes"->{},"IncludeMarkupAnnotations"->True}

In[11]:=
Options@XML`MathML`ExpressionToMathML

Out[11]=
{"Annotations"->{},"AttributeQuoting"->"'","CheckXML"->True,"ElementFormatting"->Automatic,"Entities"->None,"Formats"->{"PresentationMathML","ContentMathML"},"IncludeMarkupAnnotations"->True,"MathAttributes"->{},"NamespacePrefixes"->{},"UseUnicodePlane1Characters"->True}

-- 
http://chris.chiasson.name/


  • Prev by Date: Re: Re: Unexpected "Invalid comparison" error when plotting function defined with a Condition pattern
  • Next by Date: Re: Copying cell contents?
  • Previous by thread: maxima function
  • Next by thread: [mglost] [ADMIN] Please resend recent posts