# RE: Technical reasons for some options taken on design of MathML

Date: Tue, 18 Apr 2006 03:00:47 -0700 (PDT)
Message-ID: <3374.217.124.88.179.1145354447.squirrel@webmail.canonicalscience.com>
To: <www-math@w3.org>


Basic requirements for mathematical-scientific language

I have updated some basic requirements for a generic mathematical markup
language for scientific requirements at the next link.

[http://canonicalscience.blogspot.com/2006/04/scientific-language-canonml-is.html]

Some requirements fit into the XML model and could be considered for
debate for the future mathML specifications. Other requirements do not fit
and will be developed in alternative mathematical approaches to those from
the w3c from the Center for CANONICAL |SCIENCE).

Some requirements were presented in the past

[http://canonicalscience.blogspot.com/2006/02/choosing-notationsyntax-for-canonmath.html]

but that document will be updated.

=== Basic requirements =============

Data optimisation
-----------------

MathML is unnaturally verbose and redundant. Whereas in practice this is
not a serious problem for encoding simple formulae as E=mc^2, it is a
problem for scientific databases and for computation or interchange of
information.

In shorthand notation, the Redfield equation reads

(partial rho) / (partial t) = (L + R) rho

where R is the Redfield tensor. But equation stored for a small
physicochemical system of current interest needs of the order of 7 GB of
memory.

Taking an x10 verbosity factor, we would need 70 Gb in MathML for the same
equation.

The Redfield equation is an ultrasimplified version of more general
equations.

For example, following MathML 2.0 specification matrix

0 1 0
0 0 1
1 0 0

is encoded as

<matrix>
<matrixrow>
<cn>0</cn><cn>1</cn><cn>0</cn>
</matrixrow>
<matrixrow>
<cn>0</cn><cn>0</cn><cn>1</cn>
</matrixrow>
<matrixrow>
<cn>1</cn><cn>0</cn><cn>0</cn>
</matrixrow>
</matrix>

but can I use this ultraverbose encoding for Detour matrices of scientific
interest? Detour matrices are N x N ones. In mathematical chemistry, N is
of the order of the size of a chemical compound.

I do not consider elegant and coherent encoding big (N = 1000) Detour
matrices using MathML. Is it?

Encoding of non-hierarchical structures
---------------------------------------

This may be useful on quantum mechanical models.

Extensibility
-------------

Currently MathML presentational markup is not, and not all people agree on
extensibility of Content MathML.

Backward compatibility
----------------------

Language would be more close possible to popular existent systems. I mean:
TeX, LaTeX, Mathematica, Maple, Fortran, Lisp, C, ISO 12083, AAP Math,
some scientific DTD (Elsevier one), etc.

This also includes compatibility with CSS, HTML and others.

Formal language
---------------

For example, SXML is directly based in SEXPR and permit us to exploit
formal structure for abstraction layers.

I agree with mathematician Chaitin on the possibilities of computerized
versions of set theory.

Simplicity
----------

The good and concise is twice good!

The language would be directly manipulated and encoded by humans.

Another “advanced” site where (ds)^2 is being incorrectly served as 2s ds
is Distler’s blog MUSSINGS.

If you rely on tools and you are trained to never see the underlying code
(MathML is popularly presented as a kind of hidden mathematical
postscript) you do not know you are encoding.

MathML ultraverbose code

<mrow>
<semantics>
<mrow>
<msubsup>
<mo>&int;</mo>
<mn>1</mn>
<mi>t</mi>
</msubsup>
<mfrac>
<mrow>
<mo>&dd;</mo>
<mi>x</mi>
</mrow>
<mi>x</mi>
</mfrac>
</mrow>
<annotation-xml encoding="MathML-Content">
<apply>
<int/>
<bvar><ci>x</ci></bvar>
<lowlimit><cn>1</cn></lowlimit>
<uplimit><ci>t</ci></uplimit>
<apply>
<divide/>
<cn>1</cn>
<ci>x</ci>
</apply>
</apply>
</annotation-xml>
</semantics>
</mrow>

for \int_1^t \frac{dx}{x} may be avoided. _Difficulty of the encoding
would be of same order than in TeX_.

Juan R.

Center for CANONICAL |SCIENCE)

Received on Tuesday, 18 April 2006 10:00:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:27:37 UTC