ContentMathML-extension-proposal.md

@@ -12,6 +12,49 @@ Our [current ContentMathML extension](https://github.com/mathjax/MathJax/blob/ma
     * 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 algorithm mentioned as optional 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 is rendered as written rather than our guess of what a simplified rendering should be.
+
+
+
 ### Future features
 
 * localization -- see https://github.com/mathjax/MathJax/issues/695