Skip to content

ContentMathML extension proposal

Jump to bottom
Peter Krautzberger edited this page Apr 11, 2014 · 12 revisions

Summary

Our current ContentMathML extension is built around David Carlisle's XSLT solution ctop (c-to-p, content to presentation). This solution makes it hard to maintain and use. It is also not ideal as xslt support in Chrome might be dropped.

Requirements

  • remove dependency on the xslt stylesheet, implement a pure JavaScript solution
    • build on ctop.js
    • if possible, improvements should be contributed upstream to ctop.js
  • Identify, develop and document APIs to allow page authors to modify the conversion process
    • scope: to be determined. A first approximation might be where the MathML spec offers two Presentation MathML constructs for one Content MathML element (e.g. interval, lambda).
  • maintain or improve current Content-to-Presentation conversion quality

Notes on Strict Content MathML

We do not implement the Content MathML => Strict Content MathML transformation mentioned (optionally) in the MathML spec. Instead, we take a down-to-earth approach to Strict Content MathML.

Essentially, by handling

<apply><csymbol>foo</csymbol>

and

<apply><foo/>

as the same thing.

This is a rather loose interpretation of Strict Content which should care about Content Dictionaries etc. However, we convert for presentation where it doesn't matter. If an author calls a symbol

<csymbol cd="some-weird-category">plus</plus>

then it gets rendered as an infix +. If that's not desired, then we humbly suggest not to call it plus.

In the general case, <apply><csymbol> will be rendered using prefix form. The important thing is that every expression has a rendering, It is not necessary to give strict forms the same rendering as the markup using the specific mathml container elements. But we're happy to accept contributions for specific cases.

So for example if you have

<set><ci>a</ci><ci>b</ci><ci>c</ci></set>

and

<apply>
    <csymbol>set</csymbol>
    <ci>a</ci><ci>b</ci><ci>c</ci>
</apply>

If one wants both to come out as {a,b,c} that's fine but if the first comes out as {a,b,c} and the second as set(a,b,c) that is OK too.

But it is always acceptable to render in prefix form.

Since many users of Strict are thinking in terms of lambda calculus expressions (e.g. for theorem provers), they will probably be happier if a sum of terms is rendered as plus(1,2,3) rather than 1+2+3 or if lambda terms are rendered as written rather than our guess of what a simplified rendering should be.

Future features

notes from a MathML test suite run

These notes have all been copied into issues, so they're easier to cope with

presentation MML notes [should be moved]

Bidi

lots of bidi works. Does the ContentMML extension do anything here?

linebreaking

other errors

MathJax Wiki

Clone this wiki locally